search for: pformats

...es[NUM_NV04_OVERLAY_ATTRIBUTES] = { @@ -2042,8 +2049,8 @@ NV50SetupTexturedVideo (ScreenPtr pScreen) adapt->name = "Nouveau GeForce 8/9 Textured Video"; adapt->nEncodings = 1; adapt->pEncodings = &DummyEncodingNV50; - adapt->nFormats = NUM_FORMATS_ALL; - adapt->pFormats = NVFormats; + adapt->nFormats = NUM_FORMATS_NV50; + adapt->pFormats = NV50Formats; adapt->nPorts = NUM_TEXTURE_PORTS; adapt->pPortPrivates = (DevUnion*)(&adapt[1]); diff --git a/src/nv50_xv.c b/src/nv50_xv.c index b2541b9..ba01c99 100644 --- a/src/nv50_xv.c +++ b/src/nv50...

Not clear what the depth % 8 was trying to protect against, but it was breaking 30bpp visuals with DRI3. Add it in to ensure that bitsPerPixel % 8 is 0, since there is plenty of bpp/8 math in the driver. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nouveau_dri2.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c

On Aug 1, 2012, at 1:53 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > > Currently, we rely on switch tables to transform between formats. However, > we would like to have a different mechanism to represent these relationships > instead of switch tables. I am thinking of modeling these relations in > HexagonInstrInfo.td file and use TableGen to generate a table with

Hi Everyone, After some more thoughts to the Jacob's suggestion of using multiclasses for Opcode mapping, this is what I have come up with. Please take a look at the design below and let me know if you have any suggestions/questions. I have tried to keep the design target independent so that other targets could benefit from it. 1) The idea is to add 3 new classes into

Hi, I'm looking for some suggestions on a problem related to the Hexagon backend. Hexagon architecture allows instructions in various formats. For example, we have 3 variations of the add instruction as defined below: ADDrr : r1 = add(r2, r3) --> add 2 32-bit registers ADDrr_p : if(p0) r1 = add(r2, r3) --> predicated version of ADDrr instruction, executed when p0 is true ADDrr_np :

[wparish@localhost inex5]$ wine --version Wine 20040813 That was a Mandrake 10.0 rpm installation, over which I installed Wine-20050211.tar.gz This is the relevant history: [wparish@localhost wine-hdd]$ cd ie6 [wparish@localhost ie6]$ ls ADVAUTH.CAB* IECIF.CAB* IEMIL_2.CAB* IEW2K_1.CAB* OEEXCEP.CAB* AOLSUPP.CAB* IEDATA.CAB* IEMIL_3.CAB* IEW2K_2.CAB* README.CAB* AXA3.CAB*

The headers hadn't been regenerated in a long time and had seen a number of manual modifications. A few changes: - remove nvc0_2d entirely, use the nv50 header which has the nvc0 values too - remove 3ddefs, it's identical to the nv50 file - move macros out into a separate file Also the upstream rnndb changed the overall chip naming convention; this was fixed up manually in the

The headers hadn't been regenerated in a long time, and there were a few minor divergences. Among other things, rnndb has changed naming to G80/etc, for now I've not tackled switching that over and manually replaced the nvidia codenames back to the chip ids. However no other modifications of the headergen'd headers was done. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>