| Age | Commit message (Collapse) | Author |
|---|
|
Two parts to this:
One we don't keep pointers to possibly freed memory anymore once we unbind the
drawables from the context. Brian I need to figure out what the comment
you made there, can we get a glean/piglit test so we can fix it properly?
If the new gc is the same as the oldGC, we call the unbind even though
we just bound it in that function. doh.
(cherry picked from master, commit 77506dac8e81e9548a7e9680ce367175fe5747af)
|
|
|
|
For the TXP instruction we check if the texcoord is really a 4-component
atttibute which requires the divide by W step. This check involved the
projtex_mask field. However, the projtex_mask field was being miscalculated
because of some confusion between vertex program outputs and fragment
program inputs.
1. Rework the size_masks calculation so we correctly set bits corresponding
to fragment program input attributes.
2. Rename projtex_mask to proj_attrib_mask since we're interested in more
than just texcoords (generic varying vars too).
3. Simply the indexing of the size_masks and proj_attrib_mask fields.
4. The tracker::active[] array was mis-dimensioned. Use MAX_PROGRAM_TEMPS
instead of a magic number.
5. Update comments, add new assertions.
With these changes the Lightsmark demo/benchmark renders correctly, until
we eventually hit a GPU lockup...
|
|
For some triangles we can generate quads which lie just outside the
surface bounds. Just check the quad's mask before trying to emit/process
the quad.
Fixes failed assertion in Lightsmark.
|
|
A 0 by 0 viewport size is legal. Don't clamp against lower bound of one.
The error checking earlier in the function prevents negative values.
|
|
The results were incorrect for some negative values of A.
See bug 21872.
|
|
|
|
Fixes memory leak when destroying framebuffers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As we're only using 32bit bitmasks.
|
|
|
|
Render results are only visible when the render cache is flushed.
softpipe_is_texture_referenced must reflect that or transfers to/from the
textures bound in the framebuffer won't be proceeded of the necessary
flush, causing transfer data to be outdated/clobbered.
This fixes conform drawpix test with softpipe.
|
|
depth- and stencil renderbuffers.
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
3f2e006b759705abd7c409d30f9aeb1f2a75b83f
Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
|
|
|
|
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)
|
