| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, if a vertex shader's outputs didn't exactly match a fragment
shader's inputs we could wind up with invalid TGSI shader declarations.
For example:
Before patch:
DCL OUT[0], POSITION
DCL OUT[1], COLOR[1]
DCL OUT[2], GENERIC[0]
DCL OUT[3], GENERIC[0] <- note duplicate [0]
DCL OUT[4], GENERIC[2]
After patch:
DCL OUT[0], POSITION
DCL OUT[1], COLOR[1]
DCL OUT[2], GENERIC[0]
DCL OUT[3], GENERIC[1]
DCL OUT[4], GENERIC[2]
|
| |
|
|
|
|
| |
before/after transfers.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This was sometimes seen when Glean exited upon test failure when using
Gallium.
|
| |
|
| |
|
| |
|
|
|
|
| |
touching the depth component.
|
|
|
|
|
|
| |
Actually, after spotting this problem, I realized this is unreachable
code. However don't bother to enable this fast path now, given the normal
path is working just fine.
|
| |
|
|
|
|
|
|
|
| |
Reversed component order.
This fixes glean depthStencil test failures for PIPE_FORMAT_Z24S8_UNORM
visuals.
|
|
|
|
| |
(cherry picked from master, commit 7fdd64ab29576e607434fb8c82ddfa61e8ea6aa8)
|
|
|
|
| |
(cherry picked from master, commit cc22620e4b11425997f3bc1fc70f4c88cec22d2e)
|
|
|
|
|
|
|
| |
Add _NEW_PROGRAM_CONSTANTS to _SWRAST_NEW_DERIVED.
This makes sure that we update the fragment shader's constants when state
vars (such as point size) changes.
Fixes the progs/glsl/points.c demo.
|
|
|
|
| |
(cherry picked from master, commit d9617deb008b75f4a605a30408aeb1948139c33e)
|
|
|
|
| |
See comments for details.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The existing implementation was already implemented on software, but relied
on the pipe driver to always support the R16G16B16A16_SNORM format. This
patch eliminates that, without prejudice against a future hardware-only
implementation.
It also avoids some of the short <-> float conversions, and only does a read
transfer of the color buffer on GL_RETURN if absolutely necessary.
|
| |
|
|
|
|
|
| |
In st_bufferobj_map_range(), set obj->Offset consistently with its
usage elsewhere.
|
|
|
|
|
|
| |
Return TRUE in this case. Returning FALSE seems to result in
mis-rendering -- possibly opengl32.dll is trying to compensate by
doing a software blit??
|
|
|
|
| |
(cherry picked from master, commit ef8caec29ae73bb2bbeb48f0578d839ef29348cd)
|
| |
|
|
|
|
| |
(cherry picked from master, commit 19a54d9f1055c366fd77026dd67007a8d5921f58)
|
| |
|
|
|
|
|
|
| |
It's legal for ARB_vertex_program programs to not write to result.position.
The results are undefined in that case. This assertion was causing us to
abort/exit though.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The recent increase ST_MAX_SHADER_TOKENS to 8K causes stack overflows on
windows.
Failure to allocate is not being propagated to the caller. This is not
a regression since the previous _mesa_malloc result wasn't being
checked as well. Unfortunately it is not easy to fix, as the callers of
these functions do not have failure propagation mechanism either, and
so on. So leaving a just fixme note for now.
|
| |
|
|
|
|
| |
Also, MAX_NV_VERTEX_PROGRAM_PARAMS should be 96, not 128 (or 256).
|
|
|
|
|
|
| |
We were adding references to the input arrays, but failing to drop
them on destruction. This could lead to a 64kb buffer being leaked
each context destruction.
|
|
|
|
|
|
|
|
|
|
| |
1) Pass the correct format when calling update_array in
_mesa_VertexAttribPointerARB.
2) glVertexAttribPointerNV accepts GL_BGRA format too.
3) raise INVALID_VALUE error when format is BGRA and normalized is
false in glVertexAttribPointerARB
(cherry picked from commit 4adb190a162c5ed0684a8616331344caadba4010)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
autoconf had been designating the 8 bit libOSMesa as the default
standalone osmesa, but the Makefile expected it to be linked to libGL.
Fix up the osmesa Makefile so that it allows any of the combinations of
standalone and channel width to be built.
Fixes bug #21980.
(cherry picked from commit 7441dcd90b01df8351026af8bbb50e11bb86071a)
|
|
|
|
|
|
|
| |
Because of flat shading, we can't use same code as PIPE_PRIM_TRIANGLE_FAN.
This is a follow-on to commit a59575d8fbe8b0ca053cc8366ce7a42bc660158a.
(cherry picked from commit 086ecea179ed572c89aa77c5f465671a5cef87a7)
|
|
|
|
|
|
| |
This fixes incorrect front/back-face orientation.
(cherry picked from commit a64bbdaa3e0b036a880d6db65ceb4a66205062f1)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
When approaching y = x * 0xffffffff / 0xffffff with bit arithmetic, the
8 least significant bits of y should come from the
8 most significant bits of x.
|