| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Kristian Høgsberg <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
dri2DrawableGetMSC(), dri2WaitForMSC() and dri2WaitForSBC() were
inadvertently changed to return 0 on success. This resulted in the callers
returning an error to the client.
Restore the previous behavior and also check that the reply pointers are
valid before accessing them.
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Note that _mesa_GetVertexAttribPointervNV() is actually
glGetVertexAttribPointerv(), which operates on the generic attributes. The
geometry shader initialization looks like arbitrary cruft to me.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
v2: Rebase on top of get.c changes.
Reviewed-by: Brian Paul <[email protected]> (v1)
|
|
|
|
|
|
| |
v2: Rebase on top of get.c changes.
Reviewed-by: Brian Paul <[email protected]> (v1)
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
Note that the MAP2 getters were missing from the implementation. Neat.
v2: Rebase on top of get.c changes.
Reviewed-by: Brian Paul <[email protected]> (v1)
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
While nuking NV_vertex_program, I noticed that one of my opcodes was used in a
strange place.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
v2: Remove dead positive() function, caught by Matt.
Reviewed-by: Brian Paul <[email protected]> (v1)
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
It's not supported in any hardware drivers, and doesn't appear to be useful on
Linux.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
It wasn't supported in hardware, and the comments in the code indicated no
known uses (similar to my experience on Intel) and a possible intent to remove
it.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were holding on to this code because we were aware that NWN 1 had some
support for vertex programs -- no other linux programs I've come across would
use it (since other software also has ARB_vp or GLSL support). Only, it turns
out that NWN doesn't even give us any vertex programs. Given that we have
known issues where the extension has never been fully supported, just give up
on it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46795
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
These don't appear in ARB_vp or NV_vp and I missed that fact on the first
pass of removing dead opcodes.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Alex Deucher <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
That depends on the texture wrap modes and filtering.
|
|
|
|
|
|
|
| |
- stopped using util_color
- reformatted to occupy less characters per line.
- used memcpy for the border color
- used pipe_color_union in the state structure
|
|
|
|
|
|
|
|
|
|
|
|
| |
And the clear color too, though that may be an issue only with GL_RGB if it's
actually RGBA in the driver.
NOTE: This is a candidate for the stable branches.
Reviewed-by: Brian Paul <[email protected]>
v2: The types of st_translate_color parameters were changed to gl_color_union
and pipe_color_union as per Brian's comment.
|
| |
|
|
|
|
|
|
|
| |
NOTE: This is a candidate for the stable branch.
Signed-off-by: Abdiel <[email protected]>
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
| |
LIST_DEL() always sets the prev/next pointers to NULL now.
|
|
|
|
|
| |
Note: This is a candidate for the 9.0 branch.
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Before 369e46888904c6d379b8b477d9242cff1608e30e, the transfer was
initialized before the call to map and had the correct value already.
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
commit a010215463c63680c69e90202fe3fcd2e5b25fa6 removed ES2 specific dispatch
table and remap_helper, since now we are using dispatch.h which is generated
from gl_and_es_API.xml we need to generate a matching remap_helper using the
same xml.
Note: This is a candidate for the 9.0 branch.
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
|
|
|
|
| |
Could happen when CPU supports AVX, but LLVM doesn't.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example:
VERT
DCL IN[0]
DCL OUT[0], POSITION
DCL OUT[1], GENERIC[12]
DCL CONST[0..4]
DCL TEMP[0], LOCAL
DCL TEMP[1], LOCAL
IMM[0] UINT32 {4294967295, 0, 0, 0}
IMM[1] FLT32 { 0.0000, 1.0000, 0.0000, 0.0000}
0: SEQ TEMP[0].x, CONST[3].xxxx, IMM[0].xxxx
1: F2I TEMP[0].x, -TEMP[0]
2: SEQ TEMP[1].x, CONST[4].xxxx, IMM[0].xxxx
3: F2I TEMP[1].x, -TEMP[1]
4: AND TEMP[0].x, TEMP[0].xxxx, TEMP[1].xxxx
5: IF TEMP[0].xxxx :0
6: MOV TEMP[0], IMM[1].xyxy
7: ELSE :0
8: MOV TEMP[0], IMM[1].yxxy
9: ENDIF
10: MOV OUT[1], TEMP[0]
11: MOV OUT[0], IN[0]
12: END
instead of
VERT
DCL IN[0]
DCL OUT[0], POSITION
DCL OUT[1], GENERIC[12]
DCL CONST[0..4]
DCL TEMP[0], LOCAL
DCL TEMP[1], LOCAL
IMM UINT32 {4294967295, 0, 0, 0}
IMM FLT32 { 0.0000, 1.0000, 0.0000, 0.0000}
0: SEQ TEMP[0].x, CONST[3].xxxx, IMM[0].xxxx
1: F2I TEMP[0].x, -TEMP[0]
2: SEQ TEMP[1].x, CONST[4].xxxx, IMM[0].xxxx
3: F2I TEMP[1].x, -TEMP[1]
4: AND TEMP[0].x, TEMP[0].xxxx, TEMP[1].xxxx
5: IF TEMP[0].xxxx :0
6: MOV TEMP[0], IMM[1].xyxy
7: ELSE :0
8: MOV TEMP[0], IMM[1].yxxy
9: ENDIF
10: MOV OUT[1], TEMP[0]
11: MOV OUT[0], IN[0]
12: END
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lp_build_rsqrt initially did not do any newton-raphson step. This meant that
precision was only ~11 bits, but this handled both input 0.0 and +infinity
correctly. It did not however handle input 1.0 accurately, and denormals
always generated infinity result.
Doing a newton-raphson step increased precision significantly (but notably
input 1.0 still doesn't give output 1.0), however this fails for inputs
0.0 and infinity (both result in NaNs).
Try to fix this up by using cmp/select but since this is all quite fishy
(and still doesn't handle denormals) disable for now. Note that even with
workarounds it should still have been faster since the fallback uses sqrt/div
(which both use the usually unpipelined and slow divider hw).
Also add some more test values to lp_test_arit and test lp_build_rcp() too while
there.
v2: based on José's feedback, avoid hacky infinity definition which doesn't
work with msvc (unfortunately using INFINITY won't cut it neither on non-c99
compilers) in lp_build_rsqrt, and while here fix up the input infinity case
too (it's disabled anyway). Only test infinity input case if we have c99,
and use float cast for calculating reference rsqrt value so we really get
what we expect.
Reviewed-by: José Fonseca <[email protected]>
|
|
|
|
| |
must unwrap.
|
| |
|
|
|
|
| |
Can't access ptDraw before it is written.
|
|
|
|
| |
by changing the format to NORM.
|
|
|
|
|
| |
Signed-off-by: Oliver McFadden <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
| |
Fix breakage from commit 369e468.
|
| |
|
|
|
|
| |
Reviewed-by: Francisco Jerez <[email protected]>
|
|
|
|
|
|
|
| |
This library does not exist in LLVM 3.2 and libOpenCL.so links fine
without it on LLVM 3.1
Reviewed-by: Francisco Jerez <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This improves performance a little bit if there are lots of small indexed
draw commands.
|