| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When doing line stipple, the stipple count resets on each line segment,
unless the primitive is a GL_LINE_LOOP or a GL_LINE_STRIP.
The existing code correctly identifies the need for a software fallback
to handle conformant line stipple on GL_LINE_LOOP primitives, but
neglects to make the same assessment on GL_LINE_STRIP primitives.
This fixes it so they match.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This trims down and cleans up imports.h and glheader.h quite a bit.
|
|
|
|
|
|
Just copy the whole struct.
|
|
|
|
Reported by cjb via tinderbox on irc
|
|
|
|
|
|
Plus, put them in the order of highest to lowest priority to simplify
the texture_override() loop.
|
|
Use loops to consolidate lots of texture object code.
|
|
Replace Default1D/2D/3D/Cube/etc with DefaultTex[TEXTURE_x_INDEX].
The same should be done with the Current1D/2D/3D/etc pointers...
|
|
New gl_texgen struct allows quite a bit of code reduction.
|
|
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.
|
|
We were asking for something illegal (write_domain != 0 && read_domains !=
write_domain) because at the time of writing the region surfaces were used
for texturing occasionally as well, and we weren't really clear on the model
GEM was going to use.
This reliably triggered a kernel bug with domain handling, resulting in
oglconform mustpass.c failure. Of course, it only became visible after
01bc4d441fd6821ad9fc20d5e9544e4e587e4ff0 cleaned up some gratuitous flushing.
|
|
instructions
These texture types were defined but never put to use.
For the time being though, the Mesa->TGSI translater isn't emitting these
targets. See the XXX comment in map_texture_target().
|
|
GLSL shadow() sampler calls are properly propogated down to the driver now.
The glean glsl1 shadow() tests work (except for the alpha channel).
|
|
Note that I24X8 vs. A24X8 vs. L24X8 doesn't seem to make any difference
for texture/shadow compare, however.
|
|
Such TEX instructions will have the TexShadow flag set.
The gl_program::ShadowSamplers field is now set in the linker. We missed
that before.
|
|
If the instruction is TEX/TXP/TXL/etc the TexShadow field will be true if
the instruction is a texture fetch with shadow compare.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes mysterious failures in glean glsl1 test.
|
|
|
|
|
|
|
|
Since Ian's patch of a few weeks ago, we can enable all three variations
of two-sided stencil. Update the state tracker to handle the extra back-
face state and turn on the EXT.
Note: there's a new Glean test for two-sided stencil now...
|
|
|
|
Back-face stencil operations didn't work correctly because this value was
zero. It needs to be 1 or 2. The only place it's set otherwise is in
glEnable/Disable(GL_STENCIL_TEST_TWO_SIDE_EXT).
|
|
|
|
|
|
Move the is_boolean/integer_type() calls out of the loops.
Move the is_sampler_type() function near the bool/int functions.
Add a bunch of comments.
|
|
We were off by one when checking for too many uniform values.
|
|
If the vertex shader writes to a varying array with a variable index,
mark all the elements of that array as being written.
For example, if the vertex shader does:
for (i = 0; i < 4; i++)
gl_TexCoord[i] = expr;
Mark all texcoord outputs as being written, not just the first.
Linking will fail if a fragment shader tries to read an input that's not
written by the vertex shader. Before this fix, this linker test could fail.
|
|
Obviously, the color of fragments produced by DrawPixels is not constant,
even if the current vertex array / vertex program state indicates that the
color for normal rendering will be constant. Therefore, we need to override
certain optimisations that have been added to texenvprogram.c
Signed-off-by: Nicolai Haehnle <nhaehnle@gmail.com>
|
|
|
|
Old limit was 256. Note that no arrays are declared to this size.
The only place we have to be careful about raising this limit is the
prog_src/dst_register Index bitfields. These have been bumped up too.
Added assertions to check we don't exceed the bitfield in the future too.
|
|
This new issue was exposed by commit 6eabfc27f19a10dfc2663e99f9560966ba1ff697
|
