Re: R300 registers
On Tue, 14 Sep 2004 10:49:48 -0400 (EDT), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > > > On Tue, 14 Sep 2004, Alex Deucher wrote: > > > On Tue, 14 Sep 2004 09:37:05 -0400 (EDT), Vladimir Dergachev > > <[EMAIL PROTECTED]> wrote: > >> > >> > >> On Tue, 14 Sep 2004, Dave Airlie wrote: > >> > >>> > >>> Just a suggestion but how about adding the header file to the Wiki and > >>> anyone who comes up with more info can throw it into it as well.. so > >>> everyone works from the same basic register sets... > >>> > >>> Dave. > >>> so many cool things to do, not enough time :-) > >> > >> Actually, I am in the process of opening a new project on SF just for > >> R300 and similar development - this will go directly into CVS. > > > > It may be better to add it to freedesktop cvs since SF cvs is rarely > > accessable for anon cvs users and when it is it tends to lag behind > > the real cvs tree. > > I think they fixed it - unless it broke again since last time. Could be. I haven't tried SF cvs in a while. > > More importantly this project is for finding out more about R300 > accelerators, not building stable drivers for public consumption, > so I envisioned giving write access to every developer interested in the > project. Ah. That's a good idea. I didn't realize you were going that route. > > I am not certain, but I thought that the process of giving access to > freedesktop CVS was a bit more complicated (with good reason, of course). definitely. Alex > > best > > Vladimir Dergachev > > --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 registers
On Tue, 14 Sep 2004, Alex Deucher wrote: On Tue, 14 Sep 2004 09:37:05 -0400 (EDT), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: On Tue, 14 Sep 2004, Dave Airlie wrote: Just a suggestion but how about adding the header file to the Wiki and anyone who comes up with more info can throw it into it as well.. so everyone works from the same basic register sets... Dave. so many cool things to do, not enough time :-) Actually, I am in the process of opening a new project on SF just for R300 and similar development - this will go directly into CVS. It may be better to add it to freedesktop cvs since SF cvs is rarely accessable for anon cvs users and when it is it tends to lag behind the real cvs tree. I think they fixed it - unless it broke again since last time. More importantly this project is for finding out more about R300 accelerators, not building stable drivers for public consumption, so I envisioned giving write access to every developer interested in the project. I am not certain, but I thought that the process of giving access to freedesktop CVS was a bit more complicated (with good reason, of course). best Vladimir Dergachev --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 registers
On Tue, 14 Sep 2004 09:37:05 -0400 (EDT), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > > > On Tue, 14 Sep 2004, Dave Airlie wrote: > > > > > Just a suggestion but how about adding the header file to the Wiki and > > anyone who comes up with more info can throw it into it as well.. so > > everyone works from the same basic register sets... > > > > Dave. > > so many cool things to do, not enough time :-) > > Actually, I am in the process of opening a new project on SF just for > R300 and similar development - this will go directly into CVS. It may be better to add it to freedesktop cvs since SF cvs is rarely accessable for anon cvs users and when it is it tends to lag behind the real cvs tree. Alex > > One of the tools (glxtest) has TCL program that converts command stream > into readable forms (by humans and C compiler) and it also autogenerates > the register header. > > best > > Vladimir Dergachev > > > > > > > On Mon, 13 Sep 2004, Nicolai Haehnle wrote: > > > >> Hi, > >> > >> while I've had less success (read: hard locks and reboots) with the recently > >> drmtest and r300_demo, I did use glxtest to find out registers of the R300. > >> > >> Basically, what I did is run a small GL program, get the command buffer, > >> make some small changes and rerun. Often, this results in only a small > >> change in the command buffer (found using diff), which makes it possible to > >> guess register addresses and constants. So while I haven't been able to > >> crosstest my results by _sending_ commands using my new knowledge, I am > >> pretty certain that they are mostly correct (as long as there is no > >> explicit comment stating otherwise). > >> > >> So far, I have found registers for alpha blending and testing among other > >> things. I have also decoded most of the vertex program instruction set. > >> However, I do not have the registers for vertex program *setup* yet. All I > >> know is that both the program and its environment/parameters (whatever you > >> want to call it) are uploaded via 0x2208. > >> > >> All my findings are documented in the attached header file. > >> > >> cu, > >> Nicolai > >> > > > > -- > > David Airlie, Software Engineer > > http://www.skynet.ie/~airlied / airlied at skynet.ie > > pam_smb / Linux DECstation / Linux VAX / ILUG person > > > > > > > > --- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > > -- > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > > --- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 registers
On Tue, 14 Sep 2004, Dave Airlie wrote: Just a suggestion but how about adding the header file to the Wiki and anyone who comes up with more info can throw it into it as well.. so everyone works from the same basic register sets... Dave. so many cool things to do, not enough time :-) Actually, I am in the process of opening a new project on SF just for R300 and similar development - this will go directly into CVS. One of the tools (glxtest) has TCL program that converts command stream into readable forms (by humans and C compiler) and it also autogenerates the register header. best Vladimir Dergachev On Mon, 13 Sep 2004, Nicolai Haehnle wrote: Hi, while I've had less success (read: hard locks and reboots) with the recently drmtest and r300_demo, I did use glxtest to find out registers of the R300. Basically, what I did is run a small GL program, get the command buffer, make some small changes and rerun. Often, this results in only a small change in the command buffer (found using diff), which makes it possible to guess register addresses and constants. So while I haven't been able to crosstest my results by _sending_ commands using my new knowledge, I am pretty certain that they are mostly correct (as long as there is no explicit comment stating otherwise). So far, I have found registers for alpha blending and testing among other things. I have also decoded most of the vertex program instruction set. However, I do not have the registers for vertex program *setup* yet. All I know is that both the program and its environment/parameters (whatever you want to call it) are uploaded via 0x2208. All my findings are documented in the attached header file. cu, Nicolai -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 registers
Just a suggestion but how about adding the header file to the Wiki and anyone who comes up with more info can throw it into it as well.. so everyone works from the same basic register sets... Dave. so many cool things to do, not enough time :-) On Mon, 13 Sep 2004, Nicolai Haehnle wrote: > Hi, > > while I've had less success (read: hard locks and reboots) with the recently > drmtest and r300_demo, I did use glxtest to find out registers of the R300. > > Basically, what I did is run a small GL program, get the command buffer, > make some small changes and rerun. Often, this results in only a small > change in the command buffer (found using diff), which makes it possible to > guess register addresses and constants. So while I haven't been able to > crosstest my results by _sending_ commands using my new knowledge, I am > pretty certain that they are mostly correct (as long as there is no > explicit comment stating otherwise). > > So far, I have found registers for alpha blending and testing among other > things. I have also decoded most of the vertex program instruction set. > However, I do not have the registers for vertex program *setup* yet. All I > know is that both the program and its environment/parameters (whatever you > want to call it) are uploaded via 0x2208. > > All my findings are documented in the attached header file. > > cu, > Nicolai > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
R300 registers
Hi, while I've had less success (read: hard locks and reboots) with the recently drmtest and r300_demo, I did use glxtest to find out registers of the R300. Basically, what I did is run a small GL program, get the command buffer, make some small changes and rerun. Often, this results in only a small change in the command buffer (found using diff), which makes it possible to guess register addresses and constants. So while I haven't been able to crosstest my results by _sending_ commands using my new knowledge, I am pretty certain that they are mostly correct (as long as there is no explicit comment stating otherwise). So far, I have found registers for alpha blending and testing among other things. I have also decoded most of the vertex program instruction set. However, I do not have the registers for vertex program *setup* yet. All I know is that both the program and its environment/parameters (whatever you want to call it) are uploaded via 0x2208. All my findings are documented in the attached header file. cu, Nicolai // The entire range from 0x2300 to 0x2AC inclusive seems to be used for // immediate vertices #define R300_VAP_VTX_COLOR_R0x2464 #define R300_VAP_VTX_COLOR_G0x2468 #define R300_VAP_VTX_COLOR_B0x246C #define R300_VAP_VTX_POS_0_X_1 0x2490 // used for glVertex2*() #define R300_VAP_VTX_POS_0_Y_1 0x2494 #define R300_VAP_VTX_COLOR_PKD 0x249C // RGBA #define R300_VAP_VTX_POS_0_X_2 0x24A0 // used for glVertex3*() #define R300_VAP_VTX_POS_0_Y_2 0x24A4 #define R300_VAP_VTX_POS_0_Z_2 0x24A8 #define R300_VAP_VTX_END_OF_PKT 0x24AC // write 0 to indicate end of packet? /* gap */ #define R300_PP_ALPHA_TEST 0x4BD4 # define R300_REF_ALPHA_MASK 0x00ff # define R300_ALPHA_TEST_FAIL (0 << 8) # define R300_ALPHA_TEST_LESS (1 << 8) # define R300_ALPHA_TEST_LEQUAL(2 << 8) # define R300_ALPHA_TEST_EQUAL (3 << 8) # define R300_ALPHA_TEST_GEQUAL(4 << 8) # define R300_ALPHA_TEST_GREATER (5 << 8) # define R300_ALPHA_TEST_NEQUAL(6 << 8) # define R300_ALPHA_TEST_PASS (7 << 8) # define R300_ALPHA_TEST_OP_MASK (7 << 8) # define R300_ALPHA_TEST_ENABLE(1 << 11) /* gap */ // Notes: // - AFAIK fglrx always sets BLEND_UNKNOWN when blending is used in the application // - AFAIK fglrx always sets BLEND_NO_SEPARATE when CBLEND and ABLEND are set to the same // function (both registers are always set up completely in any case) // - Most blend flags are simply copied from R200 and not tested yet #define R300_RB3D_CBLEND0x4E04 #define R300_RB3D_ABLEND0x4E08 /* the following only appear in CBLEND */ # define R300_BLEND_ENABLE (1 << 0) # define R300_BLEND_UNKNOWN(3 << 1) # define R300_BLEND_NO_SEPARATE(1 << 3) /* the following are shared between CBLEND and ABLEND */ # define R300_FCN_MASK (3 << 12) # define R300_COMB_FCN_ADD_CLAMP (0 << 12) # define R300_COMB_FCN_ADD_NOCLAMP (1 << 12) # define R300_COMB_FCN_SUB_CLAMP (2 << 12) # define R300_COMB_FCN_SUB_NOCLAMP (3 << 12) # define R300_SRC_BLEND_GL_ZERO(32 << 16) # define R300_SRC_BLEND_GL_ONE (33 << 16) # define R300_SRC_BLEND_GL_SRC_COLOR (34 << 16) # define R300_SRC_BLEND_GL_ONE_MINUS_SRC_COLOR (35 << 16) # define R300_SRC_BLEND_GL_DST_COLOR (36 << 16) # define R300_SRC_BLEND_GL_ONE_MINUS_DST_COLOR (37 << 16) # define R300_SRC_BLEND_GL_SRC_ALPHA (38 << 16) # define R300_SRC_BLEND_GL_ONE_MINUS_SRC_ALPHA (39 << 16) # define R300_SRC_BLEND_GL_DST_ALPHA (40 << 16) # define R300_SRC_BLEND_GL_ONE_MINUS_DST_ALPHA (41 << 16) # define R300_SRC_BLEND_GL_SRC_ALPHA_SATURATE (42 << 16) # define R300_SRC_BLEND_MASK (63 << 16) # define R300_DST_BLEND_GL_ZERO(32 << 24) # define R300_DST_BLEND_GL_ONE (33 << 24) # define R300_DST_BLEND_GL_SRC_COLOR (34 << 24) # define R300_DST_BLEND_GL_ONE_MINUS_SRC_COLOR (35 << 24) # define R300_DST_BLEND_GL_DST_COLOR (36 << 24) # define R300_DST_BLEND_GL_ONE_MINUS_DST_COLOR (37 << 24) # define R300_DST_BLEND_GL_SRC_ALPHA (38 << 24) # define R300_DST_BLEND_GL_ONE_MINUS_SRC_ALPHA (39 << 24) # define R300_DST_BLEND_GL_DST_ALPHA (40 << 24) # define R300_DST_BLEND_GL_ONE_MINUS_DST_ALPHA (41 << 24) # define R300_DST_BLEND_MASK (63 << 24) #define R300_RB3D_COLORMASK
