| Age | Commit message (Collapse) | Author |
|---|
|
need to write real hw user clear
|
|
|
|
|
|
|
|
this is a step towards fbos and should fix pageflipping, but
I think the first flip seems broken.
|
|
Remove all references to aux buffers 1..3. Keep AUX0 around for now just
in case, but it'll probably go too someday. I don't know of any OpenGL
drivers since the IRIX days that support aux color buffers.
|
|
s/FRAG_RESULT_DEPR/FRAG_RESULT_DEPTH/
s/FRAG_RESULT_COLR/FRAG_RESULT/COLOR/
Remove FRAG_RESULT_COLH (NV half-precision) output since we never used it.
Next, we might merge the COLOR and DATA outputs (COLOR0, COLOR1, etc).
|
|
Core mesa now unmaps the buffers if needed in these cases.
|
|
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
|
|
|
|
i965 doesn't natively support GL_CLAMP; it treats it like
GL_CLAMP_TO_EDGE, which fails conformance tests.
This fix adds a clause to the check_fallbacks() test to check
whether GL_CLAMP is in use on any enabled 2D texture. If so,
and if strict conformance is required (via INTEL_STRICT_CONFORMANCE),
a software fallback is mandated.
In addition, validate textures *before* checking for fallbacks,
rather than after; otherwise, the texture state is never validated
and can't be trusted. (In particular, if texturing is enabled and
the sampler would access any level beyond level 0 of a texture, the
sampler will segfault, because texture validation sets the firstLevel
and lastLevel fields of a texture object so that the valid levels
will be mapped and accessed correctly. If texture validation doesn't
occur, only level 0 is accessed correctly, and that only because
firstLevel and lastLevel happen to be set to 0.)
|
|
|
|
this makes glxgears get its background back when running under DRI2
|
|
|
|
It doesn't have to do anything. See comments for more details.
|
|
We can't render into any texture format; only certain formats.
Check that render-to-texture's format is renderable in the
intel_validate_framebuffer()
There seems to be a bug somewhere that causes rendering to rgb565 textures
to be corrupted so disallow that for now. This will be revisted.
|
|
|
|
Be a little more specific about what these are.
|
|
This doesn't seem to really effect anything but seeing width=0 in drawing
regions was confusing.
|
|
The i965 driver needs an extra instruction field for color output information.
It was using the Sampler field for this. Use the Aux field instead. This
will probaby be revisited at some point...
|
|
|
|
|
|
|
|
|
|
It is possible that an object whose vertices all are outside of a
view plane is passed to clip thread due to the RHW workaround. This
object should be rejected by clip thread. Fix bug #19879
|
|
|
|
While it's a nice idea to be able to allow clients to choose a smaller
(or bigger for 16bpp screens!) depth size, right now DRI2 hands back a buffer
with a size that matches the drawable, rather than being based off of the
visual. This led to problems in readback as parts of the driver disagreed
on what format the depth buffer was really in.
Fixes the remainder of bug #19447.
|
|
It seems that in this case the Mesa code is handing us x8z24 values instead
of z24s8 values, so we need to not do the rotation. Fixes half of OGLconform
depthrange.c.
Bug #19447.
|
|
This is insanity, but so is copying the same blocks containing the actual
interesting code in the file three times each for the different tile formats.
|
|
I was lured into a false sense of security by the fact that the spans code was
already there, and a bunch of tests didn't catch the problem. oglconform's
mask.c did, though.
Bug #19970.
|
|
|
|
|
|
|
|
This removes the use of the sarea for this stuff so makes DRI2 easier
and emits the CB/ZB info in the correct place
|
|
|
|
|
|
Flush the VAP the first time for each state atom we upload new
VAP data
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For some reason flushs caused by this CS needs flush hook,
caused the chip to lockup on r300 under compiz, whereas
the F10 driver was rock solid.
|
|
|
|
|
