Re: [R300] new snapshot ?
On Friday 10 June 2005 18:10, Vladimir Dergachev wrote: On Fri, 10 Jun 2005, Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Following patch should fix this at the cost of some speed... I just committed the following patch to r300_reg.h: Thanks. By the way, I confirmed that fglrx sets those bits in 0x180 on the following cards: - 0x4E44 (R300) - 0x4E50 (RV350) - 0x4A49 (R420) ... i.e. pretty much across the board. However, there are many other registers that it touches, and I couldn't test how it affects lockups yet. === RCS file: /cvsroot/r300/r300_driver/r300/r300_reg.h,v retrieving revision 1.41 diff -u -r1.41 r300_reg.h --- r300_reg.h 8 Jun 2005 15:05:24 - 1.41 +++ r300_reg.h 10 Jun 2005 16:09:22 - @@ -1,6 +1,27 @@ #ifndef _R300_REG_H #define _R300_REG_H +#define R300_MC_INIT_MISC_LAT_TIMER0x180 +# define R300_MC_MISC__MC_CPR_INIT_LAT_SHIFT 0 +# define R300_MC_MISC__MC_VF_INIT_LAT_SHIFT 4 +# define R300_MC_MISC__MC_DISP0R_INIT_LAT_SHIFT 8 +# define R300_MC_MISC__MC_DISP1R_INIT_LAT_SHIFT 12 +# define R300_MC_MISC__MC_FIXED_INIT_LAT_SHIFT16 +# define R300_MC_MISC__MC_E2R_INIT_LAT_SHIFT 20 +# define R300_MC_MISC__MC_SAME_PAGE_PRIO_SHIFT24 +# define R300_MC_MISC__MC_GLOBW_INIT_LAT_SHIFT24 Is the last 24 supposed to be a 28? + + +#define R300_MC_INIT_GFX_LAT_TIMER 0x154 +# define R300_MC_MISC__MC_G3D0R_INIT_LAT_SHIFT0 +# define R300_MC_MISC__MC_G3D1R_INIT_LAT_SHIFT4 +# define R300_MC_MISC__MC_G3D2R_INIT_LAT_SHIFT8 +# define R300_MC_MISC__MC_G3D3R_INIT_LAT_SHIFT12 +# define R300_MC_MISC__MC_TX0R_INIT_LAT_SHIFT 16 +# define R300_MC_MISC__MC_TX1R_INIT_LAT_SHIFT 20 +# define R300_MC_MISC__MC_GLOBR_INIT_LAT_SHIFT24 +# define R300_MC_MISC__MC_GLOBW_FULL_LAT_SHIFT0 Is the last 0 supposed to be a 28? cu, Nicolai pgp7aXAA21s8A.pgp Description: PGP signature
Re: [R300] new snapshot ?
On 6/12/05, Nicolai Haehnle [EMAIL PROTECTED] wrote: On Friday 10 June 2005 18:10, Vladimir Dergachev wrote: On Fri, 10 Jun 2005, Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Following patch should fix this at the cost of some speed... I just committed the following patch to r300_reg.h: Thanks. By the way, I confirmed that fglrx sets those bits in 0x180 on the following cards: - 0x4E44 (R300) - 0x4E50 (RV350) - 0x4A49 (R420) ... i.e. pretty much across the board. However, there are many other registers that it touches, and I couldn't test how it affects lockups yet. It sets it too on 0x4e4a (RV350 NJ). For the lockups see my other mail, i am pretty sure that once we get the proper reported value in 0x0f0d (RADEON_LATENCY) the lockup will go... +#define R300_MC_INIT_MISC_LAT_TIMER0x180 +# define R300_MC_MISC__MC_CPR_INIT_LAT_SHIFT 0 +# define R300_MC_MISC__MC_VF_INIT_LAT_SHIFT 4 +# define R300_MC_MISC__MC_DISP0R_INIT_LAT_SHIFT 8 +# define R300_MC_MISC__MC_DISP1R_INIT_LAT_SHIFT 12 +# define R300_MC_MISC__MC_FIXED_INIT_LAT_SHIFT16 +# define R300_MC_MISC__MC_E2R_INIT_LAT_SHIFT 20 +# define R300_MC_MISC__MC_SAME_PAGE_PRIO_SHIFT24 +# define R300_MC_MISC__MC_GLOBW_INIT_LAT_SHIFT24 Is the last 24 supposed to be a 28? + + +#define R300_MC_INIT_GFX_LAT_TIMER 0x154 +# define R300_MC_MISC__MC_G3D0R_INIT_LAT_SHIFT0 +# define R300_MC_MISC__MC_G3D1R_INIT_LAT_SHIFT4 +# define R300_MC_MISC__MC_G3D2R_INIT_LAT_SHIFT8 +# define R300_MC_MISC__MC_G3D3R_INIT_LAT_SHIFT12 +# define R300_MC_MISC__MC_TX0R_INIT_LAT_SHIFT 16 +# define R300_MC_MISC__MC_TX1R_INIT_LAT_SHIFT 20 +# define R300_MC_MISC__MC_GLOBR_INIT_LAT_SHIFT24 +# define R300_MC_MISC__MC_GLOBW_FULL_LAT_SHIFT0 Is the last 0 supposed to be a 28? Jerome --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Fri, 10 Jun 2005 14:31:48 +1000 Ben Skeggs [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939) Following patch should fix this at the cost of some speed... This does indeed seem to correct the problem, and I don't notice a loss of speed. glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg in the process of applying the patch, so it could be something from there. What exactly does the patch do? Or is it some magic we don't about yet? Perhaps ATI guys could answer that. -- Aapo Tahkola --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: 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] new snapshot ?
On Friday 10 June 2005 16:52, Aapo Tahkola wrote: On Fri, 10 Jun 2005 14:31:48 +1000 Ben Skeggs [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939) Following patch should fix this at the cost of some speed... This does indeed seem to correct the problem, and I don't notice a loss of speed. glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg in the process of applying the patch, so it could be something from there. What exactly does the patch do? Or is it some magic we don't about yet? Perhaps ATI guys could answer that. Umm... you *must* have that piece of code from *somewhere*, it can't just have fallen out of the sky. And that alone could provide at least some clue as to what this does... cu, Nicolai pgpUcUe8u9dz5.pgp Description: PGP signature
Re: [R300] new snapshot ?
On Fri, 10 Jun 2005, Aapo Tahkola wrote:
Someone, I believe it was Aapo, said that they see white lines across the
screen when the framerate is fairly high. I didn't see this up until yesterday
when I had to change from my 9600pro to a 9600XT (I killed the card moving
it between machines somehow).
Are you using SiS based motherboard by any chance?
Following patch should fix this at the cost of some speed...
I just committed the following patch to r300_reg.h:
===
RCS file: /cvsroot/r300/r300_driver/r300/r300_reg.h,v
retrieving revision 1.41
diff -u -r1.41 r300_reg.h
--- r300_reg.h 8 Jun 2005 15:05:24 - 1.41
+++ r300_reg.h 10 Jun 2005 16:09:22 -
@@ -1,6 +1,27 @@
#ifndef _R300_REG_H
#define _R300_REG_H
+#define R300_MC_INIT_MISC_LAT_TIMER0x180
+# define R300_MC_MISC__MC_CPR_INIT_LAT_SHIFT 0
+# define R300_MC_MISC__MC_VF_INIT_LAT_SHIFT 4
+# define R300_MC_MISC__MC_DISP0R_INIT_LAT_SHIFT 8
+# define R300_MC_MISC__MC_DISP1R_INIT_LAT_SHIFT 12
+# define R300_MC_MISC__MC_FIXED_INIT_LAT_SHIFT16
+# define R300_MC_MISC__MC_E2R_INIT_LAT_SHIFT 20
+# define R300_MC_MISC__MC_SAME_PAGE_PRIO_SHIFT24
+# define R300_MC_MISC__MC_GLOBW_INIT_LAT_SHIFT24
+
+
+#define R300_MC_INIT_GFX_LAT_TIMER 0x154
+# define R300_MC_MISC__MC_G3D0R_INIT_LAT_SHIFT0
+# define R300_MC_MISC__MC_G3D1R_INIT_LAT_SHIFT4
+# define R300_MC_MISC__MC_G3D2R_INIT_LAT_SHIFT8
+# define R300_MC_MISC__MC_G3D3R_INIT_LAT_SHIFT12
+# define R300_MC_MISC__MC_TX0R_INIT_LAT_SHIFT 16
+# define R300_MC_MISC__MC_TX1R_INIT_LAT_SHIFT 20
+# define R300_MC_MISC__MC_GLOBR_INIT_LAT_SHIFT24
+# define R300_MC_MISC__MC_GLOBW_FULL_LAT_SHIFT0
+
LAT stands for latency, MC for memory controller.
best
Vladimir Dergachev
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Fri Jun 10 05:46:14 2005
@@ -5631,6 +5631,11 @@
if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
--
Aapo Tahkola
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: 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] new snapshot ?
On Fri, 10 Jun 2005 17:04:06 +0200 Nicolai Haehnle [EMAIL PROTECTED] wrote: On Friday 10 June 2005 16:52, Aapo Tahkola wrote: On Fri, 10 Jun 2005 14:31:48 +1000 Ben Skeggs [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939) Following patch should fix this at the cost of some speed... This does indeed seem to correct the problem, and I don't notice a loss of speed. glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg in the process of applying the patch, so it could be something from there. What exactly does the patch do? Or is it some magic we don't about yet? Perhaps ATI guys could answer that. Umm... you *must* have that piece of code from *somewhere*, it can't just have fallen out of the sky. And that alone could provide at least some clue as to what this does... I traced this down by compairing MMIO regs: 1.r300 driver after reboot 2.fgl with option BufferTiling set to off 3.r300 driver after fgl has been used http://rasterburn.org/~aet/regdump.tar.bz2 See lspci -v or xorg logs for correct ADDR . -- Aapo Tahkola --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: 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] new snapshot ?
Someone, I believe it was Aapo, said that they see white lines across the
screen when the framerate is fairly high. I didn't see this up until yesterday
when I had to change from my 9600pro to a 9600XT (I killed the card moving
it between machines somehow).
Are you using SiS based motherboard by any chance?
Following patch should fix this at the cost of some speed...
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Fri Jun 10 05:46:14 2005
@@ -5631,6 +5631,11 @@
if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
--
Aapo Tahkola
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: 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] new snapshot ?
Aapo Tahkola wrote:
Someone, I believe it was Aapo, said that they see white lines across the
screen when the framerate is fairly high. I didn't see this up until yesterday
when I had to change from my 9600pro to a 9600XT (I killed the card moving
it between machines somehow).
Are you using SiS based motherboard by any chance?
Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939)
Following patch should fix this at the cost of some speed...
This does indeed seem to correct the problem, and I don't notice a loss
of speed.
glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg
in the
process of applying the patch, so it could be something from there.
What exactly does the patch do? Or is it some magic we don't about yet?
Thanks!
Ben.
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Fri Jun 10 05:46:14 2005
@@ -5631,6 +5631,11 @@
if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: 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] new snapshot ?
Vladimir Dergachev wrote: Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? So have you guys given any consideration to moving the r300 driver into mesa proper? CVS access shouldn't be a problem, fwiw... 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=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Keith Whitwell [EMAIL PROTECTED] wrote: Vladimir Dergachev wrote: Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? Why not :) So have you guys given any consideration to moving the r300 driver into mesa proper? CVS access shouldn't be a problem, fwiw... I think to few of us have an access to mesa cvs (at leat i didn't have one), anyway i could ask one. But there is still missing parts. I would like to know if anyone know what is still not working and thus do a to do list of that... What i see missing is : (i may not see everythings :-) -deeper testing of tcl program generated with mesa -tex env -fragment program Does ... work ? -z offset -stencil Right now i am on pixel shader after doing some test i don't think we can use a similar stuff like i915 emit arithm, i915 hardware are far more easier to program than r300. I am coding another approach an hope to have it done by the end of this week. Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? Jerome Glisse --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote: Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? Jerome Glisse Yes, this is still very true. I've just rebuilt xorg, mesa and r300 from cvs. I tested with glxgears and a couple of games. I've got a 9800 pro. glxgears running alone doesn't crash for a long time, but using anything else in parallel (for example firefox) gives me a crash in seconds. Playing neverball or tuxracer doesn't seem to crash at all. armagetron on the other hand has a high possibility to crash, and ut2004demo crashes in no more than 10 seconds. In crash I mean that X, the mouse and the keyboard freeze. Maybe it has something to do with frame rates? Boris Peterbarg --- 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=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Boris Peterbarg [EMAIL PROTECTED] wrote: Yes, this is still very true. I've just rebuilt xorg, mesa and r300 from cvs. I tested with glxgears and a couple of games. I've got a 9800 pro. glxgears running alone doesn't crash for a long time, but using anything else in parallel (for example firefox) gives me a crash in seconds. Playing neverball or tuxracer doesn't seem to crash at all. armagetron on the other hand has a high possibility to crash, and ut2004demo crashes in no more than 10 seconds. In crash I mean that X, the mouse and the keyboard freeze. Did you try to log in via ssh ? If you can, look if the X process consume 100% of CPU, if so this may be related to the bug of r200, as we got many common code. Maybe it has something to do with frame rates? I got a 9800 (don't remember if it's a pro or not) i will try to see if i can find anything. Jerome Glisse --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote: -stencil Stencil should work. GL_ATI_separate_stencil is not implemented (hardware support it). I think, fog is not implemented too. Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? I have 9500 Pro. Some opengl application locks after while. Enemy Teritori lock immediatly after match begin if extensions are enabled If extensions are dissabled in options menu it works good, but slow. Peter Zubaj ___ Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete. http://www.wanda.sk/ --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote: Right now i am on pixel shader after doing some test i don't think we can use a similar stuff like i915 emit arithm, i915 hardware are far more easier to program than r300. I am coding another approach an hope to have it done by the end of this week. Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? I will confirm this tomorrow, right now, I am busy with other stuff. Cheers, Jonathan signature.asc Description: OpenPGP digital signature
Re: [R300] new snapshot ?
Jerome Glisse wrote: On 5/19/05, Keith Whitwell [EMAIL PROTECTED] wrote: Vladimir Dergachev wrote: Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? Sounds like a good idea. Why not :) So have you guys given any consideration to moving the r300 driver into mesa proper? CVS access shouldn't be a problem, fwiw... I think to few of us have an access to mesa cvs (at leat i didn't have one), anyway i could ask one. But there is still missing parts. I would like to know if anyone know what is still not working and thus do a to do list of that... What i see missing is : (i may not see everythings :-) -deeper testing of tcl program generated with mesa -tex env -fragment program Also, I think there's still some weirdness with a couple of texture formats, namely GL_ALPHA and GL_LUMINANCE_ALPHA. This is clearly seen in Mesa/progs/demos/texenv.c. Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Does ... work ? -z offset -stencil Right now i am on pixel shader after doing some test i don't think we can use a similar stuff like i915 emit arithm, i915 hardware are far more easier to program than r300. I am coding another approach an hope to have it done by the end of this week. I've also been working on some fragment program stuff. I have attached what I've done so far, which works quite well with Keith's texenv program generation that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I think everything's there that the texenv stuff needs. I was planning on commiting this soon, but you may have a better approach than I took so I'll wait a bit. Ben Skeggs. Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? Jerome Glisse --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Gemeinsame Unterverzeichnisse: r300.old/CVS und r300/CVS. diff -Nu r300.old/Makefile r300/Makefile --- r300.old/Makefile 2005-04-24 19:08:31.0 +1000 +++ r300/Makefile 2005-05-19 03:24:11.0 +1000 @@ -37,6 +37,7 @@ r300_texstate.c \ r300_texprog.c \ r300_vertexprog.c \ +r300_fragprog.c \ r300_shader.c \ r300_maos.c # \ diff -Nu r300.old/r300_context.c r300/r300_context.c --- r300.old/r300_context.c 2005-05-19 23:50:38.0 +1000 +++ r300/r300_context.c 2005-05-19 23:47:41.0 +1000 @@ -80,7 +80,9 @@ GL_ARB_texture_mirrored_repeat, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, - //GL_ARB_fragment_program, +#if USE_ARB_F_P == 1 + GL_ARB_fragment_program, +#endif GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, @@ -325,7 +327,19 @@ ctx-Const.MaxVertexProgramLocalParams=256; // r420 ctx-Const.MaxVertexProgramEnvParams=256; // r420 ctx-Const.MaxVertexProgramAddressRegs=1; - + +#if USE_ARB_F_P + ctx-Const.MaxFragmentProgramTemps = PFS_NUM_TEMP_REGS; + ctx-Const.MaxFragmentProgramAttribs = 11; /* copy i915... */ + ctx-Const.MaxFragmentProgramLocalParams = PFS_NUM_CONST_REGS; + ctx-Const.MaxFragmentProgramEnvParams = PFS_NUM_CONST_REGS; + ctx-Const.MaxFragmentProgramAluInstructions = PFS_MAX_ALU_INST; + ctx-Const.MaxFragmentProgramTexInstructions = PFS_MAX_TEX_INST; + ctx-Const.MaxFragmentProgramInstructions = PFS_MAX_ALU_INST+PFS_MAX_TEX_INST; + ctx-Const.MaxFragmentProgramAddressRegs = 0; /* and these are?? */ + ctx-_MaintainTexEnvProgram = GL_TRUE; +#endif + driInitExtensions(ctx, card_extensions, GL_TRUE); radeonInitSpanFuncs(ctx); diff -Nu r300.old/r300_context.h r300/r300_context.h --- r300.old/r300_context.h 2005-05-19 23:50:38.0 +1000 +++ r300/r300_context.h 2005-05-19 23:47:41.0 +1000 @@ -47,6 +47,8 @@ #include colormac.h #include radeon_context.h +#define USE_ARB_F_P 1 + struct r300_context; typedef struct r300_context r300ContextRec; typedef struct r300_context *r300ContextPtr; @@ -83,7 +85,11 @@ and pixel_shader structure later on */ #define CARD32
Re: [R300] new snapshot ?
On Thursday 19 May 2005 09:20, Keith Whitwell wrote: Vladimir Dergachev wrote: Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? Sure, anytime :) So have you guys given any consideration to moving the r300 driver into mesa proper? CVS access shouldn't be a problem, fwiw... There are two main points that have stopped me from pushing for the inclusion of the driver into Mesa proper: 1. Kernel-level security holes We should take care of full command-stream verification before moving the driver into Mesa CVS. It's easy to say We can do that later, but if we say that it's likely that it won't be done in a long time. 2. DRM binary compatibility We still don't know the meaning of many of the registers. Some registers are labelled dangerous which means we might have to do some more checks in the kernel to make sure user processes can't do harmful stuff. This means that we might have to *remove* some of the cmdbuf commands that exist today in the future. If the others believe moving r300 to Mesa is a good idea, then I'll do some auditing to the DRM code. Once I (or somebody else) has done this, I'm okay with moving the driver as long as we don't enforce DRM binary compatibility yet. cu, Nicolai pgpm9DoWLbaY9.pgp Description: PGP signature
Re: [R300] new snapshot ?
Jerome Glisse wrote: I've also been working on some fragment program stuff. I have attached what I've done so far, which works quite well with Keith's texenv program generation that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I think everything's there that the texenv stuff needs. I was planning on commiting this soon, but you may have a better approach than I took so I'll wait a bit. I have tried a similar approach at first but as swizzle appear it looks awful, i haven't take a deeper look at the way you handle it but you have a bunch of if test like i got in my first version. You certainly have done cleaner version than my first attempt thought. Anyway now what i have is the stupid way of having a table for all swizzle case, just for the x,y,z component as w is in sep an easier reg. Thus i got two tab one for xyz to FPI0_SRC conv which have a special value for not native format, this special value in an index in the second tab where i got all the code for all differents cases (64 cases less 7 of native format). This consumes few bytes about 1ko... I use a similar approach. v_swiz contains all the native r300 swizzle values, aswell as a couple of cases where we have to handle them specially. The non-native cases have v_swiz-native set to GL_FALSE. What I do is firstly loop through checking for matches of XYZ. If we match all three components, the code will return a pfs_reg_t with v_swz/s_swz set to a native type. Otherwise, we continue looping through the different outmasks doing multiple emits to another temp until we have the desired value. Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? The code is only translated once. In the case of the texenv stuff, whenever it needs to be regenerated Mesa will call r300ProgramStringNotify to tell us that the program has changed. Anyway other part of the code is basicly the same, yours is in a more advanced state than mine thus we should use yours... Anyone have strong feeling on this swizzle thing ? Or even an magic idea with a magic bitwise formula :) One other interesting feature is reuse of temp register at some point i was thinking of adding a free_temp function and having a stack of free register. Then get_temp first take from the stack if not empty, or use a new temp if empty. This get/free approach is usefull with swizzling where you know that you will use a temps register only for 1 instruction. But there may be case where you reuse the same swizzled src. I once had this in the code, but ended up stripping it down to iron out some bugs. Now that I know that it mostly works correctly, I should be able to add this back in easily enough. Rather than using a stack, I'm using a bitfield to track register allocations. Freeing a register is as easy as setting the bit to 0. Care must be taken not to cause texture indirections by reusing an already used temp as the destination for a TEX instruction (that's what rp-used_this_node is/was for) I am wondering if you emit_const_swizzle may not consume all const if say you have an const which is used in all of the 64 possibles swizzle... I may have miss something on that thought. But if we know that we will only use the const in a swizzled format then your solution is the best. No, you haven't missed anything. This was another case where I quickly hacked something up. Constant swizzles should/could be handled exactly the same as temp swizzles. In the swizzling code you just have to be careful that reg-type is set correctly depending on whether or not it's a native swizzle. I got other idea on optimizing this swizzling in program translation (basicly tracking operand). But this are maybe useless optimization for time being... I've thought of similar things, but haven't attempted anything yet. I also need to take another look at the generated code, to make sure that combining the xyz and w instuction streams is working as I intended. When I first integrated my test code into r300_dri it was, but I've changed much since then. Cheers, Ben Skeggs. Jerome Glisse --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net
Re: [R300] new snapshot ?
On Thu, 19 May 2005, Jerome Glisse wrote: Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? An intermediate approach would be to have an if function that is easier to read (and debug) but instead of using return values directly populate the table with the return values during startup and then use the table. This way we retain the readability and have the speedup from lookups. best Vladimir Dergachev --- 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=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
I've also been working on some fragment program stuff. I have attached what I've done so far, which works quite well with Keith's texenv program generation that's in Mesa cvs. Not all arb_f_p opcodes are implemented, but I think everything's there that the texenv stuff needs. I was planning on commiting this soon, but you may have a better approach than I took so I'll wait a bit. I have tried a similar approach at first but as swizzle appear it looks awful, i haven't take a deeper look at the way you handle it but you have a bunch of if test like i got in my first version. You certainly have done cleaner version than my first attempt thought. Anyway now what i have is the stupid way of having a table for all swizzle case, just for the x,y,z component as w is in sep an easier reg. Thus i got two tab one for xyz to FPI0_SRC conv which have a special value for not native format, this special value in an index in the second tab where i got all the code for all differents cases (64 cases less 7 of native format). This consumes few bytes about 1ko... Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? Anyway other part of the code is basicly the same, yours is in a more advanced state than mine thus we should use yours... Anyone have strong feeling on this swizzle thing ? Or even an magic idea with a magic bitwise formula :) One other interesting feature is reuse of temp register at some point i was thinking of adding a free_temp function and having a stack of free register. Then get_temp first take from the stack if not empty, or use a new temp if empty. This get/free approach is usefull with swizzling where you know that you will use a temps register only for 1 instruction. But there may be case where you reuse the same swizzled src. I am wondering if you emit_const_swizzle may not consume all const if say you have an const which is used in all of the 64 possibles swizzle... I may have miss something on that thought. But if we know that we will only use the const in a swizzled format then your solution is the best. I got other idea on optimizing this swizzling in program translation (basicly tracking operand). But this are maybe useless optimization for time being... Jerome Glisse --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Nicolai Haehnle [EMAIL PROTECTED] wrote: On Thursday 19 May 2005 09:20, Keith Whitwell wrote: Vladimir Dergachev wrote: Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? Sure, anytime :) So have you guys given any consideration to moving the r300 driver into mesa proper? CVS access shouldn't be a problem, fwiw... There are two main points that have stopped me from pushing for the inclusion of the driver into Mesa proper: 1. Kernel-level security holes We should take care of full command-stream verification before moving the driver into Mesa CVS. It's easy to say We can do that later, but if we say that it's likely that it won't be done in a long time. 2. DRM binary compatibility We still don't know the meaning of many of the registers. Some registers are labelled dangerous which means we might have to do some more checks in the kernel to make sure user processes can't do harmful stuff. This means that we might have to *remove* some of the cmdbuf commands that exist today in the future. If the others believe moving r300 to Mesa is a good idea, then I'll do some auditing to the DRM code. Once I (or somebody else) has done this, I'm okay with moving the driver as long as we don't enforce DRM binary compatibility yet. cu, Nicolai true, the drm may need to live on it's own branch for a bit. But I think the 3d driver could be added to mesa. it can live in cvs until we feel it is ready to be part of a stable release. Being part of mesa cvs means we'll always be in sync with the latest mesa changes and get nightly snapshots which will add additional testers for better or worse. Alex --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Boris Peterbarg [EMAIL PROTECTED] wrote: Well, I tried now - I have an old computer...well, the box anyway. Had to switch all the cables between the two computers all the time. First, the program that I ran consumed 100%. After killing it, X consumed 100% and took about 15 minutes to be killed. The last image was still stuck on the display, though. Thus i think that we face the same problem as r200 :( seems a hard bug to find Jerome Glisse --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On 5/19/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 19 May 2005, Jerome Glisse wrote: Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? An intermediate approach would be to have an if function that is easier to read (and debug) but instead of using return values directly populate the table with the return values during startup and then use the table. Did i said that i already done the table (as a human, at least everythings tends to make me think that i am a human :-)) Thus making a function to redo the table may be bit useless :) Jerome Glisse --- 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_idt12alloc_id344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote:
I use a similar approach. v_swiz contains all the native r300 swizzle
values,
aswell as a couple of cases where we have to handle them specially. The
non-native cases have v_swiz-native set to GL_FALSE.
I saw that in code but you still got a loop and test case, your
approach is well thinked. But i think it may be hard to understand
say if you look at it in 2 or 3 month.
Thus the only + arguments for a simple 2tab translation i
propose is that it the easiest thing to understand, moreover
you can easily optimize some swizzling case and don't bother
too much on other... But beside the understanding
of your mixed approach haven't a strong opinion on which solution is the
best...
The code is only translated once. In the case of the texenv stuff, whenever
it needs to be regenerated Mesa will call r300ProgramStringNotify to tell
us that the program has changed.
This why i think tab lookup speed isn't really revealent in
selecting this. I will try to adapt my swizzle function
to your code (shouldn't be difficult) thus you can see it.
Bascily arg checking in emit arith look like this :
id = reg MASK_XYZCHANNEL
reg_fpi0_mask = tab1[id];
if (reg_fpi0_mask ^ ffe0 ) {
swizzle - copy tab2[id5] - r300_instruct
t = get_temp
for itab2[id5].length
r300_instr[p-i] |= t
}
Just a memcpy of instruction and a small loop
to set the correct temp reg allocated.
Well, I'm in mixed minds about this myself now. But if you have a way
to gain extra
speed out of this without consuming a heap of RAM, I'm all for it :)
Extra speed could be useful, as some programs may have a lot of swizzles
per-frame (UT2004
has a few when MaxTextureUnits is set to 8 in ut2004.ini) and every
extra bit helps.
Care must be taken not to cause texture indirections by reusing an
already
used temp as the destination for a TEX instruction (that's what
rp-used_this_node
is/was for)
Yes, i saw this possible issue but didn't think too much on
solution to handle it, i will give a deeper look to your code
this evening.
I've attached another patch (applies on top of the last one) which
/should/ take
care of this, and handle the case where a program does a TEX directly to an
output. It also free's up temps in the cases where we need one for a
swizzle, or
an LRP.
What I'd like to be able to do is re-use temps used by the Mesa program,
and also
to free-up the hardware temp that a Mesa INPUT uses once they're no
longer needed.
We'd need to find out when the temp/input was last used so we didn't
destroy it
pre-maturely.
Should be easy enough to do, as my code already pre-parses the Mesa
program. I
originally considered this a thing I needed to fix. But it could be
useful for some things.
No, you haven't missed anything. This was another case where I quickly
hacked
something up. Constant swizzles should/could be handled exactly the same as
temp swizzles. In the swizzling code you just have to be careful that
reg-type is
set correctly depending on whether or not it's a native swizzle.
I was thinking of tracking constant and see if they are always used
swizzle. If so easier to emit the const swizzled like you do.
As i said this is maybe a to advanced and complex optimization which
may involve complex tracking of operand in the program.
You could possibly do this for some cases right now. In t_src you'd
need to skip
the emit_const4fv for constant sources if they're swizzles, and call
swizzle_const
instead. This would eliminate some of them.
The patch I attached doesn't call swizzle_const at all, instead, it uses
the same
method as temps do. I didn't see anything too nasty in ut2004 from
doing this.
I didn't test the patch in great detail, so there's probably something I
missed :/
Ben Skeggs.
Jerome Glisse
---
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_idt12alloc_id344op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--- diff/r300/r300_fragprog.c 2005-05-19 04:23:09.0 +1000
+++ r300_wip/r300/r300_fragprog.c 2005-05-20 03:21:23.0 +1000
@@ -172,10 +172,21 @@
rp-hwreg_flag |= (1 r);
rp-hwreg_used |= (1 r);
-
+
return r;
}
+static void free_hw_temp(struct r300_fragment_program *rp, int idx)
+{
+ rp-hwreg_flag = ~(1idx);
+}
+
+static void free_temp(struct r300_fragment_program *rp, int idx)
+{
+ free_hw_temp(rp, rp-temps[idx]);
+ rp-temp_flag = ~(1idx);
+}
+
static pfs_reg_t emit_const4fv(struct r300_fragment_program *rp, GLfloat *cp)
{
pfs_reg_t r = pfs_default_reg;
@@ -209,6 +220,23 @@
return r;
}
+static pfs_reg_t get_temp_tex(struct r300_fragment_program *rp)
+{
+
Re: [R300] new snapshot ?
On Thu, 19 May 2005, Jerome Glisse wrote: On 5/19/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Thu, 19 May 2005, Jerome Glisse wrote: Thus what we may do is use this table or use your swizzle function. Table lookup are faster but we doesn't have to translate code often, no ? An intermediate approach would be to have an if function that is easier to read (and debug) but instead of using return values directly populate the table with the return values during startup and then use the table. Did i said that i already done the table (as a human, at least everythings tends to make me think that i am a human :-)) Thus making a function to redo the table may be bit useless :) The function approach might be useful if there are fewer test cases than entries in the table. In this case we win on code maintainability.. best Vladimir Dergachev Jerome Glisse --- 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=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
I use a similar approach. v_swiz contains all the native r300 swizzle
values,
aswell as a couple of cases where we have to handle them specially. The
non-native cases have v_swiz-native set to GL_FALSE.
I saw that in code but you still got a loop and test case, your
approach is well thinked. But i think it may be hard to understand
say if you look at it in 2 or 3 month.
Thus the only + arguments for a simple 2tab translation i
propose is that it the easiest thing to understand, moreover
you can easily optimize some swizzling case and don't bother
too much on other... But beside the understanding
of your mixed approach haven't a strong opinion on which solution is the
best...
The code is only translated once. In the case of the texenv stuff, whenever
it needs to be regenerated Mesa will call r300ProgramStringNotify to tell
us that the program has changed.
This why i think tab lookup speed isn't really revealent in
selecting this. I will try to adapt my swizzle function
to your code (shouldn't be difficult) thus you can see it.
Bascily arg checking in emit arith look like this :
id = reg MASK_XYZCHANNEL
reg_fpi0_mask = tab1[id];
if (reg_fpi0_mask ^ ffe0 ) {
swizzle - copy tab2[id5] - r300_instruct
t = get_temp
for itab2[id5].length
r300_instr[p-i] |= t
}
Just a memcpy of instruction and a small loop
to set the correct temp reg allocated.
I once had this in the code, but ended up stripping it down to iron out some
bugs. Now that I know that it mostly works correctly, I should be able
to add
this back in easily enough. Rather than using a stack, I'm using a
bitfield to
track register allocations. Freeing a register is as easy as setting
the bit to 0.
What is in favor of a stack is that you easily find free temp
(just test if stack is empty), while with bitfield you have to
loop trought each temp see if bitfield set.
Care must be taken not to cause texture indirections by reusing an
already
used temp as the destination for a TEX instruction (that's what
rp-used_this_node
is/was for)
Yes, i saw this possible issue but didn't think too much on
solution to handle it, i will give a deeper look to your code
this evening.
No, you haven't missed anything. This was another case where I quickly
hacked
something up. Constant swizzles should/could be handled exactly the same as
temp swizzles. In the swizzling code you just have to be careful that
reg-type is
set correctly depending on whether or not it's a native swizzle.
I was thinking of tracking constant and see if they are always used
swizzle. If so easier to emit the const swizzled like you do.
As i said this is maybe a to advanced and complex optimization which
may involve complex tracking of operand in the program.
Jerome Glisse
---
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_idt12alloc_id344op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] new snapshot ?
Hi Aapo, Ben, Jerome, Nicolai: I recently checked fresh code from CVS and was pleasantly surprised to see that all Quake3 levels that were broken are now perfect - in fact I cannot find anything that is amiss ! Do you think it would be a good idea to tag the current code and make a snapshot ? thank you ! Vladimir Dergachev --- 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=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
