| Summary: | 956e6c3978abe918348377cf05e5c92971e50d3f breaks redbook texsub and texbind | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Alex Deucher <alexdeucher> |
| Component: | Mesa core | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Alex Deucher
2009-09-02 14:39:25 UTC
The textured quads show as solid white rather than as checkerboards. If you completely disable saturation (set saturate=0 at texenvprogram.c:1149) does that fix it? if so, could you check that prog_instruction::SaturateMode is implemented correctly in the driver? (In reply to comment #2) > If you completely disable saturation (set saturate=0 at texenvprogram.c:1149) > does that fix it? if so, could you check that prog_instruction::SaturateMode > is implemented correctly in the driver? > Disabling saturate in texenvprogram.c indeed fixes it. I'll check the driver. Thanks for the hint. I just added two more tests to glean's fragProg1 test to exercise saturation with ADD/SUB instructions. They might be helpful. The shader compiler appears to be doing the right thing for saturate. Disabling saturate in texenvprogram.c also fixes demos/texenv on r600. Please try the new glean test too. The fact that the texenvprogram saturate change didn't cause a regression with swrast, gallium or the i965 driver tells me it's a radeon issue. Strange. I ran the glean tests, and in both the ADD and SUB tests with saturation, mesa does set SaturateMode in the fragment instructions to anything other than 0 so the r600 shader compiler never sets the clamp bits in the instuctions. The results are identical with both ADD and ADD with saturation and SUB and SUB with saturation. Everything looks OK here. Running glean with swrast, the disassembled fragment shader for "ADD with saturation" is:
(gdb) call _mesa_print_program(program)
# Fragment Program/Shader
0: ADD TEMP[0], STATE[0], STATE[0];
1: ADD_SAT OUTPUT[1], TEMP[0], STATE[0];
2: END
(gdb) p program->Instructions[0]
$4 = {Opcode = OPCODE_ADD, SrcReg = {{File = 6, Index = 0, Swizzle = 1672,
RelAddr = 0, Abs = 0, Negate = 0}, {File = 6, Index = 0, Swizzle = 1672,
RelAddr = 0, Abs = 0, Negate = 0}, {File = 13, Index = 0,
Swizzle = 1672, RelAddr = 0, Abs = 0, Negate = 0}}, DstReg = {File = 0,
Index = 0, WriteMask = 15, RelAddr = 0, CondMask = 8, CondSwizzle = 1672,
CondSrc = 0, pad = 0}, CondUpdate = 0, CondDst = 0, SaturateMode = 0,
Precision = 1, TexSrcUnit = 0, TexSrcTarget = 0, TexShadow = 0,
BranchTarget = 0, Comment = 0x0, Data = 0x0, Aux = 0}
(gdb) p program->Instructions[1]
$5 = {Opcode = OPCODE_ADD, SrcReg = {{File = 0, Index = 0, Swizzle = 1672,
RelAddr = 0, Abs = 0, Negate = 0}, {File = 6, Index = 0, Swizzle = 1672,
RelAddr = 0, Abs = 0, Negate = 0}, {File = 13, Index = 0,
Swizzle = 1672, RelAddr = 0, Abs = 0, Negate = 0}}, DstReg = {File = 2,
Index = 1, WriteMask = 15, RelAddr = 0, CondMask = 8, CondSwizzle = 1672,
CondSrc = 0, pad = 0}, CondUpdate = 0, CondDst = 0, SaturateMode = 1,
Precision = 1, TexSrcUnit = 0, TexSrcTarget = 0, TexShadow = 0,
BranchTarget = 0, Comment = 0x0, Data = 0x0, Aux = 0}
Note that SaturateMode is correctly set to 1 in the second instruction.
I don't know how the r600 driver would be seeing anything different.
(In reply to comment #8) > Everything looks OK here. Running glean with swrast, the disassembled fragment > shader for "ADD with saturation" is: > > (gdb) call _mesa_print_program(program) > # Fragment Program/Shader > 0: ADD TEMP[0], STATE[0], STATE[0]; > 1: ADD_SAT OUTPUT[1], TEMP[0], STATE[0]; > 2: END [snip] > Note that SaturateMode is correctly set to 1 in the second instruction. > > I don't know how the r600 driver would be seeing anything different. Doesn't the r600 do some program transformations before generating actual machine code? My guess is that one of those transformations isn't copying the saturate bit. (In reply to comment #9) > > Doesn't the r600 do some program transformations before generating actual > machine code? My guess is that one of those transformations isn't copying the > saturate bit. > At the moment, it's pretty much a straight translation from mesa to machine code. AssembleInstr() in r700_assembler.c is the main workhorse. With gdb and/or a few calls to _mesa_print_program() at a few places you should be able to find where the Saturate setting is getting lost. seems to be working now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.