r500 progress?
I remember reading something about Jerome Glisse leading up an effort too bring support to r500 based cards, though I don't recall if it was "officially" happening with in the DRI development process, or just a side effort for now to be folded in once working. Anyway, I would like find some way to help in any way I can, probably more by testing or gleaning information from the card with the various reverse engineering tools than actual programming however. I don't like the fglrx drivers, and I don't need something to play games with, at least a good 2D opensource driver and maybe enough 3D support to run a compositing window manager. I have a 256MB x1300 and also an integrated 200M(or what ever the official number is) card, and I just want to help as much as I can. Brandon Sharitt -- I am become Chuck Norris, the destroyer of worlds. --J. Robert Oppenheimer, upon testing of the first atomic bomb - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [r300] Fix reordering of fragment program instructions and register allocation
Another thought; the same changed are probably needed for the vertprog code. I think there are also a lot of bugs there. On 3/18/07, Oliver McFadden <[EMAIL PROTECTED]> wrote: > This patch seems to break one of my longer fragment programs. I believe this > is > because it's running out of registers, but I haven't looked into it in > detail > yet. > > I think this patch should be committed, but directly followed by a patch to > reduce the number of registers used. > > > On 3/18/07, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > > There were a number of bugs related to the pairing of vector and > > scalar operations where swizzles ended up using the wrong source > > register, or an instruction was moved forward and ended up overwriting > > an aliased register. > > > > The new algorithm for register allocation is slightly conservative and > > may run out of registers before it's strictly necessary. On the plus > > side, it Just Works. > > > > Pairing of instructions is done whenever possible, and in more cases > > than before, so in practice this change should be a net win. > > > > The patch mostly fixes glean/texCombine. One remaining problem is that > > the code duplicates constants and parameters all over the place and > > therefore quickly runs out of resources and falls back to software. > > I'm going to look into that as well. > > > > Please test and commit this patch. If you notice any regressions, > > please tell me (but the tests are looking good). > > > > ~Nicolai > > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [r300] Fix reordering of fragment program instructions and register allocation
This patch seems to break one of my longer fragment programs. I believe this is because it's running out of registers, but I haven't looked into it in detail yet. I think this patch should be committed, but directly followed by a patch to reduce the number of registers used. On 3/18/07, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > There were a number of bugs related to the pairing of vector and > scalar operations where swizzles ended up using the wrong source > register, or an instruction was moved forward and ended up overwriting > an aliased register. > > The new algorithm for register allocation is slightly conservative and > may run out of registers before it's strictly necessary. On the plus > side, it Just Works. > > Pairing of instructions is done whenever possible, and in more cases > than before, so in practice this change should be a net win. > > The patch mostly fixes glean/texCombine. One remaining problem is that > the code duplicates constants and parameters all over the place and > therefore quickly runs out of resources and falls back to software. > I'm going to look into that as well. > > Please test and commit this patch. If you notice any regressions, > please tell me (but the tests are looking good). > > ~Nicolai > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] [r300] Fix reordering of fragment program instructions and register allocation
There were a number of bugs related to the pairing of vector and
scalar operations where swizzles ended up using the wrong source
register, or an instruction was moved forward and ended up overwriting
an aliased register.
The new algorithm for register allocation is slightly conservative and
may run out of registers before it's strictly necessary. On the plus
side, it Just Works.
Pairing of instructions is done whenever possible, and in more cases
than before, so in practice this change should be a net win.
The patch mostly fixes glean/texCombine. One remaining problem is that
the code duplicates constants and parameters all over the place and
therefore quickly runs out of resources and falls back to software.
I'm going to look into that as well.
Please test and commit this patch. If you notice any regressions,
please tell me (but the tests are looking good).
~Nicolai
diff --git a/src/mesa/drivers/dri/r300/r300_context.h b/src/mesa/drivers/dri/r300/r300_context.h
index bd9ed6f..bc43953 100644
--- a/src/mesa/drivers/dri/r300/r300_context.h
+++ b/src/mesa/drivers/dri/r300/r300_context.h
@@ -647,38 +647,84 @@ struct r300_vertex_program_cont {
#define PFS_NUM_TEMP_REGS 32
#define PFS_NUM_CONST_REGS 16
-/* Tracking data for Mesa registers */
+/* Mapping Mesa registers to R300 temporaries */
struct reg_acc {
int reg;/* Assigned hw temp */
unsigned int refcount; /* Number of uses by mesa program */
};
+/**
+ * Describe the current lifetime information for an R300 temporary
+ */
+struct reg_lifetime {
+ /* Index of the first slot where this register is free in the sense
+ that it can be used as a new destination register.
+ This is -1 if the register has been assigned to a Mesa register
+ and the last access to the register has not yet been emitted */
+ int free;
+
+ /* Index of the first slot where this register is currently reserved.
+ This is used to stop e.g. a scalar operation from being moved
+ before the allocation time of a register that was first allocated
+ for a vector operation. */
+ int reserved;
+
+ /* Index of the first slot in which the register can be used as a
+ source without losing the value that is written by the last
+ emitted instruction that writes to the register */
+ int vector_valid;
+ int scalar_valid;
+};
+
+
+/**
+ * Store usage information about an ALU instruction slot during the
+ * compilation of a fragment program.
+ */
+#define SLOT_SRC_VECTOR (1<<0)
+#define SLOT_SRC_SCALAR (1<<3)
+#define SLOT_SRC_BOTH(SLOT_SRC_VECTOR | SLOT_SRC_SCALAR)
+#define SLOT_OP_VECTOR (1<<16)
+#define SLOT_OP_SCALAR (1<<17)
+#define SLOT_OP_BOTH (SLOT_OP_VECTOR | SLOT_OP_SCALAR)
+
+struct r300_pfs_compile_slot {
+ /* Bitmask indicating which parts of the slot are used, using SLOT_ constants
+ defined above */
+ unsigned int used;
+
+ /* Selected sources */
+ int vsrc[3];
+ int ssrc[3];
+};
+
+/**
+ * Store information during compilation of fragment programs.
+ */
struct r300_pfs_compile_state {
- int v_pos, s_pos; /* highest ALU slots used */
-
- /* Track some information gathered during opcode
-* construction.
-*
-* NOTE: Data is only set by the code, and isn't used yet.
-*/
- struct {
- int vsrc[3];
- int ssrc[3];
- int umask;
- } slot[PFS_MAX_ALU_INST];
-
- /* Used to map Mesa's inputs/temps onto hardware temps */
- int temp_in_use;
- struct reg_acc temps[PFS_NUM_TEMP_REGS];
- struct reg_acc inputs[32]; /* don't actually need 32... */
-
- /* Track usage of hardware temps, for register allocation,
-* indirection detection, etc. */
- int hwreg_in_use;
- GLuint used_in_node;
- GLuint dest_in_node;
+ int nrslots; /* number of ALU slots used so far */
+
+ /* Track which (parts of) slots are already filled with instructions */
+ struct r300_pfs_compile_slot slot[PFS_MAX_ALU_INST];
+
+ /* Track the validity of R300 temporaries */
+ struct reg_lifetime hwtemps[PFS_NUM_TEMP_REGS];
+
+ /* Used to map Mesa's inputs/temps onto hardware temps */
+ int temp_in_use;
+ struct reg_acc temps[PFS_NUM_TEMP_REGS];
+ struct reg_acc inputs[32]; /* don't actually need 32... */
+
+ /* Track usage of hardware temps, for register allocation,
+ * indirection detection, etc. */
+ GLuint used_in_node;
+ GLuint dest_in_node;
};
+/**
+ * Store everything about a fragment program that is needed
+ * to render with that program.
+ */
struct r300_fragment_program {
struct gl_fragment_program mesa_program;
diff --git a/src/mesa/drivers/dri/r300/r300_fragprog.c b/src/mesa/drivers/dri/r300/r300_fragprog.c
index 251fd26..b2c89cc 100644
--- a/src/mesa/drivers/dri/r300/r300_fragprog.c
+++ b/src/mesa/drivers/dri/r300/r300_fragprog.c
@@ -94,8 +94,9 @@
#define REG_NEGV_SHIFT 18
#define REG_NEGS_SHIFT 19
#define REG_ABS_SHIFT 20
-#define REG_NO_USE_SHIFT 21
-#define REG_VALID_SHIF
Re: compiling new xf86-video-intel drive
On Sat, 2007-03-17 at 12:44 -0700, Keith Packard wrote: > On Sat, 2007-03-17 at 16:41 +, Sergio Monteiro Basto wrote: > > Hi , > > I need your help , I am trying compile intel video drive and give me > > this: > > > > checking for xf86Modes.h... no > > symlink mode code > > configure: error: Must have X server >= 1.3 source tree for mode setting > > code. Please specify --with-xserver-source > > If you aren't building from the RC tarball, I am using lastest git > you'll need some source > files from the X server which include new functionality that can be > built into the driver when compiling for older servers. > > The tarball includes the needed files; if you're trying that and it > isn't working, then there's a build bug. > Ok but where is rc tarballs ? Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: compiling new xf86-video-intel drive
On Sat, 2007-03-17 at 16:41 +, Sergio Monteiro Basto wrote: > Hi , > I need your help , I am trying compile intel video drive and give me > this: > > checking for xf86Modes.h... no > symlink mode code > configure: error: Must have X server >= 1.3 source tree for mode setting > code. Please specify --with-xserver-source If you aren't building from the RC tarball, you'll need some source files from the X server which include new functionality that can be built into the driver when compiling for older servers. The tarball includes the needed files; if you're trying that and it isn't working, then there's a build bug. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Announcing Piglit, an automated testing framework
I notice some failures with the example tests (R300) that seem to just be slight precision errors; I think you should add a margin for error because usually the hardware will implement things in a faster, perhaps less precise way. This lower precision is still "good enough", though. On 3/17/07, Brian Paul <[EMAIL PROTECTED]> wrote: > Nicolai Haehnle wrote: > > Hello, > > > > back when I was actively working on DRI drivers almost three years > > ago, I always felt uneasy about the fact that I didn't have an > > extensive array of tests that I could rely on to test for regressions. > > > > Now I've decided to do something about it. I've taken Glean and some > > code from Mesa and wrapped it with Python and cmake glue to > > - execute OpenGL tests without user interaction and > > - neatly format the results in HTML > > > > You can find the current version (and a sample HTML summary, to get an > > idea of what they look like at the moment) at > > http://homepages.upb.de/prefect/piglit/ > > > > The idea is to make testing dead simple for driver developers. I > > believe that Piglit already makes it quite simple, but I'm sure > > there's still room for improvement. > > > > My current plans are: > > - Hunt some bugs in R300, to get a better feeling for how the tool > > fares in practice > > - Integrate tests from Mesa; unfortunately, this needs manual work > > because those tests are mainly interactive, but it's definitely > > necessary to make this useful > > > > I'm also considering setting up a public repository somewhere, perhaps > > on Sourceforge. > > > > Please give it a try when you have a little time to spare and tell me > > if you find it useful (or more importantly, why you don't find it > > useful), and where it could be improved. > > I'll try to give it a try when I have some time. > > For now though I've added a link to Piglit from the Glean home page. > > -Brian > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: compiling new xf86-video-intel drive
On Saturday, March 17, 2007, Sergio Monteiro Basto wrote: > Hi , > I need your help , I am trying compile intel video drive and give me > this: > > checking for xf86Modes.h... no > symlink mode code > configure: error: Must have X server >= 1.3 source tree for mode setting > code. Please specify --with-xserver-source > + exit 1 > > what I need upgrade is just xorg-x11-server-Xorg-1.1.1 ? This is probably a better question for [EMAIL PROTECTED], but you'll need the sources for a 1.3+ server tree to build the latest Intel driver. Just check it out in the parent directory of your Intel driver tree and the configure scripts should find it. If that doesn't work, send a note to [EMAIL PROTECTED] Jesse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
compiling new xf86-video-intel drive
Hi , I need your help , I am trying compile intel video drive and give me this: checking for xf86Modes.h... no symlink mode code configure: error: Must have X server >= 1.3 source tree for mode setting code. Please specify --with-xserver-source + exit 1 what I need upgrade is just xorg-x11-server-Xorg-1.1.1 ? Tanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Announcing Piglit, an automated testing framework
Nicolai Haehnle wrote: > Hello, > > back when I was actively working on DRI drivers almost three years > ago, I always felt uneasy about the fact that I didn't have an > extensive array of tests that I could rely on to test for regressions. > > Now I've decided to do something about it. I've taken Glean and some > code from Mesa and wrapped it with Python and cmake glue to > - execute OpenGL tests without user interaction and > - neatly format the results in HTML > > You can find the current version (and a sample HTML summary, to get an > idea of what they look like at the moment) at > http://homepages.upb.de/prefect/piglit/ > > The idea is to make testing dead simple for driver developers. I > believe that Piglit already makes it quite simple, but I'm sure > there's still room for improvement. > > My current plans are: > - Hunt some bugs in R300, to get a better feeling for how the tool > fares in practice > - Integrate tests from Mesa; unfortunately, this needs manual work > because those tests are mainly interactive, but it's definitely > necessary to make this useful > > I'm also considering setting up a public repository somewhere, perhaps > on Sourceforge. > > Please give it a try when you have a little time to spare and tell me > if you find it useful (or more importantly, why you don't find it > useful), and where it could be improved. I'll try to give it a try when I have some time. For now though I've added a link to Piglit from the Glean home page. -Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10303] glFogCoordPointer broken in DRI Radeon R300 driver
http://bugs.freedesktop.org/show_bug.cgi?id=10303 --- Comment #6 from [EMAIL PROTECTED] 2007-03-17 05:32 PST --- Dave Airlie already committed this. Commit 6a9b0cd0b43ba01b24871ec1fa155e192ddeaa56. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
