Hi Aapo,
I have been thinking about this as well - the current code is just the attempt to get multitexturing working a little bit, apparently there is some info that is missing from r300_reg.h, or perhaps I misunderstood something.
With regard to state switching, it might be worth it to simply hash various configuration (fog on /fog off, etc) and just upload state difference on such changes.
This would not be too complicated to implement, whatever the mechanism of shader generation.
Btw, another interesting link would be:
http://ati.com/developer/samples/dx9/FixedFuncShader.html
There is even some code to look at.
Lastly, if you are in the mood to play with this please do - there is nothing wrong with trying multiple approaches. The important code in R300
driver has already been rewritten several times (AOS code handling, primitive submissions paths, etc)
What worked for ATI will not necessarily work for us, as getting the last fps is not as important as having a stable and maintainable driver. Thus we can (and do need to) experiment.
best
Vladimir Dergachev
On Wed, 23 Feb 2005, Aapo Tahkola wrote:
Greetings all.
I noticed that the code generation for r300 fixed pipeline has just started and decided to start this discussion before the actual implementation gets going at full speed. To cut to the chase, I would like to suggest alternative implementation using mesas struct vertex_program as a placeholder for fragments. As a fragment I mean smallest possible piece of code that can be combined into final program. Some examples could be: directional light, exponental fog, ...
http://www.idi.ntnu.no/grupper/su/sif8094-reports/2002/p10.pdf should give you a some idea what I mean.
IMO pretty much only benefit that could be achieved by implementing fixed pipeline by using mesas structures and functions is its generality. You could make it run on any chip that supports vertex programs. And I do not only mean full pipeline but just eg. fog. Im pretty founded of the possibility that mesa could implement parts that driver wants as vertex program fallbacks like this. Im not saying that by drivers supporting vertex programs would give it support for these fallbacks as I dont think translation from mesas representation to chip specific form just isnt fast enough for single state changes. Therefore fragments should be translated into form that chip wants only once(during first state change) or upon context creation.
Completely different aproach would be to have only one fragment of each type and "call" them to get desired results. However I havent noticed anything in r300 that would even make this even close to possible. Though I think hardware vendors move into that direction sooner or later.
-- Aapo Tahkola
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
