From: Vladimir D. <vo...@mi...> - 2005-02-01 15:52:47
|
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. best Vladimir Dergachev |
From: Keith W. <ke...@tu...> - 2005-02-01 16:08:18
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-01 17:52:57
|
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 |
From: Keith W. <ke...@tu...> - 2005-02-01 18:42:32
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-01 18:58:30
|
>>> 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 > |
From: Rune P. <ru...@ma...> - 2005-02-01 20:38:36
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-01 23:21:15
|
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 > |
From: Rune P. <ru...@ma...> - 2005-02-02 16:24:01
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-02 19:43:24
|
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 > |
From: Rune P. <ru...@ma...> - 2005-02-03 00:59:22
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-03 02:45:40
|
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 > |
From: Vladimir D. <vo...@mi...> - 2005-02-03 04:19:43
|
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 > |
From: Rune P. <ru...@ma...> - 2005-02-03 14:36:50
|
> 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 |
From: Vladimir D. <vo...@mi...> - 2005-02-03 15:42:20
|
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 > |
From: Rune P. <ru...@ma...> - 2005-02-03 15:59:23
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-03 16:03:56
|
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 > |
From: Rune P. <ru...@ma...> - 2005-02-03 16:43:51
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-03 17:51:32
|
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 > |
From: Rune P. <ru...@ma...> - 2005-02-03 18:29:03
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-03 18:35:43
|
>>>> >>>> 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 > |
From: Rune P. <ru...@ma...> - 2005-02-04 13:42:21
|
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 |
From: Vladimir D. <vo...@mi...> - 2005-02-04 13:54:38
|
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 > |
From: Rune P. <ru...@ma...> - 2005-02-04 16:14:38
|
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 |
From: Alex D. <ale...@gm...> - 2005-02-03 18:39:09
|
On Thu, 03 Feb 2005 19:44:57 +0100, Rune Petersen <ru...@ma...> 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 |
From: Rune P. <ru...@ma...> - 2005-02-03 19:35:01
|
Alex Deucher wrote: > On Thu, 03 Feb 2005 19:44:57 +0100, Rune Petersen <ru...@ma...> 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 |