Bug 9710

Added CC for Brian Paul due to IRC conversation. I forgot to do this initially.

Added CC for Keith due to IRC conversation. I forgot to do this initially.

While it might be possible to implement offset this way, most hardware has
dedicated support for it elsewhere.  Most probably this is because running a
fragment program which modifies the depth value forces the hardware to turn off
all sorts of early-Z and hyper-Z optimizations.

Are you certain that the hardware you're looking at (r300?) needs to implement
offset this way?  

ALSO: texenvprogram.c isn't the right place to do this as it won't help the
cases where a client-supplied fragment program is in use.  It seems more likely
that it would be necessary to append some instructions to the compiled program
to implement depth offset.  You wouldn't want to do this to the core mesa
program as it would depend on whether offset were enabled or not, better add a
dependency within the driver to make program (re)compilation dependent on
polygon offset state.

DOUBLE-ALSO:  I'm not sure that you can get all the gradient information
necessary to perform the calculations in the fragment program.  So you may just
end up unable to do it.

I'm not sure this is a good way to go about doing offset.  Probably any sane
hardware will have support for it in a different, fixed-functionality place.

I'm leaving the bug as NEW, but if you agree, please set to WONTFIX or similar.

Well, I agree maybe core mesa isn't the correct place for this... I'm just reporting based on the discussion I had with aet and idr on #dri-devel.  I think that you wouldn't need to regenerate the fragment program at all; just make it use some local parameters or similar...  Do you think it would be better to assign this to r300 and do the fragprog hacking in the r300 driver? 

I don't think it should be done in the fragment program at all, unless there is
strong evidence that this is the only way to achieve the effect on this hardware...

I am sure that doing it this way will be slow, not because of the extra few
instructions in the fragment program, but because it will force the hardware to
disable early z testing and similar optimizations.

My recommendation is to look harder for dedicated support for offset in the
hardware.  There should be at least some as DX9 has something similar to OpenGL
z-offset.

This is likely somethings we miss, it seems r300 reg file have some
information on register 0x42B4 which might be involved in this offset
things. I guess that before we go further with this we need to figure
out what fglrx do with the card in such case.

(In reply to comment #3)
> While it might be possible to implement offset this way, most hardware has
> dedicated support for it elsewhere.  Most probably this is because running a
> fragment program which modifies the depth value forces the hardware to turn off
> all sorts of early-Z and hyper-Z optimizations.
> 
> Are you certain that the hardware you're looking at (r300?) needs to implement
> offset this way?  
> 
> ALSO: texenvprogram.c isn't the right place to do this as it won't help the
> cases where a client-supplied fragment program is in use.  It seems more likely
> that it would be necessary to append some instructions to the compiled program
> to implement depth offset.  You wouldn't want to do this to the core mesa
> program as it would depend on whether offset were enabled or not, better add a
> dependency within the driver to make program (re)compilation dependent on
> polygon offset state.
> 
> DOUBLE-ALSO:  I'm not sure that you can get all the gradient information
> necessary to perform the calculations in the fragment program.  So you may just
> end up unable to do it.
> 
> I'm not sure this is a good way to go about doing offset.  Probably any sane
> hardware will have support for it in a different, fixed-functionality place.

r300 has had glPolygonOffset support for as long as its been able to run q3.
Anyway, there are couple other extenssions where we would need to poke
t_vp_build.c to get things going. We, for instance, have to use 2 as base in
fogc calculations instead of Euler's number.