Re: r300 fixed pipeline design
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
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
On Mon, 09 May 2005 19:09:40 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Tue, 03 May 2005 14:59:53 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT)
Vladimir Dergachev [EMAIL PROTECTED] wrote:
On Thu, 21 Apr 2005, Aapo Tahkola wrote:
On Wed, 23 Feb 2005 15:03:38 -0500 (EST)
Vladimir Dergachev [EMAIL PROTECTED] 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
Index: t_vp_build.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/tnl/t_vp_build.c,v
retrieving revision 1.10
diff -u -b -B -u -r1.10 t_vp_build.c
--- t_vp_build.c11 May 2005 15:18:59 - 1.10
+++ t_vp_build.c11 May 2005 16:12:55 -
@@ -103,6 +103,8 @@
#define YSWIZZLE_Y
#define ZSWIZZLE_Z
#define WSWIZZLE_W
+#define ONE SWIZZLE_ONE
+#define ZERO SWIZZLE_ZERO
/* Construct a ureg:
@@ -968,10 +970,11 @@
for (i = 0; i ctx-Const.MaxTextureCoordUnits; i++) {
struct gl_texture_unit *texUnit = ctx-Texture.Unit[i];
GLuint texmat_enabled = ctx-Texture._TexMatEnabled ENABLE_TEXMAT(i);
- struct ureg out = register_output(p, VERT_RESULT_TEX0 + i);
+ struct ureg out;
if (texUnit-TexGenEnabled || texmat_enabled) {
struct ureg out_texgen = undef;
+out = register_output(p, VERT_RESULT_TEX0 + i);
if (texUnit-TexGenEnabled) {
GLuint copy_mask = 0;
@@ -1095,6 +1098,35 @@
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));
+ }
+ }
+
+ for (i = 0; i ctx-Const.MaxTextureCoordUnits; i++) {
+ struct gl_texture_unit *texUnit = ctx-Texture.Unit[i];
+ GLuint texmat_enabled = ctx-Texture._TexMatEnabled ENABLE_TEXMAT(i);
+
+ if ((! (texUnit-TexGenEnabled || texmat_enabled))
texUnit-_ReallyEnabled) {
+struct ureg out = register_output(p, VERT_RESULT_TEX0 + i);
+emit_op1(p, VP_OPCODE_MOV, out, 0, register_input(p,
VERT_ATTRIB_TEX0+i));
+ }
+ }
}
Re: r300 fixed pipeline design
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 --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
Aapo Tahkola wrote: On Tue, 03 May 2005 14:59:53 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Thu, 21 Apr 2005 09:57:48 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Aapo Tahkola wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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 --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
Aapo Tahkola wrote: On Tue, 03 May 2005 14:59:53 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Thu, 21 Apr 2005 09:57:48 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Aapo Tahkola wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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 --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
Aapo Tahkola wrote: On Thu, 21 Apr 2005 09:57:48 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Aapo Tahkola wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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 --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
On Tue, 03 May 2005 14:59:53 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: On Thu, 21 Apr 2005 09:57:48 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Aapo Tahkola wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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 --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
On Sat, 30 Apr 2005 15:43:08 +0300 Aapo Tahkola [EMAIL PROTECTED] 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 r300_tnl_switch.tar.bz2 Description: Binary data
Re: r300 fixed pipeline design
On Thu, 21 Apr 2005 09:57:48 -0400 (EDT) Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Aapo Tahkola wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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 r300-fpl-mesa.patch Description: Binary data
Re: r300 fixed pipeline design
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). 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 --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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 fpl2.tar.bz2 Description: Binary data
Re: r300 fixed pipeline design
On 4/21/05, Aapo Tahkola [EMAIL PROTECTED] wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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... 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
Jerome Glisse wrote: On 4/21/05, Aapo Tahkola [EMAIL PROTECTED] wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
On Thu, 21 Apr 2005, Aapo Tahkola wrote: On Wed, 23 Feb 2005 15:03:38 -0500 (EST) Vladimir Dergachev [EMAIL PROTECTED] 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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
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 --- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
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_ide95alloc_id396op=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=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
