| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: José Fonseca <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Corbin Simpson <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Michel Dänzer <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a vertex shader input attribute is declared with an integral type
(e.g. ivec4), we need to ensure that the generated vertex shader code
addresses the vertex attribute register using the proper register
type. (Previously, we assumed all vertex shader input attributes were
floating-point).
In addition, when uploading vertex data that was specified with
VertexAttribIPointer, we need to instruct the vertex fetch unit to
convert the data to signed or unsigned int, rather than float. And
when filling in the implied w=1 on a vector with less than 4
components, we need to fill it in with the integer representation of 1
rather than the floating-point representation of 1.
Fixes piglit tests vs-attrib-{ivec4,uvec4}-precision.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This patch ensures that gl_client_array::Integer is properly set to
GL_TRUE for vertex attributes specified using glVertexAttribIPointer,
and to GL_FALSE for vertex attributes specified using
glVertexAttribPointer, so that the vertex attributes can be
interpreted properly by driver back-ends.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
When converting an expression like "++x" to GLSL IR we were failing to
account for the possibility that x might be an unsigned integral type.
As a result the user would receive a bogus error message "Could not
implicitly convert operands to arithmetic operator".
Fixes piglit tests {vs,fs}-{increment,decrement}-uint.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
| |
|
|
|
|
|
| |
Signed-off-by: Jakob Bornecrantz <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
| |
They are only used by the r200 driver now.
|
|
|
|
|
| |
With DRI2, textures are always resident and using the DRI texmem helper
here is broken anyway, since nothing else uses it.
|
| |
|
|
|
|
| |
drirenderbuffer.[ch] is going bye-bye.
|
| |
|
| |
|
| |
|
|
|
|
| |
DRI2 is always enabled now.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also DRI1-only.
|
|
|
|
| |
DRI1-only as well.
|
|
|
|
| |
Another DRI1-only extension.
|
|
|
|
| |
All DRI2 drivers support setting a separate read drawable.
|
|
|
|
| |
There are no DRI1 drivers left.
|
|
|
|
|
| |
TODO: check if GetImage works with passing the pitch as width, similar to PutImage,
which avoids the extra copy, ala dri_sw_displaytarget_display() in src/gallium/winsys/sw/dri/dri_sw_winsys.c
|
|
|
|
|
| |
Missed one casting error due to rebase for commit
98aa2a8f725e44aec8bd998fe436a134e94f13bb.
|
|
|
|
|
|
|
|
|
|
| |
This is a cleanup of commit 02f1b50987c0d24da3dcc36dbb44821c20d0660c.
Update tex buffer using a dri_drawable hook from implemented in sw/drisw.c.
This saves us the duplication of dri_drawable.c.
CC: Stuart Abercrombie <[email protected]>
CC: Stéphane Marchesin <[email protected]>
|
|
|
|
|
|
|
| |
This reverts commit 569bde1fa7d03fb7688d0d391b32e61e857ad44e.
CC: Stuart Abercrombie <[email protected]>
CC: Stéphane Marchesin <[email protected]>
|
|
|
|
|
|
|
| |
This reverts commit 02f1b50987c0d24da3dcc36dbb44821c20d0660c.
CC: Stuart Abercrombie <[email protected]>
CC: Stéphane Marchesin <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Certain exports (position, point size, etc.) are treated
specially by the shader and not counted as generic exports.
Note the exports and any relevant related state bits.
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Skip PSIZE and POSITION when counting VS outputs.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=42435
Tested without regressions on evergreen.
NOTE: this is a candidate for the 7.11 branch.
Signed-off-by: Vadim Girlin <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Fixes a bunch of prototype mismatch warnings..
|
|
|
|
| |
Signed-off-by: Jeremy Huddleston <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Yuanhan Liu <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
This fixes issues with the code playing fast and loose with types of
buffers, and as a bonus avoids the wrappers that were previously used
to pull bits out of packed depth/stencil buffers.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Some of the return values were u32, some were 24 bits, and z16
returned 16 bits. The caller would have to do all the work of
interpreting the format all over again. However, there are no callers
of this function at this point.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
Perhaps the easiest implementation, nouveau can directly map buffers
even if tiled, and uses separate surfaces for its texture
renderbuffers so we don't have to worry about that offset.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike intel, we do a blit to/from GTT memory in order to
untile/retile the renderbuffer data, since we don't have fence
registers for accessing it.
(There is software tiling code in radeon_tile.c, but it's unused and
doesn't support macro tiling)
Reviewed-by: Brian Paul <[email protected]>
|