Well aware of the problem. Radeons have very complex fog paths.

I'll assign this to myself, since I'm probably the only guy working on this.

*** Bug 17870 has been marked as a duplicate of this bug. ***

Created attachment 19424 [details] [review]
Partial possible fix

Chris, please search for existing bug reports before filing new ones.

FWIW, this happens since commit 19d77d6cfa384142cc6ab4d9b3db4b28cefb6f19 (temporarily set the FRAG_BIT_FOGC bit in InputsRead when fog is enabled). This patch allows some programs like mesa/progs/demos/teapot to work again, though they still complain:

*********************************WARN_ONCE*********************************
File r300_state.c function r300SetupRSUnit line 1756
Don't know how to satisfy InputsRead=0x00000008
***************************************************************************

So probably similar changes are needed in more places at least.

*** Bug 18242 has been marked as a duplicate of this bug. ***

*** Bug 18510 has been marked as a duplicate of this bug. ***

None of the reports seem to have a full backtrace, so here you go.  This is with the game 'rune'

Mesa 7.3-devel implementation error: radeon_program_pair.c::allocate_input_registers(): Don't know how to handle inputs 0x8


Please report at bugzilla.freedesktop.org
*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 354
Software fallback:!fp->translated
***************************************************************************
Mesa 7.3-devel implementation error: radeon_program_pair.c::allocate_input_registers(): Don't know how to handle inputs 0x8


Please report at bugzilla.freedesktop.org

Program received signal SIGSEGV, Segmentation fault.
0x02cdf172 in radeonWriteDepthSpan_z24_s8 (ctx=0xab57cb8, rb=0xae23b00, n=2, 
    x=326, y=733, values=0xbfff58e0, mask=0x0)
    at ../../../../../src/mesa/drivers/dri/common/depthtmp.h:61
61			     WRITE_DEPTH( x1, y, depth[i] );
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-5.i386 libXdamage-1.1.1-4.fc9.i386 libXxf86vm-1.0.2-1.fc10.i386 libdrm-2.4.0-0.21.fc10.i386 libselinux-2.0.73-1.fc10.i386
(gdb) bt
#0  0x02cdf172 in radeonWriteDepthSpan_z24_s8 (ctx=0xab57cb8, rb=0xae23b00, 
    n=2, x=326, y=733, values=0xbfff58e0, mask=0x0)
    at ../../../../../src/mesa/drivers/dri/common/depthtmp.h:61
#1  0x01b4f936 in depth_test_span (ctx=0xab57cb8, span=0xbfffdaa0)
    at swrast/s_depth.c:545
#2  0x01b5addb in _swrast_write_rgba_span (ctx=0xab57cb8, span=0xbfffdaa0)
    at swrast/s_span.c:1332
#3  0x01b718cd in general_triangle (ctx=0xab57cb8, v0=0x4f08020, v1=0x4f08168, 
    v2=0x4f082b0) at swrast/s_tritemp.h:862
#4  0x01b4e837 in _swrast_validate_triangle (ctx=0xab57cb8, v0=0x4f08020, 
    v1=0x4f08168, v2=0x4f082b0) at swrast/s_context.c:337
#5  0x01b4dce4 in _swrast_Triangle (ctx=0xab57cb8, v0=0x4f08020, v1=0x4f08168, 
    v2=0x4f082b0) at swrast/s_context.c:692
#6  0x01b7c33a in triangle_rgba (ctx=0xab57cb8, e0=0, e1=1, e2=2)
    at swrast_setup/ss_tritmp.h:188
#7  0x01b1b057 in _tnl_render_triangles_verts (ctx=0xab57cb8, start=0, 
    count=111, flags=52) at tnl/t_vb_rendertmp.h:163
#8  0x01b1c281 in run_render (ctx=0xab57cb8, stage=0xab9b3b4)
    at tnl/t_vb_render.c:320
#9  0x01b140cd in _tnl_run_pipeline (ctx=0xab57cb8) at tnl/t_pipeline.c:158
#10 0x01b14b18 in _tnl_draw_prims (ctx=0xab57cb8, arrays=0xab898c8, 
    prim=0xbfffe590, nr_prims=1, ib=0x0, min_index=0, max_index=110)
    at tnl/t_draw.c:402
#11 0x01b0c842 in vbo_exec_DrawArrays (mode=4, start=0, count=111)
    at vbo/vbo_exec_array.c:267
#12 0x05a88d89 in UOpenGLRenderDevice::EndBuffering () from ./OpenGLDrv.so
#13 0x05a822a4 in UOpenGLRenderDevice::PostDrawGouraud () from ./OpenGLDrv.so
#14 0x0066e876 in URender::DrawActorSprite () from ./Render.so
#15 0x0068ad60 in URender::DrawFrame () from ./Render.so
#16 0x0068c4b8 in URender::DrawWorld () from ./Render.so
#17 0x001f244a in UGameEngine::Draw () from ./Engine.so
#18 0x080d41c8 in ?? ()
#19 0x08f93e48 in ?? ()
#20 0x00000001 in ?? ()
#21 0x00000000 in ?? ()

*** Bug 18735 has been marked as a duplicate of this bug. ***

Created attachment 21798 [details] [review]
Revert two (errant) cherry-picks from gallium-0.2.

Okay, everybody CCed, please see if the following gets rid of the message and allows your apps to run at a normal-ish speed. I'm considering proposing this patch for Mesa 7.3, but I want to be sure it fixes other people's stuff too, first.

Do NOT help without r300-fogc.diff from Michel's Comment #3.

But with r300-fogc.diff ~mesa/progs/redbook/fog is wrong eq. no fog.

I'm not sure I agree with your reverts.

If a fragment program specifies the fog option, then the fogcoord input attribute _will_ be needed.  Not setting the FRAG_BIT_FOGC bit would seem to lead to other problems.  Namely, the fragment.fogcoord attribute may have an undefined value.

I think you're just patching over a deeper issue.

Looking in r300_state.c there's lots of tests for all the other fragment program inputs (like FRAG_BIT_TEX0) but FRAG_BIT_FOGC is never checked for.  That's a problem.  A fragment program can read the fragment.fogcoord value and use it for anything, not just fog.  Clearly, some new code is needed there.  I'll follow-up with a simple patch that at least silences the warnings.

Created attachment 21845 [details] [review]
silence fog warnings/errors in r300 driver (untested)

maybe an R300 user can give this a try.

(In reply to comment #10)
> I'm not sure I agree with your reverts.
> 
> If a fragment program specifies the fog option, then the fogcoord input
> attribute _will_ be needed.  Not setting the FRAG_BIT_FOGC bit would seem to
> lead to other problems.  Namely, the fragment.fogcoord attribute may have an
> undefined value.
> 
> I think you're just patching over a deeper issue.
> 
> Looking in r300_state.c there's lots of tests for all the other fragment
> program inputs (like FRAG_BIT_TEX0) but FRAG_BIT_FOGC is never checked for. 
> That's a problem.  A fragment program can read the fragment.fogcoord value and
> use it for anything, not just fog.  Clearly, some new code is needed there. 
> I'll follow-up with a simple patch that at least silences the warnings.
> 

Yep. I've been over that code quite a bit, tried many different ways to handle it.

The fundamental problem is that with our current setup, there's no way to "correctly" route fog coordinates every time, on every chipset. ("Correct" here could be as discrete coords, stuffed in texcoords, stuffed in color alpha, I've tried quite a bit.) I can't get it to work for every single path, and to be honest, I'm not sure if it's a limitation of the current setup, or if it's PEBKAC on my end.

At any rate, I had hoped that it would be possible to just ignore FOGC a bit further up the chain of command, but if not, then that's life. Obsoleting that patch.

~ C.

Comment #11 works on r300 (RV350 AS [Radeon 9550]).

Xorg.0.log
Chipset ATI Radeon 9600 AS (AGP) found

But ~/redbook/fog is wrong with it.

I've committed my suggested patch to mesa/master for the 7.3 release.

It would be nice if someone consolidated all the r300 fog bug reports into one.

(In reply to comment #15)
> I've committed my suggested patch to mesa/master for the 7.3 release.
Is it already in Mesa Master/7.3 RC3?

(In reply to comment #16)
> (In reply to comment #15)
> > I've committed my suggested patch to mesa/master for the 7.3 release.
> Is it already in Mesa Master/7.3 RC3?
> 

It was committed before 7.3-rc2:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=0dffd223491765fe572d606c2b10855cb568db7a

*** Bug 19932 has been marked as a duplicate of this bug. ***

Should be fixed in current master. Can you confirm?

Closing as fixed

Mass version move, cvs -> git