After a discussion on #dri-devel about glPolygonOffset for R300 I'm filing an enhancement request. I was talking with aet and idr about this, and R300 must implement glPolygonOffset via a fragment program; or rather, modifying the existing fragment program. The thinking was that other hardware would be similar so this belongs in core Mesa, probably in texenvprogram.c. 17:22:56 <+idr> z3ro, aet: We just need a context flag so that the driver can tell core that fragprogs need to track polygon offset state. 17:23:17 <+idr> z3ro, aet: My suggestion would be to file an enhancement bug for it. 17:23:33 <+idr> z3ro, aet: I'm sure either Brian or keithw will have some implementation suggestions. I guess all that needs to be done is adding the value to result.depth when glPolygonOffset is enabled; I don't really know the details, I'm just filing the enhancement request.
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.
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.