Age | Commit message (Collapse) | Author |
|
Since we stopped using alloc_temp to get hw indices for FP attrs
there shouldn't be any non-deallocated temps left.
|
|
Since we know when we don't use a TEMP or FP ATTR register anymore,
we can release their hw resources early.
|
|
Immediates are inlined now where possible, so we need to set
pc->allow32 to FALSE in LIT where we have the conditional MOV,
since immediates swallow the predicate bits.
|
|
|
|
I chose to just convert unpaired 32 bit length instructions
after parsing all instructions, although it might be possible
to determine beforehand whether there would be any lone ones,
and then even do some swapping to bring them together ...
|
|
|
|
This would have happened in p.e. ADD TEMP[0], TEMP[0].xyxy, TEMP[1]
or RCP/RSQ TEMP[i], TEMP[i].
|
|
Depth output in fragment programs should end up in the first
register after the color outputs.
|
|
VP outputs that should be loadable in the FP are mapped to
interpolant indices by HPOS, COL0 etc.; of course HPOS is
always written, so the highest byte of 1988 is a bitmask that
selects which components of HPOS are used for interpolants,
i.e. the FP inputs in COL0 start at index POPCNT(1988[24:28]).
|
|
Record interpolation mode for attributes while parsing declarations,
and also remember the indices of FP color inputs and FP depth output,
which has to end up in the highest output register.
|
|
We now inspect the TGSI instructions in tx_prep to determine where
temps and FP attrs are last accessed.
This will enable us to reclaim some temporaries early and we also
use it to omit pre-loading FP attributes that aren't used.
|
|
We could do even better (like just allocating 1 value in alloc_immd),
but that's fine for now I guess.
|
|
|
|
According to tgsi-instruction-set.txt, if they are written, z and w
should be set to 0 and 1 respectively in SCS, and w to 1.0 in XPD.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use the first vertex, not the last.
|
|
Fixes segfault in glRasterPos()
|
|
|
|
Fixes failed viewport updates on glxgears (and other apps) resize since
e41780fedc2c1f22b43118da30a0103fa68b769f.
Bug #20473.
|
|
Limit the maximum renderbuffer size to 8192 on i965 and to 2048 on
earlier hardware.
|
|
|
|
|
|
This array was mistakenly dimensioned with VERT_ATTRIB_MAX (32) but it
should really be MAX_VERTEX_GENERIC_ATTRIBS (16).
The generic vertex attributes are in addition to the conventional arrays
(except in NV vertex program mode- they alias/overlay in that case) so
the total of all conventional attributes plus generic attributes should
total 32 (not 48).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When a vertex shader uses generic vertex attribute 0, but not gl_Vertex,
we need to set attribute[16] to point to attribute[0]. We were setting the
attribute size, but not the pointer.
Fixes crash in glsl/multitex.c when using the VertCoord attribute instead
of gl_Vertex.
|
|
|
|
|
|
If the multitex.vert shader uses the VertCoord generic vertex attribute
instead of the pre-defined gl_Vertex attribute, we need to make sure that
VertCoord gets bound to generic vertex attribute zero.
That's because we need to call glVertexAttrib2fv(0, xy) after all the other
vertex attributes have been set since setting generic attribute 0 triggers
vertex submission. Before, we wound up issuing the vertex attributes in
the order 0, 1, 2 which caused the first vertex to be submitted before all
the attributes were set. Now, the attributes are set in 1, 2, 0 order.
|
|
|
|
It's possible to hand a GL_COLOR_INDEX/GL_BITMAP image to glTexImage3D()
which gets converted to RGBA via the glPixelMap tables.
This fixes a failure with piglit/fdo10370 with Gallium.
|