| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The polygon stipple pattern, like the viewport and the
polygon face orientation, must be inverted on the i965
when rendering to a FBO (which itself has an inverted pixel
coordinate system compared to raw Mesa).
In addition, the polygon stipple offset, which orients
the stipple to the window system, disappears when rendering
to an FBO (because the window system offset doesn't apply,
and there's no associated FBO offset).
With these fixes, the conform triangle and polygon stipple
tests pass when rendering to texture.
|
|
|
|
In the i965, the FBO coordinate system is inverted from the standard
OpenGL/Mesa coordinate system; that means that the viewport and the
polygon face orientation have to be inverted if rendering to a FBO.
The viewport was already being handled correctly; but polygon face
was not. This caused a conform failure when rendering to texture with
two-sided lighting enabled.
This fixes the problem in the i965 driver, and adds to the comment about
the gl_framebuffer "Name" field so that this isn't a surprise to other
driver writers.
|
|
It seems the code that set up the FB_WRITE message was incomplete in this
case. The number of payload registers was wrong and that caused a hang.
It would be good to have a second set of eyes take a look at this...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If we're using anything but GL_NEAREST sampling of a cube map, we need to
use the BRW_TEXCOORDMODE_CUBE texcoord wrap mode. Before this, the GPU
would either lock up or subsequent texture filtering would be corrupted.
|
|
Before this change we would up emitting instructions with invalid register
numbers. This typically (but not always) hung the GPU. For now, just
prevent emitting bad instructions to avoid hangs. Still need to do some
kind of proper error recovery.
|
|
This is the size of the intermediate instruction buffer.
|
|
|
|
|
|
This function scans the shader to see if it has any GLSL features like
conditionals and loops. Calling this during state validation is expensive.
Just call it when the shader is given to the driver and save the result.
There's some new/temporary assertions to be sure we don't get out of sync
on this.
|
|
|
|
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.
|
|
|
|
|
|
Instructions such as RCP, RSQ, LOG must smear the result of the function
across the dest register's X, Y, Z and W channels (subject to write masking).
Before this change, only the X component was getting written.
Among other things, this fixes cube map texture sampling in GLSL shaders
(since cube lookups involve normalizing the texcoord).
|
|
Plus fix up a debug printf.
|
|
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
|
|
|
|
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).
|
|
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.)
|
|
Be a little more specific about what these are.
|
|
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
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Noticed this with the fbotexture demo.
|
|
|
|
The default for EmitCondCodes got flipped when gallium-0.2 was merged.
This fixes GLSL if/else/endif regressions.
Drivers that use GLSL should always explicitly set the flag to be safe.
|
|
Previously, the prog_instruction::Data field was used to map original Mesa
instructions to brw instructions in order to resolve subroutine calls. This
was a rather tangled mess. Plus it's an obstacle to implementing dynamic
allocation/growing of the instruction buffer (it's still a fixed size).
Mesa's GLSL compiler emits a label for each subroutine and CAL instruction.
Now we use those labels to patch the subroutine calls after code generation
has been done. We just keep a list of all CAL instructions that needs patching
and a list of all subroutine labels. It's a simple matter to resolve them.
This also consolidates some redundant post-emit code between brw_vs_emit.c and
brw_wm_glsl.c and removes some loops that cleared the prog_instruction::Data
fields at the end.
Plus, a bunch of new comments.
|
|
This doesn't effect correctness, but we were emitting an extraneous ADD.
|
|
|
|
|
