Direct Rendering Infrastructure

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@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir Dergachev <volodya@...> wrote:

>    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.

Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.

Attached tarball contains test code I extracted from that paper and bunch of modifications.
Jerome Glisse(if im not mistaken) rolled up a lot cleaner version of it (see vprogram.c).
Spotlights should work as of todays Mesa cvs and software vertex shading as bug #3087 is resolved.
Keys 1, 2 and 3 switch between them.

> 
>    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

Branching could be interesting if older radeons would support such a thing.

> 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.

I dont think we need to sacrifice framerates here.
There are some one instruction saves like writing directly into result instead of using MOV from temp but those can probably be worked out with small hacks.

>                           best
> 
>                               Vladimir Dergachev
> 

-- 
Aapo Tahkola

On 4/21/05, Aapo Tahkola <aet@...> wrote:
> On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
> Vladimir Dergachev <volodya@...> wrote:
>=20
> >    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.
>=20
> Could work reasonably well. Problem with hashing all programs is that we =
would most likely have so many different programs that it would be undesira=
ble to keep them in memory. Take for example omiting tex coord transforms, =
rescaling of normals, normalization of normals..
> Sure we could just start dropping them but that might lead to instable fr=
amerates if we constantly translate new programs.
> I cant say I knew any really good way to handle this at the moment so its=
 probably best to try something and see what problems arise.

I was working on this too  but my new study keep me busy a bit.
Anyway i got a improved version of this and i think that the following
solution might well fit this problem.

We have to selected program according to this :
  - if no light of shade model =3D flat no lighting
    and so a simple program could do the work
    for all case (not looked at fog but i think that
    when we have flat shading fog haven't to be
   computed in the vertex shader (will look at
   spec for this))
- if light then we have to have something
  that hash all possible configuration.

Thus i think we better split the problem to choose
this for each enabled light and have invariant
program part.

-coordinate transformation and onfly
 texture coordinate transformation (should't
 consume too much time i think)
-normalize or rescale of normal (one state to parse)
-then for each enabled light we select
 the approriate routine add it
-we have an invariant program part at the
 end (which basicly compute the final color
 from all light computation previously done).

Moreover to have less state to parse we should
choose to always separate specular & diffuse
(Any reason to not do so ?)

Anyway here to make a decision, testing is definitly
needed.=20

> Attached tarball contains test code I extracted from that paper and bunch=
 of modifications.
> Jerome Glisse(if im not mistaken) rolled up a lot cleaner version of it (=
see vprogram.c).
> Spotlights should work as of todays Mesa cvs and software vertex shading =
as bug #3087 is resolved.
> Keys 1, 2 and 3 switch between them.

I have a new version of this vprogram which is even simpler at least i thin=
k.
I will post it tomorrow. And if i get enought time i will try come up with
an implementation in r300 to test my proposal.

Btw can we share things accross different context ? Basicly with
my proposal we would end up to have only 2-4 differente routine
corresponding to each possible case for a light. And some
common code at start & end, better to share but doesn't consume
so much memory less than 1ko i think...

I have been thinking to some similar think for the pixel shader, but
vertex first...

Jerome Glisse

Jerome Glisse wrote:
> On 4/21/05, Aapo Tahkola <aet@...> wrote:
> 
>>On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
>>Vladimir Dergachev <volodya@...> wrote:
>>
>>
>>>   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.
>>
>>Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
>>Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
>>I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.
> 
> 
> I was working on this too  but my new study keep me busy a bit.
> Anyway i got a improved version of this and i think that the following
> solution might well fit this problem.
> 
> We have to selected program according to this :
>   - if no light of shade model = flat no lighting
>     and so a simple program could do the work
>     for all case (not looked at fog but i think that
>     when we have flat shading fog haven't to be
>    computed in the vertex shader (will look at
>    spec for this))
> - if light then we have to have something
>   that hash all possible configuration.
> 
> Thus i think we better split the problem to choose
> this for each enabled light and have invariant
> program part.
> 
> -coordinate transformation and onfly
>  texture coordinate transformation (should't
>  consume too much time i think)
> -normalize or rescale of normal (one state to parse)
> -then for each enabled light we select
>  the approriate routine add it
> -we have an invariant program part at the
>  end (which basicly compute the final color
>  from all light computation previously done).
> 
> Moreover to have less state to parse we should
> choose to always separate specular & diffuse
> (Any reason to not do so ?)
> 
> Anyway here to make a decision, testing is definitly
> needed. 
> 
> 
>>Attached tarball contains test code I extracted from that paper and bunch of modifications.
>>Jerome Glisse(if im not mistaken) rolled up a lot cleaner version of it (see vprogram.c).
>>Spotlights should work as of todays Mesa cvs and software vertex shading as bug #3087 is resolved.
>>Keys 1, 2 and 3 switch between them.
> 
> 
> I have a new version of this vprogram which is even simpler at least i think.
> I will post it tomorrow. And if i get enought time i will try come up with
> an implementation in r300 to test my proposal.
> 
> Btw can we share things accross different context ? Basicly with
> my proposal we would end up to have only 2-4 differente routine
> corresponding to each possible case for a light. And some
> common code at start & end, better to share but doesn't consume
> so much memory less than 1ko i think...
> 
> I have been thinking to some similar think for the pixel shader, but
> vertex first...
> 

Seems like everyone's working on the same thing.  I've just committed a 
file which implements most of this internally in Mesa.  I've got a few 
other commits to make before it can be turned on, but it should be 
pretty much the facility you're looking for.

Keith

On Thu, 21 Apr 2005, Aapo Tahkola wrote:

> On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
> Vladimir Dergachev <volodya@...> wrote:
>
>>    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.
>
> Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
> Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
> I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.

Well, we know that the register space we are interested in is less than 4K.
A megabyte would hold 256 such configurations - should be plenty, no ?

                         best

                           Vladimir Dergachev

> Seems like everyone's working on the same thing.  I've just committed a
> file which implements most of this internally in Mesa.  I've got a few
> other commits to make before it can be turned on, but it should be
> pretty much the facility you're looking for.

Btw you are not working on same things for pixel shader (texture
filtering, multi-texture, ...) ? Thus doing all the code we need :)

Jerome Glisse

Jerome Glisse wrote:

>>Seems like everyone's working on the same thing.  I've just committed a
>>file which implements most of this internally in Mesa.  I've got a few
>>other commits to make before it can be turned on, but it should be
>>pretty much the facility you're looking for.
>>    
>>
>
>Btw you are not working on same things for pixel shader (texture
>filtering, multi-texture, ...) ? Thus doing all the code we need :)
>  
>
This would indeed be useful, as currently the i915 and r300 drivers
could both use common code for the fragment pipeline.

I'm almost certain that drivers for future hardware will also benefit
from having this functionality inside Mesa.

Cheers,
Ben Skeggs.


>Jerome Glisse
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: New Crystal Reports XI.
>Version 11 adds new functionality designed to reduce time involved in
>creating, integrating, and deploying reporting solutions. Free runtime info,
>new features, or free trial, at: http://www.businessobjects.com/devxi/728
>--
>_______________________________________________
>Dri-devel mailing list
>Dri-devel@...
>https://lists.sourceforge.net/lists/listinfo/dri-devel
>
>
>  
>

On Thu, 21 Apr 2005, Jerome Glisse wrote:

>> Seems like everyone's working on the same thing.  I've just committed a
>> file which implements most of this internally in Mesa.  I've got a few
>> other commits to make before it can be turned on, but it should be
>> pretty much the facility you're looking for.
>
> Btw you are not working on same things for pixel shader (texture
> filtering, multi-texture, ...) ? Thus doing all the code we need :)

No - I have not had a chance to do anything serious with R300 for few 
weeks..

                    best

                      Vladimri Dergachev

>
> Jerome Glisse
>

Jerome Glisse wrote:
>>Seems like everyone's working on the same thing.  I've just committed a
>>file which implements most of this internally in Mesa.  I've got a few
>>other commits to make before it can be turned on, but it should be
>>pretty much the facility you're looking for.
> 
> 
> Btw you are not working on same things for pixel shader (texture
> filtering, multi-texture, ...) ? Thus doing all the code we need :)

I probably will be adding such a thing in the not-too-distant future.

Note that the i915 driver already does this, building it's own internal 
program rather than a Mesa or ARB fragment program.

Keith

On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
Vladimir Dergachev <volodya@...> wrote:

> 
> 
> On Thu, 21 Apr 2005, Aapo Tahkola wrote:
> 
> > On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
> > Vladimir Dergachev <volodya@...> wrote:
> >
> >>    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.
> >
> > Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
> > Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
> > I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.
> 
> Well, we know that the register space we are interested in is less than 4K.
> A megabyte would hold 256 such configurations - should be plenty, no ?

Maybe for average case but not for worst.

Heres a list of problems that prevent r300 driver from using Keith's ffp program generator:
1. _TnlProgram is of fixed size type and smaller than r300_vertex_program 
2. Programs generated are incomplete in sense that they dont move input color to output(also applies to texture coords)
3. Number of temps exceeds 32 in some cases.

Attached patch temporarily fixes first two issues.

Problems on r300 side(that im aware of):
1. Multitexturing is broken on r300 side as texcoords regs arent properly asigned in r300_setup_rs_unit
2. Problems with colors applied to textures(see dinoshade).

Ill add something that allows to switch between hw and sw tnl on the fly using magic keys later today.

-- 
Aapo Tahkola

> Maybe for average case but not for worst.
>=20
> Heres a list of problems that prevent r300 driver from using Keith's ffp =
program generator:
> 1. _TnlProgram is of fixed size type and smaller than r300_vertex_program
> 2. Programs generated are incomplete in sense that they dont move input c=
olor to output(also applies to texture coords)
> 3. Number of temps exceeds 32 in some cases.
>=20
> Attached patch temporarily fixes first two issues.
>=20
> Problems on r300 side(that im aware of):
> 1. Multitexturing is broken on r300 side as texcoords regs arent properly=
 asigned in r300_setup_rs_unit
> 2. Problems with colors applied to textures(see dinoshade).

I haven't looked deeply in the code vp_build but i will take a deeper
look to it. I think we should really use somethings that mesa
provides as futur drivers will probably use such things.

>3. Number of temps exceeds 32 in some cases.

I astonished by the number of temp reg, there is a waste some
where i think.

I have little bit stoped my effort as it seems they are issue
with closed driver & vertex program (ati one) not providing
correct values in some case (really boring to debug). But i
will try to finish it at least it could be a good test program...

Jerome Glisse

On Sat, 30 Apr 2005 15:43:08 +0300
Aapo Tahkola <aet@...> wrote:

> Ill add something that allows to switch between hw and sw tnl on the fly using magic keys later today.

Attached offensive beast does this.
When compiled r300_tnl_switch.so is loaded with LD_PRELOAD, applications that use events to read keyboard input respond to F11 and F12 keys.

-- 
Aapo Tahkola

Aapo Tahkola wrote:
> On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
> Vladimir Dergachev <volodya@...> wrote:
> 
> 
>>
>>On Thu, 21 Apr 2005, Aapo Tahkola wrote:
>>
>>
>>>On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
>>>Vladimir Dergachev <volodya@...> wrote:
>>>
>>>
>>>>   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.
>>>
>>>Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
>>>Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
>>>I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.
>>
>>Well, we know that the register space we are interested in is less than 4K.
>>A megabyte would hold 256 such configurations - should be plenty, no ?
> 
> 
> Maybe for average case but not for worst.
> 
> Heres a list of problems that prevent r300 driver from using Keith's ffp program generator:
> 1. _TnlProgram is of fixed size type and smaller than r300_vertex_program 

What's the actual issue here?  In what circumstances does this cause a 
problem?

> 2. Programs generated are incomplete in sense that they dont move input color to output(also applies to texture coords)

The programs share the semantics of regular vertex programs - which 
don't do this copying either.  So, if you need to add this sort of 
copying when you encode a regular vertex program for the r300, you'll 
need to do the same thing with the generated programs.  If not, I don't 
understand what's going on.

> 3. Number of temps exceeds 32 in some cases.

Can you give some details?  I'm sure this can be pared down a little.

> Attached patch temporarily fixes first two issues.
> 
> Problems on r300 side(that im aware of):
> 1. Multitexturing is broken on r300 side as texcoords regs arent properly asigned in r300_setup_rs_unit
> 2. Problems with colors applied to textures(see dinoshade).
> 
> Ill add something that allows to switch between hw and sw tnl on the fly using magic keys later today.
> 

Keith

On Tue, 03 May 2005 14:59:53 +0100
Keith Whitwell <keith@...> wrote:

> Aapo Tahkola wrote:
> > On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
> > Vladimir Dergachev <volodya@...> wrote:
> > 
> > 
> >>
> >>On Thu, 21 Apr 2005, Aapo Tahkola wrote:
> >>
> >>
> >>>On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
> >>>Vladimir Dergachev <volodya@...> wrote:
> >>>
> >>>
> >>>>   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.
> >>>
> >>>Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
> >>>Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
> >>>I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.
> >>
> >>Well, we know that the register space we are interested in is less than 4K.
> >>A megabyte would hold 256 such configurations - should be plenty, no ?
> > 
> > 
> > Maybe for average case but not for worst.
> > 
> > Heres a list of problems that prevent r300 driver from using Keith's ffp program generator:
> > 1. _TnlProgram is of fixed size type and smaller than r300_vertex_program 
> 
> What's the actual issue here?  In what circumstances does this cause a 
> problem?

Mesa is holding drivers private data bound to programs in containers just like in i915NewProgram.
I suggest this to be sorted out by adding PrivatePrt to vertex and fragment program structures in Mesa.
This way drivers can allocate their private structures at translation stage and more better estimate needed memory.
Also this fits well into the hashing scheme when arb programs generated by t_vp_build.c could be destroyed once no longer needed.

> 
> > 2. Programs generated are incomplete in sense that they dont move input color to output(also applies to texture coords)
> 
> The programs share the semantics of regular vertex programs - which 
> don't do this copying either.  So, if you need to add this sort of 
> copying when you encode a regular vertex program for the r300, you'll 
> need to do the same thing with the generated programs.  If not, I don't 
> understand what's going on.

According to issue 16 of vertex_progra spec, initial values of temps and results are undefined unless written to.

> > 3. Number of temps exceeds 32 in some cases.
> 
> Can you give some details?  I'm sure this can be pared down a little.

Happened with ut2k4. Ill look into this at better time.

-- 
Aapo Tahkola

Aapo Tahkola wrote:
> On Tue, 03 May 2005 14:59:53 +0100
> Keith Whitwell <keith@...> wrote:
> 
> 
>>Aapo Tahkola wrote:
>>
>>>On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
>>>Vladimir Dergachev <volodya@...> wrote:
>>>
>>>
>>>
>>>>On Thu, 21 Apr 2005, Aapo Tahkola wrote:
>>>>
>>>>
>>>>
>>>>>On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
>>>>>Vladimir Dergachev <volodya@...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>  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.
>>>>>
>>>>>Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
>>>>>Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
>>>>>I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.
>>>>
>>>>Well, we know that the register space we are interested in is less than 4K.
>>>>A megabyte would hold 256 such configurations - should be plenty, no ?
>>>
>>>
>>>Maybe for average case but not for worst.
>>>
>>>Heres a list of problems that prevent r300 driver from using Keith's ffp program generator:
>>>1. _TnlProgram is of fixed size type and smaller than r300_vertex_program 
>>
>>What's the actual issue here?  In what circumstances does this cause a 
>>problem?
> 
> 
> Mesa is holding drivers private data bound to programs in containers just like in i915NewProgram.
> I suggest this to be sorted out by adding PrivatePrt to vertex and fragment program structures in Mesa.
> This way drivers can allocate their private structures at translation stage and more better estimate needed memory.
> Also this fits well into the hashing scheme when arb programs generated by t_vp_build.c could be destroyed once no longer needed.

Sounds reasonable - would you like to submit a patch for this?

> 
>>>2. Programs generated are incomplete in sense that they dont move input color to output(also applies to texture coords)
>>
>>The programs share the semantics of regular vertex programs - which 
>>don't do this copying either.  So, if you need to add this sort of 
>>copying when you encode a regular vertex program for the r300, you'll 
>>need to do the same thing with the generated programs.  If not, I don't 
>>understand what's going on.
> 
> 
> According to issue 16 of vertex_progra spec, initial values of temps and results are undefined unless written to.

Hmm, I think you're right...  I'll fix this up.

> 
>>>3. Number of temps exceeds 32 in some cases.
>>
>>Can you give some details?  I'm sure this can be pared down a little.
> 
> 
> Happened with ut2k4. Ill look into this at better time.
> 

Sounds like it's probably a leak somewhere.

Keith

Aapo Tahkola wrote:
> On Tue, 03 May 2005 14:59:53 +0100
> Keith Whitwell <keith@...> wrote:
> 
> 
>>Aapo Tahkola wrote:
>>
>>>On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
>>>Vladimir Dergachev <volodya@...> wrote:
>>>
>>>
>>>
>>>>On Thu, 21 Apr 2005, Aapo Tahkola wrote:
>>>>
>>>>
>>>>
>>>>>On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
>>>>>Vladimir Dergachev <volodya@...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>  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.
>>>>>
>>>>>Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
>>>>>Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
>>>>>I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.
>>>>
>>>>Well, we know that the register space we are interested in is less than 4K.
>>>>A megabyte would hold 256 such configurations - should be plenty, no ?
>>>
>>>
>>>Maybe for average case but not for worst.
>>>
>>>Heres a list of problems that prevent r300 driver from using Keith's ffp program generator:
>>>1. _TnlProgram is of fixed size type and smaller than r300_vertex_program 
>>
>>What's the actual issue here?  In what circumstances does this cause a 
>>problem?
> 
> 
> Mesa is holding drivers private data bound to programs in containers just like in i915NewProgram.
> I suggest this to be sorted out by adding PrivatePrt to vertex and fragment program structures in Mesa.
> This way drivers can allocate their private structures at translation stage and more better estimate needed memory.
> Also this fits well into the hashing scheme when arb programs generated by t_vp_build.c could be destroyed once no longer needed.

I think the issue is that I was creating the structures directly rather 
than calling ctx->Driver.NewProgram() to do this, as is the case with 
all other fragment & vertex programs.

I've changed this now and converted the i915 driver to use 
ctx->_TexEnvProgram (ie the fragment program) if MESA_TEX_PROG=t is set. 
  This seems to work fine.

The issue of creating/destroying the programs should probably be done at 
a higher level, ie in mesa/main/texenvprogram.c, so that drivers don't 
all end up with similar different hashing schemes.

Keith

On Mon, 09 May 2005 19:09:40 +0100
Keith Whitwell <keith@...> wrote:

> Aapo Tahkola wrote:
> > On Tue, 03 May 2005 14:59:53 +0100
> > Keith Whitwell <keith@...> wrote:
> > 
> > 
> >>Aapo Tahkola wrote:
> >>
> >>>On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
> >>>Vladimir Dergachev <volodya@...> wrote:
> >>>
> >>>
> >>>
> >>>>On Thu, 21 Apr 2005, Aapo Tahkola wrote:
> >>>>
> >>>>
> >>>>
> >>>>>On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
> >>>>>Vladimir Dergachev <volodya@...> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>  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.
> >>>>>
> >>>>>Could work reasonably well. Problem with hashing all programs is that we would most likely have so many different programs that it would be undesirable to keep them in memory. Take for example omiting tex coord transforms, rescaling of normals, normalization of normals..
> >>>>>Sure we could just start dropping them but that might lead to instable framerates if we constantly translate new programs.
> >>>>>I cant say I knew any really good way to handle this at the moment so its probably best to try something and see what problems arise.
> >>>>
> >>>>Well, we know that the register space we are interested in is less than 4K.
> >>>>A megabyte would hold 256 such configurations - should be plenty, no ?
> >>>
> >>>
> >>>Maybe for average case but not for worst.
> >>>
> >>>Heres a list of problems that prevent r300 driver from using Keith's ffp program generator:
> >>>1. _TnlProgram is of fixed size type and smaller than r300_vertex_program 
> >>
> >>What's the actual issue here?  In what circumstances does this cause a 
> >>problem?
> > 
> > 
> > Mesa is holding drivers private data bound to programs in containers just like in i915NewProgram.
> > I suggest this to be sorted out by adding PrivatePrt to vertex and fragment program structures in Mesa.
> > This way drivers can allocate their private structures at translation stage and more better estimate needed memory.
> > Also this fits well into the hashing scheme when arb programs generated by t_vp_build.c could be destroyed once no longer needed.
> 
> I think the issue is that I was creating the structures directly rather 
> than calling ctx->Driver.NewProgram() to do this, as is the case with 
> all other fragment & vertex programs.

Or that.

Heres a better version of the mov changes.
Changes to build_texture_transform should still break software tnl though.

> The issue of creating/destroying the programs should probably be done at 
> a higher level, ie in mesa/main/texenvprogram.c, so that drivers don't 
> all end up with similar different hashing schemes.

I agree.

-- 
Aapo Tahkola

Aapo Tahkola wrote:

>>>
>>>Mesa is holding drivers private data bound to programs in containers just like in i915NewProgram.
>>>I suggest this to be sorted out by adding PrivatePrt to vertex and fragment program structures in Mesa.
>>>This way drivers can allocate their private structures at translation stage and more better estimate needed memory.
>>>Also this fits well into the hashing scheme when arb programs generated by t_vp_build.c could be destroyed once no longer needed.
>>
>>I think the issue is that I was creating the structures directly rather 
>>than calling ctx->Driver.NewProgram() to do this, as is the case with 
>>all other fragment & vertex programs.
> 
> 
> Or that.
> 
> Heres a better version of the mov changes.
> Changes to build_texture_transform should still break software tnl though.
> 

Looks good, I'll apply this probably tomorrow morning.

I had some email problems yesterday & didn't see the first version.

Keith

Aapo Tahkola wrote:

>  static void build_passthrough( struct tnl_program *p, GLuint inputs )
>  {
> +   GLcontext *ctx = p->ctx;
> +   GLuint i, nr_lights = 0;
> +   
> +   if (ctx->Light.Enabled == GL_FALSE)
> +      emit_op1(p, VP_OPCODE_MOV, register_output(p, VERT_RESULT_COL0), 0,
> +			    register_input(p, VERT_ATTRIB_COLOR0));
> +   else {
> +     
> +      for (i = 0; i < MAX_LIGHTS; i++) 
> +         if (ctx->Light.Light[i].Enabled)
> +	   nr_lights++;
> +      
> +      if(nr_lights == 0) { /* Darkness */
> +         struct ureg dummy = register_input( p, VERT_ATTRIB_POS );
> +	 
> +         emit_op1(p, VP_OPCODE_MOV, register_output(p, VERT_RESULT_COL0), 0,
> +			      swizzle(dummy, ZERO, ZERO, ZERO, ZERO));

Slight problem with the above line - the "reduced swizzle" that arb_f_p 
allows you for arguments doesn't include the ZERO/ONE options, it's only 
  X,Y,Z,W and optional negation.  You can get the full swizzle with the 
SWZ instruction.  I'll fix this up, probably to use an explicit constant.

Keith