Direct Rendering Infrastructure

Vladimir Dergachev wrote:
> 
> Turns out small modification of single texture pixel shader was all 
> required to get alpha channel working in textures.
> 
> I retagged jump_and_click, q3demo is now definitely playable, albeit
> burn marks are screwed up for some reason - possibly because we do not 
> handle Polygon.OffsetFill ?

That would do it.  You are probably seeing some wierd diagonal stripy 
patterns in the burn marks, or maybe they vanish altogether sometimes?

If so, that's polygon offset.

> Also, there is some sort of weird bug where textures with alpha are 
> checkered - there are rectangles missing in a checkered pattern, which 
> is most visible on large letters.

Can't help you with that one.

Keith

On Tue, 1 Feb 2005, Keith Whitwell wrote:

> Vladimir Dergachev wrote:
>> 
>> Turns out small modification of single texture pixel shader was all 
>> required to get alpha channel working in textures.
>> 
>> I retagged jump_and_click, q3demo is now definitely playable, albeit
>> burn marks are screwed up for some reason - possibly because we do not 
>> handle Polygon.OffsetFill ?
>
> That would do it.  You are probably seeing some wierd diagonal stripy 
> patterns in the burn marks, or maybe they vanish altogether sometimes?

Some triangles vanish occasionally as if they are located slightly 
underneath the surface they are drawn on. I guess fill offset is supposed 
to lift them slightly.

Would you know whether a card with programmable shader pipeline would 
implement it as part of vertex shader program or have dedicated hardware ?

                           thank you !

                                Vladimir Dergachev

Vladimir Dergachev wrote:
> 
> 
> On Tue, 1 Feb 2005, Keith Whitwell wrote:
> 
>> Vladimir Dergachev wrote:
>>
>>>
>>> Turns out small modification of single texture pixel shader was all 
>>> required to get alpha channel working in textures.
>>>
>>> I retagged jump_and_click, q3demo is now definitely playable, albeit
>>> burn marks are screwed up for some reason - possibly because we do 
>>> not handle Polygon.OffsetFill ?
>>
>>
>> That would do it.  You are probably seeing some wierd diagonal stripy 
>> patterns in the burn marks, or maybe they vanish altogether sometimes?
> 
> 
> Some triangles vanish occasionally as if they are located slightly 
> underneath the surface they are drawn on. I guess fill offset is 
> supposed to lift them slightly.
> 
> Would you know whether a card with programmable shader pipeline would 
> implement it as part of vertex shader program or have dedicated hardware ?

The radeons & r200's have dedicated hardware for it.

It would be hard to implement in a vertex shader as it pertains to 
triangles (effectively random triplets of vertices) which aren't in 
existence at that point in the pipeline.  So it almost certainly has to 
be done post-vertex-shader.

Could it be done in the pixel shader?  Somewhat unlikely as well as the 
calculations rely on values that probably don't make it that far down 
the pipeline.

It's really a triangle-setup step, my guess is that there will be 
dedicated hardware for it.

Keith

>>> patterns in the burn marks, or maybe they vanish altogether sometimes?
>> 
>> 
>> Some triangles vanish occasionally as if they are located slightly 
>> underneath the surface they are drawn on. I guess fill offset is supposed 
>> to lift them slightly.
>> 
>> Would you know whether a card with programmable shader pipeline would 
>> implement it as part of vertex shader program or have dedicated hardware ?
>
> The radeons & r200's have dedicated hardware for it.
>
> It would be hard to implement in a vertex shader as it pertains to triangles 
> (effectively random triplets of vertices) which aren't in existence at that 
> point in the pipeline.  So it almost certainly has to be done 
> post-vertex-shader.
>
> Could it be done in the pixel shader?  Somewhat unlikely as well as the 
> calculations rely on values that probably don't make it that far down the 
> pipeline.
>
> It's really a triangle-setup step, my guess is that there will be dedicated 
> hardware for it.

Great - thank you !

                     Vladimir Dergachev

>
> Keith
>

Vladimir Dergachev wrote:
 >
 > Turns out small modification of single texture pixel shader was all
 > required to get alpha channel working in textures.
 >
 > I retagged jump_and_click, q3demo is now definitely playable, albeit
 > burn marks are screwed up for some reason - possibly because we do not
 > handle Polygon.OffsetFill ?
 >
 > Also, there is some sort of weird bug where textures with alpha are
 > checkered - there are rectangles missing in a checkered pattern, which
 > is most visible on large letters.

Very nice.

Though I'm missing som textures. Allways the same, and the missing are 
all above arches.
Also the podium looks a bit strange.

screenshot:
http://home19.inet.tele.dk/runner/images/shot0000.png

Rune Petersen

On Tue, 1 Feb 2005, Rune Petersen wrote:

> Vladimir Dergachev wrote:
>>
>> Turns out small modification of single texture pixel shader was all
>> required to get alpha channel working in textures.
>>
>> I retagged jump_and_click, q3demo is now definitely playable, albeit
>> burn marks are screwed up for some reason - possibly because we do not
>> handle Polygon.OffsetFill ?
>>
>> Also, there is some sort of weird bug where textures with alpha are
>> checkered - there are rectangles missing in a checkered pattern, which
>> is most visible on large letters.
>
> Very nice.
>
> Though I'm missing som textures. Allways the same, and the missing are all 
> above arches.
> Also the podium looks a bit strange.

I see similar issues. I think alpha is still screwed up somehow.
If you hit ` to bring up console you will see that the transparency is 
achieved by a dithered effect, rather than being a "true" transparency.

The only change I made to get this is an alpha instruction in 
r300_fixed_pipelines.h (search for #if 0, you'll see commented out old 
code and new one just below).

I think one can play with this rather safely - I would expect no lockups 
no matter what values you put it, albeit Quake could become unreadable.

                          best

                             Vladimir Dergachev

>
> screenshot:
> http://home19.inet.tele.dk/runner/images/shot0000.png
>
> Rune Petersen
>

Vladimir Dergachev wrote:
> I see similar issues. I think alpha is still screwed up somehow.
> If you hit ` to bring up console you will see that the transparency is 
> achieved by a dithered effect, rather than being a "true" transparency.
> 
> The only change I made to get this is an alpha instruction in 
> r300_fixed_pipelines.h (search for #if 0, you'll see commented out old 
> code and new one just below).
> 
> I think one can play with this rather safely - I would expect no lockups 
> no matter what values you put it, albeit Quake could become unreadable.
> 

I had a go at it. The only useful information I found was that the 
"Quake III" logo in the menu is viewable by adding SRC2A, but not 
without corruption of everything else.
Also the rockets smoke-trail is missing most of the time.

Rune Petersen

On Wed, 2 Feb 2005, Rune Petersen wrote:

> Vladimir Dergachev wrote:
>> I see similar issues. I think alpha is still screwed up somehow.
>> If you hit ` to bring up console you will see that the transparency is 
>> achieved by a dithered effect, rather than being a "true" transparency.
>> 
>> The only change I made to get this is an alpha instruction in 
>> r300_fixed_pipelines.h (search for #if 0, you'll see commented out old code 
>> and new one just below).
>> 
>> I think one can play with this rather safely - I would expect no lockups no 
>> matter what values you put it, albeit Quake could become unreadable.
>> 
>
> I had a go at it. The only useful information I found was that the "Quake 
> III" logo in the menu is viewable by adding SRC2A, but not without corruption 
> of everything else.
> Also the rockets smoke-trail is missing most of the time.

One thing you might try is to exchange the order of arguments or do 
something similar. There are some comments by Nicolai on ordering of 
arguments in r300_reg.h, these might reflect actual hardware limitations.

For example, I do not understand why in flat texture shader one has to 
have two identical instructions and why the first and last instructions in
single texture shader are identical as well.

                       best

                         Vladimir Dergachev

>
> Rune Petersen
>

Vladimir Dergachev wrote:
> 
> One thing you might try is to exchange the order of arguments or do 
> something similar. There are some comments by Nicolai on ordering of 
> arguments in r300_reg.h, these might reflect actual hardware limitations.
> 
> For example, I do not understand why in flat texture shader one has to 
> have two identical instructions and why the first and last instructions in
> single texture shader are identical as well.

I couldn't find a combination that makes alpha look any better and got 
angry at the identical instructions which didn't do anything.
So I removed them.
I don't se any problem without these innstuctions. unless there are 
special cases. q3a and NeHe lessons 2-20 don't look any worse.

Rune Petersen

On Thu, 3 Feb 2005, Rune Petersen wrote:

> Vladimir Dergachev wrote:
>> 
>> One thing you might try is to exchange the order of arguments or do 
>> something similar. There are some comments by Nicolai on ordering of 
>> arguments in r300_reg.h, these might reflect actual hardware limitations.
>> 
>> For example, I do not understand why in flat texture shader one has to have 
>> two identical instructions and why the first and last instructions in
>> single texture shader are identical as well.
>
> I couldn't find a combination that makes alpha look any better and got angry 
> at the identical instructions which didn't do anything.
> So I removed them.
> I don't se any problem without these innstuctions. unless there are special 
> cases. q3a and NeHe lessons 2-20 don't look any worse.

Hmm.. This is puzzling.

One more thing - try to compare console in quake (you can bring it up by 
pressing `) in game and end-game modes. On my computer it displays fine 
during the game (properly blended) but is "dithered" in end-game screen, 
even though I would expect quake to use the same code for displaying both.

                        best

                           Vladimir Dergachev

>
> Rune Petersen
>

On Thu, 3 Feb 2005, Rune Petersen wrote:

> Vladimir Dergachev wrote:
>> 
>> One thing you might try is to exchange the order of arguments or do 
>> something similar. There are some comments by Nicolai on ordering of 
>> arguments in r300_reg.h, these might reflect actual hardware limitations.
>> 
>> For example, I do not understand why in flat texture shader one has to have 
>> two identical instructions and why the first and last instructions in
>> single texture shader are identical as well.
>
> I couldn't find a combination that makes alpha look any better and got angry 
> at the identical instructions which didn't do anything.
> So I removed them.
> I don't se any problem without these innstuctions. unless there are special 
> cases. q3a and NeHe lessons 2-20 don't look any worse.

You are quite right - also the following instruction:

 	{
 	EASY_PFS_INSTR0(MAD, SRC0C_XYZ, ONE, ZERO),
 	EASY_PFS_INSTR1(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, NONE, ALL),
 	EASY_PFS_INSTR2(MAD, SRC0A, ONE, ZERO),
 	EASY_PFS_INSTR3(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, OUTPUT)
 	}

looks like a NOP ( it basically does reg0<-reg0*1+0.0 ).

                   best

                      Vladimir Dergachev

>
> Rune Petersen
>

Rune Petersen wrote:
> Vladimir Dergachev wrote:
> 
>>
>> One thing you might try is to exchange the order of arguments or do 
>> something similar. There are some comments by Nicolai on ordering of 
>> arguments in r300_reg.h, these might reflect actual hardware limitations.
>>
>> For example, I do not understand why in flat texture shader one has to 
>> have two identical instructions and why the first and last 
>> instructions in
>> single texture shader are identical as well.
> 
> 
> I couldn't find a combination that makes alpha look any better and got 
> angry at the identical instructions which didn't do anything.
> So I removed them.
> I don't se any problem without these innstuctions. unless there are 
> special cases. q3a and NeHe lessons 2-20 don't look any worse.

I haven't looked at the r300 code as it's not in Mesa CVS, but I'm 
wondering if you've noticed that the i915 driver does a similar task of 
converting fixed function GL to a programable fragment shader backend?

It may be a bit late in the day, but there might still be a couple of 
things to pick up from looking at that code.

Keith

On Thu, 03 Feb 2005 08:51:31 +0000, Keith Whitwell
<keith@...> wrote:
> Rune Petersen wrote:
> > Vladimir Dergachev wrote:
> >
> >>
> >> One thing you might try is to exchange the order of arguments or do
> >> something similar. There are some comments by Nicolai on ordering of
> >> arguments in r300_reg.h, these might reflect actual hardware limitations.
> >>
> >> For example, I do not understand why in flat texture shader one has to
> >> have two identical instructions and why the first and last
> >> instructions in
> >> single texture shader are identical as well.
> >
> >
> > I couldn't find a combination that makes alpha look any better and got
> > angry at the identical instructions which didn't do anything.
> > So I removed them.
> > I don't se any problem without these innstuctions. unless there are
> > special cases. q3a and NeHe lessons 2-20 don't look any worse.
> 
> I haven't looked at the r300 code as it's not in Mesa CVS, but I'm
> wondering if you've noticed that the i915 driver does a similar task of
> converting fixed function GL to a programable fragment shader backend?
> 
> It may be a bit late in the day, but there might still be a couple of
> things to pick up from looking at that code.
> 
> Keith
> 
> 

maybe it makes sense to start including r300 in mesa.  You guys have
made a lot of progress.  It doesn't have to be built by default, and
the development can still happen in r300 cvs (just sync them from time
to time), but it might help with the testing since snapshots would be
made nightly.  OTOH, it's still fairly experimental.

Alex

On Thu, 3 Feb 2005, Keith Whitwell wrote:

> Rune Petersen wrote:
>> Vladimir Dergachev wrote:
>> I couldn't find a combination that makes alpha look any better and got 
>> angry at the identical instructions which didn't do anything.
>> So I removed them.
>> I don't se any problem without these innstuctions. unless there are special 
>> cases. q3a and NeHe lessons 2-20 don't look any worse.
>
> I haven't looked at the r300 code as it's not in Mesa CVS, but I'm wondering 
> if you've noticed that the i915 driver does a similar task of converting 
> fixed function GL to a programable fragment shader backend?
>
> It may be a bit late in the day, but there might still be a couple of things 
> to pick up from looking at that code.

Great, thank you ! I'll take a look at it..

                        best

                          Vladimir Dergachev



>
> Keith
>

> You are quite right - also the following instruction:
> 
>     {
>     EASY_PFS_INSTR0(MAD, SRC0C_XYZ, ONE, ZERO),
>     EASY_PFS_INSTR1(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, NONE, 
> ALL),
>     EASY_PFS_INSTR2(MAD, SRC0A, ONE, ZERO),
>     EASY_PFS_INSTR3(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, OUTPUT)
>     }
> 
> looks like a NOP ( it basically does reg0<-reg0*1+0.0 ).

with some more testing I found:
- FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen 
to avoid corruption. Can you add these NOPs only when resizing? =)

- SINGLE_TEXTURE_VERTEX_SHADER needs 1 NOP to get q3a to work for me.
   else get a blank screen. The game runs fine I just can't see anything.
   The NOP might be needed for the initial setup.

Rune Petersen

On Thu, 3 Feb 2005, Rune Petersen wrote:

>
>> You are quite right - also the following instruction:
>> 
>>     {
>>     EASY_PFS_INSTR0(MAD, SRC0C_XYZ, ONE, ZERO),
>>     EASY_PFS_INSTR1(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, NONE, 
>> ALL),
>>     EASY_PFS_INSTR2(MAD, SRC0A, ONE, ZERO),
>>     EASY_PFS_INSTR3(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, OUTPUT)
>>     }
>> 
>> looks like a NOP ( it basically does reg0<-reg0*1+0.0 ).
>
> with some more testing I found:
> - FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen to 
> avoid corruption. Can you add these NOPs only when resizing? =)

Not really, but this might indicate a sort of bandwidth issue - one part 
is issuing pixels faster than the other part can receive. What resolution 
are you running at ?

>
> - SINGLE_TEXTURE_VERTEX_SHADER needs 1 NOP to get q3a to work for me.
>  else get a blank screen. The game runs fine I just can't see anything.
>  The NOP might be needed for the initial setup.

This can also be fixed by setting alu_offset field to 0 instead of 1 - 
apparently it is an offset into alu program.

I missed it on my last commit, as reducing the length of the program did 
not overwrite previous instruction 1.

Also, if one believes alu_end then it says that the length of the program
is 1 in both cases and thus PFS_NOP pruning has mostly cosmetic effect.

                           best

                             Vladimir Dergachev

>
> Rune Petersen
>

Vladimir Dergachev wrote:
>> with some more testing I found:
>> - FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full 
>> screen to avoid corruption. Can you add these NOPs only when resizing? =)
> 
> 
> Not really, but this might indicate a sort of bandwidth issue - one part 
> is issuing pixels faster than the other part can receive. What 
> resolution are you running at ?

X is 1280x1024 and the lessons uses 640x480 in full screen.

Rune Petersen

On Thu, 3 Feb 2005, Rune Petersen wrote:

> Vladimir Dergachev wrote:
>>> with some more testing I found:
>>> - FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen to 
>>> avoid corruption. Can you add these NOPs only when resizing? =)
>> 
>> 
>> Not really, but this might indicate a sort of bandwidth issue - one part is 
>> issuing pixels faster than the other part can receive. What resolution are 
>> you running at ?
>
> X is 1280x1024 and the lessons uses 640x480 in full screen.

I put back a single PFS_NOP as the syntax does not allow for less than 1 
instruction (alu_end==0 corresponds to 1 instruction).

Does this fix things for you ?

I do not see any issues when running with large windows (1920x1200 X 
resolution), so this could be connected to page flipping instead.

                          best

                            Vladimir Dergachev

>
> Rune Petersen
>

Vladimir Dergachev wrote:
>>
>> X is 1280x1024 and the lessons uses 640x480 in full screen.
> 
> 
> I put back a single PFS_NOP as the syntax does not allow for less than 1 
> instruction (alu_end==0 corresponds to 1 instruction).
You are right, but why do we get away with having 0 tex instruction? 
It should be under the same restrictions.
> 
> Does this fix things for you ?
No, I need 2.
> 
> I do not see any issues when running with large windows (1920x1200 X 
> resolution), so this could be connected to page flipping instead.

I think it could be related to me using DVI. the Radeon DVI-code seams 
buggy my monitor is reporting running at 1279x1023.

Rune Petersen

Rune Petersen wrote:

>> looks like a NOP ( it basically does reg0<-reg0*1+0.0 ).
> 
> with some more testing I found:
> - FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen 
> to avoid corruption. Can you add these NOPs only when resizing? =)
> 
> - SINGLE_TEXTURE_VERTEX_SHADER needs 1 NOP to get q3a to work for me.
>   else get a blank screen. The game runs fine I just can't see anything.
>   The NOP might be needed for the initial setup.

It could be that the hardware "consumes" instructions in fixed-size 
groups.  It may need instuctions that use results from previous 
instructions to be in different groups.  In other words, it may be 
somewhat VLIW in nature.  Would that explain the need for some of these 
funky nops?

On Thu, 3 Feb 2005, Rune Petersen wrote:

> > You are quite right - also the following instruction:
> > 
> >     {
> >     EASY_PFS_INSTR0(MAD, SRC0C_XYZ, ONE, ZERO),
> >     EASY_PFS_INSTR1(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, NONE, 
> > ALL),
> >     EASY_PFS_INSTR2(MAD, SRC0A, ONE, ZERO),
> >     EASY_PFS_INSTR3(0, 0, 0 | PFS_FLAG_CONST, 0 | PFS_FLAG_CONST, OUTPUT)
> >     }
> > 
> > looks like a NOP ( it basically does reg0<-reg0*1+0.0 ).
> 
> with some more testing I found:
> - FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen 
> to avoid corruption. Can you add these NOPs only when resizing? =)
> 
> - SINGLE_TEXTURE_VERTEX_SHADER needs 1 NOP to get q3a to work for me.
>    else get a blank screen. The game runs fine I just can't see anything.
>    The NOP might be needed for the initial setup.

	Makes sense... if you have to have all instructions take one cycle
scheduling wise, but some need more, then you need NOPs.  Since this
instruction system wasn't designed to be programmed directly by end users,
it didn't bother the hardware designers ;) 

	One of these days I'd like to check this driver out - I have a
radeon 9500non-pro and a 9800pro, although my main box has a gf6800...

	- Chad
 
> Rune Petersen
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

On Thu, 3 Feb 2005, Rune Petersen wrote:

> Vladimir Dergachev wrote:
>>> 
>>> X is 1280x1024 and the lessons uses 640x480 in full screen.
>> 
>> 
>> I put back a single PFS_NOP as the syntax does not allow for less than 1 
>> instruction (alu_end==0 corresponds to 1 instruction).
> You are right, but why do we get away with having 0 tex instruction? It 
> should be under the same restrictions.

There is a special bit that tells whether node0 has texture instructions - 
it is not set for FLAT_COLOR_PIPELINE.

>> 
>> Does this fix things for you ?
> No, I need 2.

Do you still see the same problem by stretching the window as large as it 
can be ?

                     best

                       Vladimir Dergachev

>> 
>> I do not see any issues when running with large windows (1920x1200 X 
>> resolution), so this could be connected to page flipping instead.
>
> I think it could be related to me using DVI. the Radeon DVI-code seams buggy 
> my monitor is reporting running at 1279x1023.
>
> Rune Petersen
>

On Thu, 3 Feb 2005, Ian Romanick wrote:

> Rune Petersen wrote:
>
>>> looks like a NOP ( it basically does reg0<-reg0*1+0.0 ).
>> 
>> with some more testing I found:
>> - FLAT_COLOR_PIXEL_SHADER needs 2 NOP when resizing window->full screen to 
>> avoid corruption. Can you add these NOPs only when resizing? =)
>> 
>> - SINGLE_TEXTURE_VERTEX_SHADER needs 1 NOP to get q3a to work for me.
>>   else get a blank screen. The game runs fine I just can't see anything.
>>   The NOP might be needed for the initial setup.
>
> It could be that the hardware "consumes" instructions in fixed-size groups. 
> It may need instuctions that use results from previous instructions to be in 
> different groups.  In other words, it may be somewhat VLIW in nature.  Would 
> that explain the need for some of these funky nops?

Yes, except we have only one instruction to begin with.

Rune, does the fix with alu_offset=0 work for you ?

                        thank you !

                            Vladimir Dergachev

>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Vladimir Dergachev wrote:

> Yes, except we have only one instruction to begin with.
> 
> Rune, does the fix with alu_offset=0 work for you ?

Yes this is my fault. I forgot to put it in writing.
yes the alu_offset fixed the problem.


Rune Petersen

Vladimir Dergachev wrote:
> 
> 
> On Thu, 3 Feb 2005, Rune Petersen wrote:
> 
>> Vladimir Dergachev wrote:
>>
>>>>
>>>> X is 1280x1024 and the lessons uses 640x480 in full screen.
>>>
>>>
>>>
>>> I put back a single PFS_NOP as the syntax does not allow for less 
>>> than 1 instruction (alu_end==0 corresponds to 1 instruction).
>>
>> You are right, but why do we get away with having 0 tex instruction? 
>> It should be under the same restrictions.
> 
> 
> There is a special bit that tells whether node0 has texture instructions 
> - it is not set for FLAT_COLOR_PIPELINE.
> 
>>>
>>> Does this fix things for you ?
>>
>> No, I need 2.
> 
> 
> Do you still see the same problem by stretching the window as large as 
> it can be ?

there are no problems with stretching the window

I've experimented and found that 2 NOPs doesn't really help.
if I set full screen to be the LCDs native resolution it happens less often.
I think this problem DVI-related. Until I or someone else can show the 
problem is with the r300 code you should leave this alone.

Do you know who is responsible for the DVI-code?

Rune Petersen

>>>> 
>>>> Does this fix things for you ?
>>> 
>>> No, I need 2.
>> 
>> 
>> Do you still see the same problem by stretching the window as large as it 
>> can be ?
>
> there are no problems with stretching the window
>
> I've experimented and found that 2 NOPs doesn't really help.
> if I set full screen to be the LCDs native resolution it happens less often.
> I think this problem DVI-related. Until I or someone else can show the 
> problem is with the r300 code you should leave this alone.

You can try to resize the screen to check whether this problem occurs in 
2d as well. (You can use xrandr or KDE resize app for that).

>
> Do you know who is responsible for the DVI-code?

No idea.

                       best

                         Vladimir Dergachev

>
> Rune Petersen
>

On Thu, 03 Feb 2005 19:44:57 +0100, Rune Petersen <runner@...> wrote:
> Vladimir Dergachev wrote:
> >
> >
> > On Thu, 3 Feb 2005, Rune Petersen wrote:
> >
> >> Vladimir Dergachev wrote:
> >>
> >>>>
> >>>> X is 1280x1024 and the lessons uses 640x480 in full screen.
> >>>
> >>>
> >>>
> >>> I put back a single PFS_NOP as the syntax does not allow for less
> >>> than 1 instruction (alu_end==0 corresponds to 1 instruction).
> >>
> >> You are right, but why do we get away with having 0 tex instruction?
> >> It should be under the same restrictions.
> >
> >
> > There is a special bit that tells whether node0 has texture instructions
> > - it is not set for FLAT_COLOR_PIPELINE.
> >
> >>>
> >>> Does this fix things for you ?
> >>
> >> No, I need 2.
> >
> >
> > Do you still see the same problem by stretching the window as large as
> > it can be ?
> 
> there are no problems with stretching the window
> 
> I've experimented and found that 2 NOPs doesn't really help.
> if I set full screen to be the LCDs native resolution it happens less often.
> I think this problem DVI-related. Until I or someone else can show the
> problem is with the r300 code you should leave this alone.
> 
> Do you know who is responsible for the DVI-code?
> 

lots of people have touched that.  it could be related to the display
buffer watermark code. perhaps it needs some tweaks for your chip. 
take a look at radeon_driver.c::RADEONInitDispBandwidth()
it looks like the r420 isn't supported quite yet:
    /* R420 family not supported yet */
    if (info->ChipFamily == CHIP_FAMILY_R420) return; 

Alex

Alex Deucher wrote:
> On Thu, 03 Feb 2005 19:44:57 +0100, Rune Petersen <runner@...> wrote:
>>
>>Do you know who is responsible for the DVI-code?
>>
> 
> 
> lots of people have touched that.  it could be related to the display
> buffer watermark code. perhaps it needs some tweaks for your chip. 
> take a look at radeon_driver.c::RADEONInitDispBandwidth()
> it looks like the r420 isn't supported quite yet:
>     /* R420 family not supported yet */
>     if (info->ChipFamily == CHIP_FAMILY_R420) return; 
> 
> Alex
> 
Thank you, I'll have a look.
I have support via a hack, it is detected as an CHIP_FAMILY_RV350 =)

Rune Petersen

Rune Petersen wrote:
> Alex Deucher wrote:
> 
>> On Thu, 03 Feb 2005 19:44:57 +0100, Rune Petersen 
>> <runner@...> wrote:
>>
>>>
>>> Do you know who is responsible for the DVI-code?
>>>
>>
>>
>> lots of people have touched that.  it could be related to the display
>> buffer watermark code. perhaps it needs some tweaks for your chip. 
>> take a look at radeon_driver.c::RADEONInitDispBandwidth()
>> it looks like the r420 isn't supported quite yet:
>>     /* R420 family not supported yet */
>>     if (info->ChipFamily == CHIP_FAMILY_R420) return;
>> Alex
>>
> Thank you, I'll have a look.
> I have support via a hack, it is detected as an CHIP_FAMILY_RV350 =)

Sorry for the noise. only dri is hacked.
someone with CVS write access please remove the lines:
      /* R420 family not supported yet */
      if (info->ChipFamily == CHIP_FAMILY_R420) return;

I don't see any improvement other than my monitor now reports the 
correct resolution.

Rune Petersen

Vladimir Dergachev wrote:
>> there are no problems with stretching the window
>>
>> I've experimented and found that 2 NOPs doesn't really help.
>> if I set full screen to be the LCDs native resolution it happens less 
>> often.
>> I think this problem DVI-related. Until I or someone else can show the 
>> problem is with the r300 code you should leave this alone.
> 
> 
> You can try to resize the screen to check whether this problem occurs in 
> 2d as well. (You can use xrandr or KDE resize app for that).
> 

I tried KDE and I found no problems resizing.


Rune Petersen

On Fri, 4 Feb 2005, Rune Petersen wrote:

> Vladimir Dergachev wrote:
>>> there are no problems with stretching the window
>>> 
>>> I've experimented and found that 2 NOPs doesn't really help.
>>> if I set full screen to be the LCDs native resolution it happens less 
>>> often.
>>> I think this problem DVI-related. Until I or someone else can show the 
>>> problem is with the r300 code you should leave this alone.
>> 
>> 
>> You can try to resize the screen to check whether this problem occurs in 2d 
>> as well. (You can use xrandr or KDE resize app for that).
>> 
>
> I tried KDE and I found no problems resizing.

Next step is to try some sort of 2d DGA applications (wesnoth ? SDL ?) and 
see if the problem is still there. Maybe it is only DGA that is broken.

                          best

                             Vladimir Dergachev

>
>
> Rune Petersen
>

Vladimir Dergachev wrote:
> 
> 
> On Fri, 4 Feb 2005, Rune Petersen wrote:
> 
>> Vladimir Dergachev wrote:
>>
>>>> there are no problems with stretching the window
>>>>
>>>> I've experimented and found that 2 NOPs doesn't really help.
>>>> if I set full screen to be the LCDs native resolution it happens 
>>>> less often.
>>>> I think this problem DVI-related. Until I or someone else can show 
>>>> the problem is with the r300 code you should leave this alone.
>>>
>>>
>>>
>>> You can try to resize the screen to check whether this problem occurs 
>>> in 2d as well. (You can use xrandr or KDE resize app for that).
>>>
>>
>> I tried KDE and I found no problems resizing.
> 
> 
> Next step is to try some sort of 2d DGA applications (wesnoth ? SDL ?) 
> and see if the problem is still there. Maybe it is only DGA that is broken.
> 
window->full screen works with wesnoth.

Rune Petersen

>>> special cases. q3a and NeHe lessons 2-20 don't look any worse.
>>
>> I haven't looked at the r300 code as it's not in Mesa CVS, but I'm
>> wondering if you've noticed that the i915 driver does a similar task of
>> converting fixed function GL to a programable fragment shader backend?
>>
>> It may be a bit late in the day, but there might still be a couple of
>> things to pick up from looking at that code.
>>
>> Keith
>>
>>
>
> maybe it makes sense to start including r300 in mesa.  You guys have
> made a lot of progress.  It doesn't have to be built by default, and
> the development can still happen in r300 cvs (just sync them from time
> to time), but it might help with the testing since snapshots would be
> made nightly.  OTOH, it's still fairly experimental.

Sorry did not reply earlier, I had to take some time to think about this.

The biggest reason at the moment against including R300 driver in Mesa CVS
is that the code is a mess. There are r200 files that are not being used 
in any way and large sections of code simply cut'n'pasted from R200 driver 
with pieces commented out to allow everything to compile.

Once proper vertex upload code has been put in this could be cleaned up, 
improper code removed and the driver would be in a much better shape.

This would be needed not to just get the code "respectable" but to get an 
overview which features are working, which are half done and which are 
lacking altogether.

The second big reason is that we cannot simply include Mesa driver alone - 
it would have to be accompanied by changes to the DRM driver. R300 DRM 
driver is stabilized as far as experimental development is concerned, but 
it is far from perfect from security standpoint (we basically allow almost 
arbitrary commands as we did not know what we would need when we started).

                             best

                                Vladimir Dergachev

>
> Alex
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

On Friday 04 February 2005 15:26, Vladimir Dergachev wrote:
> > maybe it makes sense to start including r300 in mesa.  You guys have
> > made a lot of progress.  It doesn't have to be built by default, and
> > the development can still happen in r300 cvs (just sync them from time
> > to time), but it might help with the testing since snapshots would be
> > made nightly.  OTOH, it's still fairly experimental.
>
> Sorry did not reply earlier, I had to take some time to think about this.
>
> The biggest reason at the moment against including R300 driver in Mesa CVS
> is that the code is a mess. There are r200 files that are not being used
> in any way and large sections of code simply cut'n'pasted from R200 driver
> with pieces commented out to allow everything to compile.

I would really like to see the r300 code not get its own driver.  Unified=20
drivers are a good thing, and radeon/r200 is bad enough.  Unfortunately I=20
don't know a good way to make sure they don't diverge more than they alread=
y=20
have.  I think the current development method is working fine for now, but=
=20
that the end goal should be to fold the r300 code back into r200.

> The second big reason is that we cannot simply include Mesa driver alone -
> it would have to be accompanied by changes to the DRM driver. R300 DRM
> driver is stabilized as far as experimental development is concerned, but
> it is far from perfect from security standpoint (we basically allow almost
> arbitrary commands as we did not know what we would need when we started).

Here again, ideally this would get folded upstream too, once it's at least=
=20
secure.

I can't really mandate a policy since I haven't been contributing much to=20
r300, but I would like to hear how people think this should progress.

=2D aajx

On Fri, 4 Feb 2005, Adam Jackson wrote:

> On Friday 04 February 2005 15:26, Vladimir Dergachev wrote:
>>> maybe it makes sense to start including r300 in mesa.  You guys have
>>> made a lot of progress.  It doesn't have to be built by default, and
>>> the development can still happen in r300 cvs (just sync them from time
>>> to time), but it might help with the testing since snapshots would be
>>> made nightly.  OTOH, it's still fairly experimental.
>>
>> Sorry did not reply earlier, I had to take some time to think about this.
>>
>> The biggest reason at the moment against including R300 driver in Mesa CVS
>> is that the code is a mess. There are r200 files that are not being used
>> in any way and large sections of code simply cut'n'pasted from R200 driver
>> with pieces commented out to allow everything to compile.
>
> I would really like to see the r300 code not get its own driver.  Unified
> drivers are a good thing, and radeon/r200 is bad enough.  Unfortunately I
> don't know a good way to make sure they don't diverge more than they already
> have.  I think the current development method is working fine for now, but
> that the end goal should be to fold the r300 code back into r200.
>
>> The second big reason is that we cannot simply include Mesa driver alone -
>> it would have to be accompanied by changes to the DRM driver. R300 DRM
>> driver is stabilized as far as experimental development is concerned, but
>> it is far from perfect from security standpoint (we basically allow almost
>> arbitrary commands as we did not know what we would need when we started).
>
> Here again, ideally this would get folded upstream too, once it's at least
> secure.
>
> I can't really mandate a policy since I haven't been contributing much to
> r300, but I would like to hear how people think this should progress.

Folding DRM driver is not difficult, in fact currently there is just one 
extra file with r300-specific code.

As for folding R300 driver, we'll see how things turn out. It is hard 
for me to imagine how this folding could take place - albeit it might turn 
out to be not too bad.

An incomplete list of issues:

      * shaders are different from R200 hardware
      * the hardware state is different with registers in different
        locations.

        So R200 code like

 	    rmesa->hw.ctx.cmd[CTX_RB3D_CNTL] & ~R200_PLANE_MASK_ENABLE;

        won't work as there is no RB3D_CNTL that we know of.

        It is really quite bad - there are numerous R300 registers with
        offsets above 0x4000 while the largest R200 register I see used in
        Mesa driver is R200_RB3D_CBLENDCNTL at offset 0x3220.

      * I don't think we need software TCL code to be separate - as I
        understand this code is in R200 driver because initial driver
        did not support hardware TCL. (We do not support it either, yet)

So unifying would require thorough understanding of both hardware 
platforms and Mesa drivers in general, and will likely imply a rewrite of
large portions of both drivers.

On the other hand, the texture allocation code can be shared almost 
entirely. Vertex processing can also be shared with small effort - albeit 
it would be nicer to use one of the templates, if any are available for 
that purpose.

                          best

                             Vladimir Dergachev

>
> - aajx
>

On Friday 04 February 2005 21:52, Vladimir Dergachev wrote:
> On Fri, 4 Feb 2005, Adam Jackson wrote:
> > Here again, ideally this would get folded upstream too, once it's at
> > least secure.
> >
> > I can't really mandate a policy since I haven't been contributing much
> > to r300, but I would like to hear how people think this should progress.
>=20
> Folding DRM driver is not difficult, in fact currently there is just one=
=20
> extra file with r300-specific code.
>=20
> As for folding R300 driver, we'll see how things turn out. It is hard=20
> for me to imagine how this folding could take place - albeit it might tur=
n=20
> out to be not too bad.

You know, I actually started the r300 driver with this in mind, which is wh=
y=20
you'll still see all those r200_* files around. The thing is, I neither=20
have the hardware to test whether it still works on R200, nor can I=20
currently contribute much to development.

It really shouldn't require a complete rewrite, just a lot of careful (and=
=20
tedious) refactoring.

cu,
Nicolai

Adam Jackson wrote:
> I would really like to see the r300 code not get its own driver.  Unified 
> drivers are a good thing, and radeon/r200 is bad enough.  Unfortunately I 
> don't know a good way to make sure they don't diverge more than they already 
> have.  I think the current development method is working fine for now, but 
> that the end goal should be to fold the r300 code back into r200.
> 
> 
>>The second big reason is that we cannot simply include Mesa driver alone -
>>it would have to be accompanied by changes to the DRM driver. R300 DRM
>>driver is stabilized as far as experimental development is concerned, but
>>it is far from perfect from security standpoint (we basically allow almost
>>arbitrary commands as we did not know what we would need when we started).
> 
> 
> Here again, ideally this would get folded upstream too, once it's at least 
> secure.
> 
> I can't really mandate a policy since I haven't been contributing much to 
> r300, but I would like to hear how people think this should progress.

I'm not so convinced that r200 and r300 driver (and radeon, for that 
matter) really should be only one driver. Why is it that bad to have 3 
drivers? Those chips just ARE different. Sure, the 2d parts are more or 
less identical and certainly should be only one driver, but that's 
already the case. DRM should probably be the same too, since the 
differences needed are pretty much limited to what packets it accepts.
But I'm not exactly sure how you'd unify the dri code. While you cannot 
deny that the drivers indeed look very similar, there are still a lot of 
differences. You will inevitably end up with lots of "if Radeon do that, 
else" code (or did you have #ifdef's in mind, so you would share the 
same source files, but would compile it to 3 targets in the end?).
So you might be able to unify them, but I'd bet it won't look pretty.
Of course, it depends on how dissimilar the chips actually are. IMHO the 
differences between radeon and r200 are too big to make unifying 
worthwile, I have only looked at the r300 driver briefly but the 
differences to r200 seem to be quite large too.
As a side note, last time I checked ATI had 3 Direct3d drivers for the 
chips too. They have a unified package to install, and they may (no 
idea) share large parts of source code, but there are 3 distinct dlls in 
the end.

Roland

On Friday 04 February 2005 16:17, Roland Scheidegger wrote:
> Adam Jackson wrote:
> > I can't really mandate a policy since I haven't been contributing much =
to
> > r300, but I would like to hear how people think this should progress.
>
> I'm not so convinced that r200 and r300 driver (and radeon, for that
> matter) really should be only one driver. Why is it that bad to have 3
> drivers? Those chips just ARE different. Sure, the 2d parts are more or
> less identical and certainly should be only one driver, but that's
> already the case. DRM should probably be the same too, since the
> differences needed are pretty much limited to what packets it accepts.
> But I'm not exactly sure how you'd unify the dri code. While you cannot
> deny that the drivers indeed look very similar, there are still a lot of
> differences. You will inevitably end up with lots of "if Radeon do that,
> else" code (or did you have #ifdef's in mind, so you would share the
> same source files, but would compile it to 3 targets in the end?).

No, definitely not #ifdef hell, down that road lies madness.

We have this already though, in several drivers.  Savage3D and Savage4, Int=
el=20
830/855/915, Voodoo3 and Voodoo4/5 even.  And I would expect that the=20
differences in features between chips corresponds well to GL features for t=
he=20
most part, so they're natural boundaries for conditionals anyway.

> So you might be able to unify them, but I'd bet it won't look pretty.
> Of course, it depends on how dissimilar the chips actually are. IMHO the
> differences between radeon and r200 are too big to make unifying
> worthwile, I have only looked at the r300 driver briefly but the
> differences to r200 seem to be quite large too.

Documentation would be a large help here of course.  Have any of the r300=20
developers asked ATI for the 3d docs?  Or even unbowdlerised r200 docs.  Th=
at=20
would help greatly in seeing whether, for example, some of the r300 registe=
rs=20
are also present on r200 and we just don't know it, per Vladimir's example=
=20
earlier in the thread.

> As a side note, last time I checked ATI had 3 Direct3d drivers for the
> chips too. They have a unified package to install, and they may (no
> idea) share large parts of source code, but there are 3 distinct dlls in
> the end.

Direct3D drivers are not really an apples-to-apples comparison since they'l=
l=20
try to factor out as many conditionals as possible for that last 0.03fps in=
=20
3dmark.  fglrx is probably a more fair comparison, and fglrx covers r200=20
through r400 no problem.  If we assume that that's the more maintainable=20
solution from ATI's perspective, I have trouble seeing how distinct drivers=
=20
would be more maintainable for us.

As an example of what the non-unified road looks like, look at the glide=20
source.  Despite successive chips being pretty much strict supersets in ter=
ms=20
of functionality, they clone the entire tree for each chip.  I suspect the=
=20
effort required to keep drivers unified is worth it in the long run.

=2D ajax

Adam Jackson wrote:
> On Friday 04 February 2005 15:26, Vladimir Dergachev wrote:
> 
>>The biggest reason at the moment against including R300 driver in Mesa CVS
>>is that the code is a mess. There are r200 files that are not being used
>>in any way and large sections of code simply cut'n'pasted from R200 driver
>>with pieces commented out to allow everything to compile.
> 
> I would really like to see the r300 code not get its own driver.  Unified 
> drivers are a good thing, and radeon/r200 is bad enough.  Unfortunately I 
> don't know a good way to make sure they don't diverge more than they already 
> have.  I think the current development method is working fine for now, but 
> that the end goal should be to fold the r300 code back into r200.

I agree.  I think the i915 / i830 driver provides a good model.  In that 
driver you have two different groups of files.  On group contains the 
code that is the same for both drivers and is name <vendor>_*.[ch].  The 
other group contains the code that is specific to each chip and is named 
<chip>_*.[ch].

Since most of the driver is driven by function pointers, the only place 
that has any 'if (this_chip) { foo; } else if (that_chip) { bar; }' is, 
if I'm not mistaken, in the context creation code.

Adam Jackson wrote:
> On Friday 04 February 2005 16:17, Roland Scheidegger wrote:
 >
> Direct3D drivers are not really an apples-to-apples comparison since they'll 
> try to factor out as many conditionals as possible for that last 0.03fps in 
> 3dmark.  fglrx is probably a more fair comparison, and fglrx covers r200 
> through r400 no problem.  If we assume that that's the more maintainable 
> solution from ATI's perspective, I have trouble seeing how distinct drivers 
> would be more maintainable for us.
> 
> As an example of what the non-unified road looks like, look at the glide 
> source.  Despite successive chips being pretty much strict supersets in terms 
> of functionality, they clone the entire tree for each chip.  I suspect the 
> effort required to keep drivers unified is worth it in the long run.
>

the way I see it is that there needs very good reasons for merging 
drivers. not just for the sake of merging.

My understanding is that r200 and r300 have very different interfaces. 
You only improve maintainability for code shared between the drivers.
So the question should be how much are the drivers alike.

>
>> So you might be able to unify them, but I'd bet it won't look pretty.
>> Of course, it depends on how dissimilar the chips actually are. IMHO the
>> differences between radeon and r200 are too big to make unifying
>> worthwile, I have only looked at the r300 driver briefly but the
>> differences to r200 seem to be quite large too.
>
> Documentation would be a large help here of course.  Have any of the r300
> developers asked ATI for the 3d docs?  Or even unbowdlerised r200 docs.  That
> would help greatly in seeing whether, for example, some of the r300 registers
> are also present on r200 and we just don't know it, per Vladimir's example
> earlier in the thread.

I asked ATI for 3d documentation early of summer 2004, as far as I know 
they have not decided yet. They did provide 2d documentation for R300 
chips.

>
>> As a side note, last time I checked ATI had 3 Direct3d drivers for the
>> chips too. They have a unified package to install, and they may (no
>> idea) share large parts of source code, but there are 3 distinct dlls in
>> the end.
>
> Direct3D drivers are not really an apples-to-apples comparison since they'll
> try to factor out as many conditionals as possible for that last 0.03fps in
> 3dmark.  fglrx is probably a more fair comparison, and fglrx covers r200
> through r400 no problem.  If we assume that that's the more maintainable
> solution from ATI's perspective, I have trouble seeing how distinct drivers
> would be more maintainable for us.

The thing is, it could very well be that one could port R300 driver to 
R200 cards, but I am somewhat certain that one cannot do the opposite.

And R200 driver works already, so this is clearly a task for later.

On the other hand, AFAIK, the tulip driver in Linux kernel was rewritten 
about 7 times (please correct me), so it would be a good idea to make the 
attempt.

There are many reasons:

      * benefits of unification ajax has mentioned

      * optimization - we are certainly not bothering with it too much

      * having fun reachitecturing Mesa driver

      * perhaps some improvements in ease of developing

           + perhaps some non-C code generation (I see python is being
             used already, perhaps some ML or Lisp fans can contribute
             as well)

           + facility for runtime generation of machine code -
             for example have "slow switch variables" which, when
             changed, write a "goto" instruction at the appropriate
             place.

      * unexpected stuff that always shows up

                          best

                            Vladimir Dergachev

On Fri, 4 Feb 2005, Nicolai Haehnle wrote:

> On Friday 04 February 2005 21:52, Vladimir Dergachev wrote:
>> On Fri, 4 Feb 2005, Adam Jackson wrote:
>>> Here again, ideally this would get folded upstream too, once it's at
>>> least secure.
>>>
>>> I can't really mandate a policy since I haven't been contributing much
>>> to r300, but I would like to hear how people think this should progress.
>>
>> Folding DRM driver is not difficult, in fact currently there is just one
>> extra file with r300-specific code.
>>
>> As for folding R300 driver, we'll see how things turn out. It is hard
>> for me to imagine how this folding could take place - albeit it might turn
>> out to be not too bad.
>
> You know, I actually started the r300 driver with this in mind, which is why
> you'll still see all those r200_* files around. The thing is, I neither
> have the hardware to test whether it still works on R200, nor can I
> currently contribute much to development.

I did not know that :) I thought you just used R200 driver to get to 
something that would do fallbacks.

>
> It really shouldn't require a complete rewrite, just a lot of careful (and
> tedious) refactoring.

If anyone wants to this can be easily checked by folding in texture 
handling code. If this can be done cleanly so it works on both drivers 
things are looking up.

Otherwise, there is no point in bothering. A good deal of state switching
code would need different files.

                      best

                          Vladimir Dergachev

>
> cu,
> Nicolai
>

Adam Jackson wrote:
>> I'm not so convinced that r200 and r300 driver (and radeon, for 
>> that matter) really should be only one driver. Why is it that bad 
>> to have 3 drivers? Those chips just ARE different. Sure, the 2d 
>> parts are more or less identical and certainly should be only one 
>> driver, but that's already the case. DRM should probably be the 
>> same too, since the differences needed are pretty much limited to 
>> what packets it accepts. But I'm not exactly sure how you'd unify 
>> the dri code. While you cannot deny that the drivers indeed look 
>> very similar, there are still a lot of differences. You will 
>> inevitably end up with lots of "if Radeon do that, else" code (or 
>> did you have #ifdef's in mind, so you would share the same source 
>> files, but would compile it to 3 targets in the end?).
> 
> 
> No, definitely not #ifdef hell, down that road lies madness.
Definitely agree here :-).

> We have this already though, in several drivers.  Savage3D and 
> Savage4, Intel 830/855/915, Voodoo3 and Voodoo4/5 even.  And I would 
> expect that the differences in features between chips corresponds 
> well to GL features for the most part, so they're natural boundaries 
> for conditionals anyway.
True. I think though savage3D and Savage4 are quite similar, so are
Voodoo3 and Voodoo4. The intel driver is a good argument however, i830
and i915 are quite different. It still manages to share quite some
files. I'm not so sure though a unified radeon/r200/r300 driver would
actually share a lot of code. Some stuff is certainly identical for all
of them (things like lock code, parts of cmdbuf/ioctl code, texmem,
sanity, maybe vertex submission (maos_arrays), and probably other stuff
as well). That's actually more than I initially thought, so maybe it
would be worth it.
Though if r200 and r300 are going to be unified, I'd definitely suggest
that radeon gets unified too. The code which can be shared between r200
and r300 is likely going to be pretty much the same as the code which
can be shared between radeon and r200, I think. In fact, if one would 
now unify radeon and r200 driver, this might allow the r300 driver to be 
more easily added a bit later. Any volunteers ;-).

>> As a side note, last time I checked ATI had 3 Direct3d drivers for 
>> the chips too. They have a unified package to install, and they may
>>  (no idea) share large parts of source code, but there are 3 
>> distinct dlls in the end.
> 
> 
> Direct3D drivers are not really an apples-to-apples comparison since 
> they'll try to factor out as many conditionals as possible for that 
> last 0.03fps in 3dmark.  fglrx is probably a more fair comparison, 
> and fglrx covers r200 through r400 no problem.  If we assume that 
> that's the more maintainable solution from ATI's perspective, I have 
> trouble seeing how distinct drivers would be more maintainable for 
> us.
That's a good point.

> As an example of what the non-unified road looks like, look at the 
> glide source.  Despite successive chips being pretty much strict 
> supersets in terms of functionality, they clone the entire tree for 
> each chip.  I suspect the effort required to keep drivers unified is 
> worth it in the long run.
I think glide is a very good example when you really should unify the 
code, since really pretty much all code could be shared for all chips. I 
would suspect r100/r200/r300 are quite a bit more different, and less of 
the code will be the same. But maybe you're right, and in the long run 
it would really be beneficiary. As Ian said, the intel driver seems to 
be a useful model. It shares the common code, and still nicely separates 
the code when the implemenentation needs to be different.

Roland

> Though if r200 and r300 are going to be unified, I'd definitely suggest
> that radeon gets unified too. The code which can be shared between r200
> and r300 is likely going to be pretty much the same as the code which
> can be shared between radeon and r200, I think. In fact, if one would now
> unify radeon and r200 driver, this might allow the r300 driver to be more
> easily added a bit later. Any volunteers ;-).

I think about it everytime I port some fixes from r200 to radeon :-) but
then I get scared.... to be honest it probably isn't a huge job, the
radeon/r200 are quite alike, you also have the issue that ATI duplicate a
lot of registers at different places, and without docs its hard to know
where these are..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Vladimir Dergachev wrote:
> 

>      * I don't think we need software TCL code to be separate - as I
>        understand this code is in R200 driver because initial driver
>        did not support hardware TCL. (We do not support it either, yet)

You also need some support for software TCL in situations where you have 
to fallback for whatever reason.

Keith

On Sat, 5 Feb 2005, Keith Whitwell wrote:

> Vladimir Dergachev wrote:
>> 
>
>>      * I don't think we need software TCL code to be separate - as I
>>        understand this code is in R200 driver because initial driver
>>        did not support hardware TCL. (We do not support it either, yet)
>
> You also need some support for software TCL in situations where you have to 
> fallback for whatever reason.

But what could this be ? R300 vertex shaders are generic enough.

                          best

                            Vladimir Dergachev

>
> Keith
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Vladimir Dergachev wrote:
> 
> 
> On Sat, 5 Feb 2005, Keith Whitwell wrote:
> 
>> Vladimir Dergachev wrote:
>>
>>>
>>
>>>      * I don't think we need software TCL code to be separate - as I
>>>        understand this code is in R200 driver because initial driver
>>>        did not support hardware TCL. (We do not support it either, yet)
>>
>>
>> You also need some support for software TCL in situations where you 
>> have to fallback for whatever reason.
> 
> 
> But what could this be ? R300 vertex shaders are generic enough.

You only need one thing.  Are all the GL texture border modes supported, 
for instance?  What about the GL_FRONT_AND_BACK draw buffer target?

Keith

Keith Whitwell wrote:
> Vladimir Dergachev wrote:
> 
>>
>>
>> On Sat, 5 Feb 2005, Keith Whitwell wrote:
>>
>>> Vladimir Dergachev wrote:
>>>
>>>>
>>>
>>>>      * I don't think we need software TCL code to be separate - as I
>>>>        understand this code is in R200 driver because initial driver
>>>>        did not support hardware TCL. (We do not support it either, yet)
>>>
>>>
>>>
>>> You also need some support for software TCL in situations where you 
>>> have to fallback for whatever reason.
>>
>>
>>
>> But what could this be ? R300 vertex shaders are generic enough.
> 
> 
> You only need one thing.  Are all the GL texture border modes supported, 
> for instance?  What about the GL_FRONT_AND_BACK draw buffer target?
> 
> Keith

Additionally, there is r300-class hardware around which don't even has 
(hw) tcl/vertex shader (xpress 200 igp, aka rs480).

Roland