| Age | Commit message (Collapse) | Author |
|---|
|
This was causing hangs in cairogears, as we would blit to the 8bpp target
(A8 texture) as 16bpp, and stomp over state objects.
|
|
|
|
This can improve debugging with INTEL_DEBUG=batch,sync by giving smaller
batchbuffers.
|
|
I keep wanting to hack this knob in as a one-time thing, so it seemed useful
to have all the time.
|
|
|
|
The 3D destination shares the same cache so we don't have any trouble with
the later commands needing the writes flushed inside of the same batchbuffer.
|
|
|
|
front_region may be null.
|
|
The i965 hardware cannot do GL_CLAMP behavior on textures; an earlier
commit forced a software fallback if strict conformance was required
(i.e. the INTEL_STRICT_CONFORMANCE environment variable was set) and
2D textures were used, but it was somewhat flawed - it could trigger
the software fallback even if 2D textures weren't enabled, as long
as one texture unit was enabled.
This fixes that, and adds software fallback for GL_CLAMP behavior with
1D and 3D textures.
It also adds support for a particular setting of the INTEL_STRICT_CONFORMANCE
environment variable, which forces software fallbacks to be taken *all*
the time. This is helpful with debugging. The value is:
export INTEL_STRICT_CONFORMANCE=2
|
|
|
|
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.
|
|
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>
|
|
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.
|
|
|
|
This doesn't seem to really effect anything but seeing width=0 in drawing
regions was confusing.
|
|
|
|
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.
|
|
The intelImage also holds a reference to the miptree, so unref that as well.
|
|
This lets us avoid allocing new buffers for renderbuffers, finalized miptrees,
and PBO-uploaded textures when there's an unreferenced but still active one
cached, while also avoiding CPU waits for batchbuffers and CPU-uploaded
textures. The size of BOs allocated for a desktop running current GL
cairogears on i915 is cut in half with this.
Note that this means we require libdrm 2.4.5.
|
|
Fixes mysterious failures in glean glsl1 test.
|
|
This is a 2% win in fbo_firecube, and would avoid a sw fallback for
masked clears.
|
|
|
|
It's done in the Mesa GLSL compiler. The only part of it that might
matter in drivers is the centroid sampling option for MSAA.
|
|
While running conform with render-to-texture:
conform -d 33 -v 2 -t -direct
the i965 driver failed this assertion:
intel_clear.c:77: intel_clear_tris: Assertion `(mask & ~((1 << BUFFER_BACK_LEFT) | (1 << BUFFER_FRONT_LEFT) | (1 << BUFFER_DEPTH) | (1 << BUFFER_STENCIL))) == 0' failed.
The problem is that intel_clear_tris() is called by intelClear() to
clear any and all of the available color buffers, but intel_clear_tris()
actually only handles the back left and front left color buffers; so
the assertion fails as soon as you try to clear a non-standard color
buffer.
The fix is to have intelClear() only call intel_clear_tris() with
buffers that intel_clear_tris() can support. intelClear() already backs
down to _swrast_Clear() for all buffers that aren't handled explicitly.
|
|
This involved fixing driConcatConfigs to not return const (which had made a
mess of a previous patch too).
|
|
Everything other than "make sure the last rendering ends up visible on the
screen" doesn't need that behavior.
|
|
|
|
Found while debugging cairo-gl.
|
|
|
|
This is the big merge of the gallium-0.2 branch into master.
gallium-master-merge was just the staging area for it.
Both gallium-0.2 and gallium-master-merge are considered closed now.
Conflicts:
progs/demos/Makefile
src/mesa/main/state.c
src/mesa/main/texenvprogram.c
|
|
|
|
Add the MSAA samples array or make sure its contents are initialized.
|
|
Fixes bad background in all the progs/glsl/ tests.
|
|
(cherry picked from commit f7d80aa00611917bc8ce637136d982b151b8f44f)
This also involved adding the new MSAA fields to driCreateConfigs().
Also, re-add prog_instructions->Sampler field for i965 driver. Will
have to revisit that.
|
|
The MI opcodes have different variable length masks, so use an operand
specific mask to decode the length.
|
|
A couple of minor typos that proclaimed an error in the wrong command, and
failed to offset the mask.
|
|
By selecting a 4444 texture format due to a bad test, we hit the
intel_update_wrapper error path, and despite the appearance of error handling
in it and its callers, the desired behavior (software fallback) doesn't occur.
|
|
Too much commit -a while debugging.
|
|
|
|
No real-world impact on performance seen. Even glxgears seems to be, if
anything, happier.
|
|
This still leaves us with a broken depth 32 visual, but now it's the server's
visual setup that's at fault.
|
|
|
|
|
|
This is a 10% win on the ever-important glxgears not-a-benchmark.
|
|
This saves an inadvertent round-trip to the X Server on DrawBuffers, which was
hurting some metaops.
|
