Age | Commit message (Collapse) | Author |
|
|
|
Fixes ut2004 warnings about overflowing command buffer.
|
|
|
|
|
|
With gcc implementation uses __builtin_clr which counts number of
leading zeros.
Fallback implementation uses bit manipulation. First it duplicates
the highest bit to all lower bits and then adds one to get the power
of two number.
|
|
|
|
Changed stride size calculation to do the math by rounding
the value instead of loop. r600 minimum stride is 256 which
might might cause up to about 60 rounds of the loop.
|
|
Bug #32810
|
|
For the tiny bis of data we generally upload through the CURBEs, the
overhead of the kernel's pagetable trickery is actually rather high.
This improves cairo-gl gnome-terminal-vim performance by 3.8%.
|
|
Improves cairo-gl gnome-terminal-vim times by 11%.
|
|
Fixes failure in cairo-gl firefox-planet-gnome.
|
|
This improves firefox-talos-svg runtimes on cairo-gl by 14%.
|
|
The piglit vp-address-01 test uses negative address-relative
offsets. In this test we're indexing into PROGRAM_STATE_VAR
which, in turn, contains references to ENV vars.
We previously fixed this issue for PROGRAM_CONSTANT.
piglit/vp-address-01 (the version from Feb 5) passes now.
(cherry picked from commit 64be837b0b171c44f47a3c0b83f566d292ffff50)
|
|
|
|
Without this patch, the two symbols get an underscore prepended
and an "@4" appended when compiling with VC8.
Signed-off-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit e65029e9b32ddabea0ec583c04484345b40f1557)
|
|
This got "simplified" away in e4f168a6f4911a096be97d2e83ef8ad9c5862ec0.
|
|
This fixes the progs/glsl/pointcoord.c demo. But this isn't a proper fix.
We really need a TGSI_SEMANTIC_POINT_COORD label so that the draw module
can determine which fragment input / vertex output slot needs to be set
up with the point coordinate info. We've been using generic slot 0 so far.
This would also require telling the draw module about fragment shaders
(something it doesn't have at this time).
|
|
Only emit polygon stipple when the state is enabled.
|
|
|
|
|
|
This fixes glean paths test case.
|
|
GL_TRUE indicates that the driver accepts the program.
GL_FALSE indicates the program can't be compiled/translated by the
driver for some reason (too many resources used, etc).
Propogate this result up to the GL API: set GL_INVALID_OPERATION
error if glProgramString() was called. Set shader program link
status to GL_FALSE if glLinkProgram() was called.
At this point, drivers still don't do any program checking and
always return GL_TRUE.
|
|
This fixes glean paths test case.
|
|
|
|
DEBUG preprocessor macro is set by configure script when
--enable-debug is passed for configure. Radeon then just
increase debugging verbosity if DEBUG is set in compile
time.
|
|
|
|
We don't need to flush so often. Next step
would be to move the flushing to the drm and only
flush after each command buffer rather than each
draw.
|
|
PXOR user in code were causing the lowest SP float register to have NaN
values which made all math operations in that slot fail. Correct istruction
to clear float registers is XORPS which handles single precission floats
correctly.
Fixes progs/tests/fog in swrast SSE mode.
Now the correct commit instead of 66d09e4a2a6b770ddb which is not even close
of correct fix for the bug.
|
|
|
|
This reverts commit 4c31632817a0bde28ad6c9ee8032d838ce4b7bfb.
|
|
We were misinterpretting GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS previously.
It's the number of texture units for which we need to keep state; not
just the total number of texture units addressable by the vertex shader
plus fragment shader.
Since sw Mesa independently supports 16 texture units in vertex shaders
and 16 texture units in fragment shaders, the max combined units is 32.
Note that the docs for glActiveTexture() indicate the max legal unit is
MAX(GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, MAX_TEXTURE_COORDS) - 1.
A new piglit test (texunits.c) tests the various texture unit limits.
I'm pretty sure I've got this all right now, but additional reviews
are welcome...
|
|
These are limited to the number of texture coordinate units.
|
|
|
|
|
|
|
|
|
|
Further testing should reveal if any these assertions are hit...
|
|
|
|
|
|
|
|
|
|
This should make things easier for drivers wanting to work with a
"subclass" of gl_framebuffer.
The complementary "_mesa_initialize_framebuffer" function is now
called "_mesa_initialize_window_framebuffer" for the sake of
symmetry.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|
|
The in-place splitting code wasn't dealing with index buffers at all
(and it was being called from vbo_split_prims for too big index
buffers, causing some occasional corruption).
Additionally, it wasn't taking into account primitives arrays with
non-contiguous indices (e.g. given prim[0].start = 0 and prim[1].start
= max_verts, it would happily call back the driver with (max_index -
min_index) still greater than max_verts, causing infinite recursion).
It still doesn't handle too large indexed vertex buffers: use
vbo_split_copy for that.
|
|
This is a very informal version number, but there have been enough
changes that a bump is appropriate at this time.
|
|
Compiler can't usually turn x/2.0f into x * 0.5f, though we're happy
with either.
|
|
the first looks like a definite bug, the second I'm not so confident
of but it works.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
4769566500be1a53dd9b4cc1a613aef439a0e3d8
Signed-off-by: Corbin Simpson <MostAwesomeDude@gmail.com>
|
|
It will be useful for the nouveau DRI driver and IMHO there's no
reason to keep it private.
Signed-off-by: Brian Paul <brianp@vmware.com>
|
|
|