[Mesa3d-dev] [PATCH 1/2] nouveau/nv04: very primitive line/point render
This time it renders progs/demos/bounce and progs/samples/sphere correctly.
From 1848ef2fc2b25a49e555c5f23694b9df590756b2 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu rand...@mail.ru
Date: Tue, 9 Mar 2010 06:24:16 +
Subject: [PATCH 1/2] nouveau/nv04: very primitive line/point render
---
src/mesa/drivers/dri/nouveau/nv04_render.c | 156
1 files changed, 156 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_render.c b/src/mesa/drivers/dri/nouveau/nv04_render.c
index b5943d9..633fbb1 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_render.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_render.c
@@ -36,6 +36,18 @@
#define NUM_VERTEX_ATTRS 6
+typedef struct
+{
+ float ScreenX;
+ float ScreenY;
+ float ScreenZ;
+ float EyeM;
+ unsigned int Color;
+ unsigned int Specular;
+ float TextureS;
+ float TextureT;
+} NV_HW_Vertex;
+
static void
swtnl_update_viewport(GLcontext *ctx)
{
@@ -148,11 +160,155 @@ swtnl_reset_stipple(GLcontext *ctx)
static void
swtnl_points(GLcontext *ctx, GLuint first, GLuint last)
{
+ int i;
+
+ GLfloat pointSize = ctx-Point.Size * 0.5; // was 0.75
+ GLfloat dx, dy, z, z1;
+ GLfloat x,y;
+ NV_HW_Vertex vertex_four[4];
+
+
+for (i=first;i=last;i++)
+{
+
+
+ x = ((float *) _tnl_get_vertex( ctx, i ))[0];
+ y = ((float *) _tnl_get_vertex( ctx, i ))[1];
+
+/* Populate NV_HW_vertex */
+ vertex_four[0].ScreenX = x - pointSize;
+ vertex_four[0].ScreenY = y + pointSize;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, i ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, i ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, i ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, i ))[5];
+ vertex_four[0].TextureS = ((float *) _tnl_get_vertex( ctx, i ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, i ))[7];
+
+ vertex_four[1].ScreenX = x - pointSize;
+ vertex_four[1].ScreenY = y - pointSize;
+ vertex_four[1].ScreenZ = ((float *) _tnl_get_vertex( ctx, i ))[2];
+ vertex_four[1].EyeM = ((float *) _tnl_get_vertex( ctx, i ))[3];
+ vertex_four[1].Color = ((unsigned int *) _tnl_get_vertex( ctx, i ))[4];
+ vertex_four[1].Specular = ((unsigned int *) _tnl_get_vertex( ctx, i ))[5];
+ vertex_four[1].TextureS = ((float *) _tnl_get_vertex( ctx, i ))[6];
+ vertex_four[1].TextureT = ((float *) _tnl_get_vertex( ctx, i ))[7];
+
+ vertex_four[2].ScreenX = x + pointSize;
+ vertex_four[2].ScreenY = y - pointSize;
+ vertex_four[2].ScreenZ = ((float *) _tnl_get_vertex( ctx, i ))[2];
+ vertex_four[2].EyeM = ((float *) _tnl_get_vertex( ctx, i ))[3];
+ vertex_four[2].Color = ((unsigned int *) _tnl_get_vertex( ctx, i ))[4];
+ vertex_four[2].Specular = ((unsigned int *) _tnl_get_vertex( ctx, i ))[5];
+ vertex_four[2].TextureS = ((float *) _tnl_get_vertex( ctx, i ))[6];
+ vertex_four[2].TextureT = ((float *) _tnl_get_vertex( ctx, i ))[7];
+
+ vertex_four[3].ScreenX = x + pointSize;
+ vertex_four[3].ScreenY = y + pointSize;
+ vertex_four[3].ScreenZ = ((float *) _tnl_get_vertex( ctx, i ))[2];
+ vertex_four[3].EyeM = ((float *) _tnl_get_vertex( ctx, i ))[3];
+ vertex_four[3].Color = ((unsigned int *) _tnl_get_vertex( ctx, i ))[4];
+ vertex_four[3].Specular = ((unsigned int *) _tnl_get_vertex( ctx, i ))[5];
+ vertex_four[3].TextureS = ((float *) _tnl_get_vertex( ctx, i ))[6];
+ vertex_four[3].TextureT = ((float *) _tnl_get_vertex( ctx, i ))[7];
+
+
+ BEGIN_PRIMITIVE(4);
+ OUT_RINGp(chan, vertex_four[0], vertex_len);
+ OUT_RINGp(chan, vertex_four[1], vertex_len);
+ OUT_RINGp(chan, vertex_four[2], vertex_len);
+ OUT_RINGp(chan, vertex_four[3], vertex_len);
+ END_PRIMITIVE(0x320210);
+}
}
+
static void
swtnl_line(GLcontext *ctx, GLuint v1, GLuint v2)
{
+ GLfloat LineWidth;
+ GLfloat dx, dy, z, z1;
+ GLfloat x1,x2,y1,y2;
+ NV_HW_Vertex vertex_four[4];
+
+ GLfloat pos_tmp1[4]; /*x,y,z,w */
+ GLfloat pos_tmp2[4]; /*x,y,z,w */
+
+ LineWidth = ctx-Line.Width * 0.5F;
+
+ /*
+ * Get line extents.
+ */
+
+ x1 = ((float *) _tnl_get_vertex( ctx, v1 ))[0];
+ x2 = ((float *) _tnl_get_vertex( ctx, v2 ))[0];
+ y1 = ((float *) _tnl_get_vertex( ctx, v1 ))[1];
+ y2 = ((float *) _tnl_get_vertex( ctx, v2 ))[1];
+
+/*
+* Determine major and minor axis.
+*/
+
+ dx = x2 - x1; dy = y2 - y1;
+ if (fabs(dx) fabs(dy))
+ {
+ dy = LineWidth;
+ dx = 0.0F;
+ }
+ else
+ {
+ dx = LineWidth;
+ dy = 0.0F;
+ }
+
+ // z = ((float *) _tnl_get_vertex( ctx, v1 ))[2] + ctx-LineOffset;
+
+
+/* Populate NV_HW_vertex */
+ vertex_four[0].ScreenX = x1 - dx;
+ vertex_four[0].ScreenY = y1 - dy;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, v1 ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, v1 ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, v1 ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, v1 ))[5];
+ vertex_four[0].TextureS = ((float *)
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
Brian Paul wrote: Keith Whitwell wrote: This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. My PS3 is still going- I'll look into it. OK, it compiles but it doesn't run at all. The SPUs immediately crash because of invalid commands in the batch buffers. I suspect there's other breakage in texture handing and displaying of display targets. I don't have time to fix this so I guess cell will stay broken for a while. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium cached bufmgr busy change
We can do this optimisation with busy as well. As long as you add things to the busy list at the end, and stop testing after the first busy call. At least for a single linear GPU context, which is all I expect this code will ever be handling. Wouldn't this just end up reinventing the fenced bufmgr? Basically cached needs a list of all destroyed buffers (ideally in destruction order, so it can do the stopping optimization when expiring buffers), while the busy mechanism needs a list of all used buffers (destroyed or not) in usage order. So it seems it would need two lists, and essentially result in something that replicates fenced inside cached. BTW, right now I think all drivers use a single GPU context in userspace. Even Nouveau multiplexes Gallium contexts on a single channel (this is probably broken though). -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
On Tue, 2010-03-09 at 06:36 -0800, Brian Paul wrote: Keith Whitwell wrote: This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. My PS3 is still going- I'll look into it. Thanks Brian. Hopefully it's clear what's going on - it's just a port of the equivalent code from llvmpipe, plus a change to do the display-target untwiddling inside the driver rather than in the winsys. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
Keith Whitwell wrote: This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. My PS3 is still going- I'll look into it. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium-sw-api-2, cell driver alert!
This is getting close to ready to merge, so please take a look if you're interested in the software rasterizers. Heads up that I've had to do some work on the cell driver in the gallium-sw-api-2 branch to migrate it to the new shared sw_winsys implementation. Unfortunately I don't have the cell SDK installed, so I can't even compile-test the changes. Hopefully someone out there who cares about cell can take a look, but I don't want to hold up merging this branch if nobody jumps on it. This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote: This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Dave had some code that fixes this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Minor gallium changes
On Tue, Mar 9, 2010 at 6:37 AM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-03-08 at 15:28 -0800, Brian Paul wrote: 1. Rename pipe_sampler_state:min_mip_filter to mip_filter. I don't know that the min part of that field refers to. 2. Remove PIPE_MAX_TEXTURE_LEVELS from p_state.h This token isn't used anywhere in the gallium interface anymore, nor the state trackers. I've already removed the use of this token in the gallium drivers (use per-driver #defines instead). There's still some use in the blitter code though. This looks fine. 3. BTW, none of these #defines are used in the gallium interface header files: PIPE_MAX_CONSTANT_BUFFERS PIPE_MAX_ATTRIBS PIPE_MAX_SAMPLERS PIPE_MAX_VERTEX_SAMPLERS They are used in the utility code and drivers though. Should we define these in the gallium interface if they're not used by the interface itself? PIPE_MAX_SAMPLERS / PIPE_MAX_VERTEX_SAMPLERS are the maximum argument set_fragment_sampler_textures/set_vertex_sampler_textures. These are indeed unnecessary given that there are corresponding caps queries. So state trackers should use arrays big enough to represent the API limits, and pipe drivers should use arrays big enough to represent the hardware limits, and both should agree on what's passed via the caps. Ditto for PIPE_MAX_CONSTANT_BUFFERS. I'm not sure about PIPE_MAX_ATTRIBS though. Can't find a caps for it. Since the drivers need to know those limits, can we doc them? I've been looking them up in the headers when I need to see their values, and I know I'm not the only one. ~ C. -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote: This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Dave had some code that fixes this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. It's just a cleanup at this point, no urgency. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 1/4] nouveau/nv04: very primitive line/point render
Playing with lines, some trivial/*-unfilled-* demos works, tri-unfilled-smooth
renders wrong (as one big smooth tri, not as small smooth tre inside unfilled
one). Also, clipping is wrong, as show by tri-unfilled-clip.
This is more playground, hwen i'll have 6 or 8 optimized polygon rendering
functions, it will be much less fun to code all those fixups in driver, so,
t_dd_tritmp.h calling .
From 1848ef2fc2b25a49e555c5f23694b9df590756b2 Mon Sep 17 00:00:00 2001
From: Andrew Randrianasulu rand...@mail.ru
Date: Tue, 9 Mar 2010 06:24:16 +
Subject: [PATCH 1/4] nouveau/nv04: very primitive line/point render
---
src/mesa/drivers/dri/nouveau/nv04_render.c | 156
1 files changed, 156 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nv04_render.c b/src/mesa/drivers/dri/nouveau/nv04_render.c
index b5943d9..633fbb1 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_render.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_render.c
@@ -36,6 +36,18 @@
#define NUM_VERTEX_ATTRS 6
+typedef struct
+{
+ float ScreenX;
+ float ScreenY;
+ float ScreenZ;
+ float EyeM;
+ unsigned int Color;
+ unsigned int Specular;
+ float TextureS;
+ float TextureT;
+} NV_HW_Vertex;
+
static void
swtnl_update_viewport(GLcontext *ctx)
{
@@ -148,11 +160,155 @@ swtnl_reset_stipple(GLcontext *ctx)
static void
swtnl_points(GLcontext *ctx, GLuint first, GLuint last)
{
+ int i;
+
+ GLfloat pointSize = ctx-Point.Size * 0.5; // was 0.75
+ GLfloat dx, dy, z, z1;
+ GLfloat x,y;
+ NV_HW_Vertex vertex_four[4];
+
+
+for (i=first;i=last;i++)
+{
+
+
+ x = ((float *) _tnl_get_vertex( ctx, i ))[0];
+ y = ((float *) _tnl_get_vertex( ctx, i ))[1];
+
+/* Populate NV_HW_vertex */
+ vertex_four[0].ScreenX = x - pointSize;
+ vertex_four[0].ScreenY = y + pointSize;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, i ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, i ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, i ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, i ))[5];
+ vertex_four[0].TextureS = ((float *) _tnl_get_vertex( ctx, i ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, i ))[7];
+
+ vertex_four[1].ScreenX = x - pointSize;
+ vertex_four[1].ScreenY = y - pointSize;
+ vertex_four[1].ScreenZ = ((float *) _tnl_get_vertex( ctx, i ))[2];
+ vertex_four[1].EyeM = ((float *) _tnl_get_vertex( ctx, i ))[3];
+ vertex_four[1].Color = ((unsigned int *) _tnl_get_vertex( ctx, i ))[4];
+ vertex_four[1].Specular = ((unsigned int *) _tnl_get_vertex( ctx, i ))[5];
+ vertex_four[1].TextureS = ((float *) _tnl_get_vertex( ctx, i ))[6];
+ vertex_four[1].TextureT = ((float *) _tnl_get_vertex( ctx, i ))[7];
+
+ vertex_four[2].ScreenX = x + pointSize;
+ vertex_four[2].ScreenY = y - pointSize;
+ vertex_four[2].ScreenZ = ((float *) _tnl_get_vertex( ctx, i ))[2];
+ vertex_four[2].EyeM = ((float *) _tnl_get_vertex( ctx, i ))[3];
+ vertex_four[2].Color = ((unsigned int *) _tnl_get_vertex( ctx, i ))[4];
+ vertex_four[2].Specular = ((unsigned int *) _tnl_get_vertex( ctx, i ))[5];
+ vertex_four[2].TextureS = ((float *) _tnl_get_vertex( ctx, i ))[6];
+ vertex_four[2].TextureT = ((float *) _tnl_get_vertex( ctx, i ))[7];
+
+ vertex_four[3].ScreenX = x + pointSize;
+ vertex_four[3].ScreenY = y + pointSize;
+ vertex_four[3].ScreenZ = ((float *) _tnl_get_vertex( ctx, i ))[2];
+ vertex_four[3].EyeM = ((float *) _tnl_get_vertex( ctx, i ))[3];
+ vertex_four[3].Color = ((unsigned int *) _tnl_get_vertex( ctx, i ))[4];
+ vertex_four[3].Specular = ((unsigned int *) _tnl_get_vertex( ctx, i ))[5];
+ vertex_four[3].TextureS = ((float *) _tnl_get_vertex( ctx, i ))[6];
+ vertex_four[3].TextureT = ((float *) _tnl_get_vertex( ctx, i ))[7];
+
+
+ BEGIN_PRIMITIVE(4);
+ OUT_RINGp(chan, vertex_four[0], vertex_len);
+ OUT_RINGp(chan, vertex_four[1], vertex_len);
+ OUT_RINGp(chan, vertex_four[2], vertex_len);
+ OUT_RINGp(chan, vertex_four[3], vertex_len);
+ END_PRIMITIVE(0x320210);
+}
}
+
static void
swtnl_line(GLcontext *ctx, GLuint v1, GLuint v2)
{
+ GLfloat LineWidth;
+ GLfloat dx, dy, z, z1;
+ GLfloat x1,x2,y1,y2;
+ NV_HW_Vertex vertex_four[4];
+
+ GLfloat pos_tmp1[4]; /*x,y,z,w */
+ GLfloat pos_tmp2[4]; /*x,y,z,w */
+
+ LineWidth = ctx-Line.Width * 0.5F;
+
+ /*
+ * Get line extents.
+ */
+
+ x1 = ((float *) _tnl_get_vertex( ctx, v1 ))[0];
+ x2 = ((float *) _tnl_get_vertex( ctx, v2 ))[0];
+ y1 = ((float *) _tnl_get_vertex( ctx, v1 ))[1];
+ y2 = ((float *) _tnl_get_vertex( ctx, v2 ))[1];
+
+/*
+* Determine major and minor axis.
+*/
+
+ dx = x2 - x1; dy = y2 - y1;
+ if (fabs(dx) fabs(dy))
+ {
+ dy = LineWidth;
+ dx = 0.0F;
+ }
+ else
+ {
+ dx = LineWidth;
+ dy = 0.0F;
+ }
+
+ // z = ((float *) _tnl_get_vertex( ctx, v1 ))[2] + ctx-LineOffset;
+
+
+/* Populate NV_HW_vertex */
+ vertex_four[0].ScreenX = x1 - dx;
+ vertex_four[0].ScreenY = y1 - dy;
+
[Mesa3d-dev] Commit messages broken??
I haven't seen any of these for a while now... Anyone have any ideas? Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote: This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Dave had some code that fixes this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. It's just a cleanup at this point, no urgency. I'll try and merge the easy bits of my branch to get drop u_simple_screen first. then worry about the cached mgr stuff. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] sw-api-2 branch
This has reached a point where I could think about merging it. There is plenty more cleanup to do, but the branch makes some big strides and introduces a couple of concepts that I've wanted for a long time. In particular the idea of a designated targets subtree which has code for explicitly constructing driver stacks. Secondly the ability to inject layers into (at least) the software stacks has been greatly improved, and I'd like to see us build on that for hardware drivers as well. There is probably still some bugfix to come, but if you're interested in the software rasterizers, please check out this branch and let me know how much I've broken things... Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium-sw-api-2, cell driver alert!
On Tue, 2010-03-09 at 12:43 -0800, Dave Airlie wrote: On Wed, Mar 10, 2010 at 2:31 AM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-03-09 at 08:19 -0800, Corbin Simpson wrote: On Tue, Mar 9, 2010 at 6:08 AM, Keith Whitwell kei...@vmware.com wrote: This leaves r300g as the only remaining user of pipe_winsys/u_simple_screen - which means we can rename that code r300_winsys and pull it into that driver... Dave had some code that fixes this, I think. I more or less agreed to stay out of it, but I might take a look if killing u_simple_screen is a priority. It's just a cleanup at this point, no urgency. I'll try and merge the easy bits of my branch to get drop u_simple_screen first. then worry about the cached mgr stuff. Sure, whenever it's convenient. Keith -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Piglit fbo tests
Hi, following 3 piglit tests are failing on r300 because they're trying to use GL_ARB_texture_non_power_of_two without checking if this extension is available: fbo-blit fbo-nodepth-test fbo-nostencil-test I'm not sure what solution is preferable, 1) change the teximage sizes to be POT, 2) require ARB_texture_npot. I've tried first solution for fbo-blit but it segfaults, trying to execute function at null address, so it would require some more investigation. Regards, Maciej -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Commit messages broken??
Keith Whitwell wrote: I haven't seen any of these for a while now... Anyone have any ideas? I haven't seen them either. I don't know what's going on, but Tollef Fog Heen (an FD.org admin) created new mesa lists on fd.o yesterday (though Michel and I haven't move the subscriber lists yet). Perhaps something broke from that? Tollef? -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Piglit fbo tests
Maciej Cencora wrote: Hi, following 3 piglit tests are failing on r300 because they're trying to use GL_ARB_texture_non_power_of_two without checking if this extension is available: fbo-blit fbo-nodepth-test fbo-nostencil-test I'm not sure what solution is preferable, 1) change the teximage sizes to be POT, 2) require ARB_texture_npot. I've tried first solution for fbo-blit but it segfaults, trying to execute function at null address, so it would require some more investigation. We should use POT texture sizes so that the test always does _something_. Where's the crash? -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] code generation for dynamic extensions broken ?
On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Sapountzis wrote: I made a small test to test code genration for dynamic extensions in http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-test When using libGL + swrast_dri.so from getproc-test, the dynamic extensions code is not exercised and the test passes. When using libGL from mesa 7.7 and swrast_dri.so from getproc-test, the extension string does contain GL_MESA_test_extension but the test segfaults. There are a few places where this could break. - The generated dispatch stub function is wrong. - The dispatch offset used by the driver is wrong. - The dispatch remapping used by the driver is wrong. It turned out that there were two bugs in glapi. One with using non-exec memory and the other with using an un-relocated function template for entry-point generation. I put fixes at: http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-debug I also tested with libGL pretending to not know fbo extensions, the fbo* demos and tests render correctly. I get a warning about an invalid enum in RenderbufferStorageMultisample(target) but i don't know where it comes from and it does not affect rendering. Since we are already generating static dispatch stubs for all known extensions, I guess we can add a few more static stubs and use them, instead of generating on-the-fly. I put an example about this in the getproc-debug branch, but I don't know if it's a good idea. regards, George. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] code generation for dynamic extensions broken ?
On Wed, Mar 10, 2010 at 2:18 AM, George Sapountzis gsapount...@gmail.com wrote: I also tested with libGL pretending to not know fbo extensions, the fbo* demos and tests render correctly. I get a warning about an invalid enum in RenderbufferStorageMultisample(target) but i don't know where it comes from and it does not affect rendering. ignore the warning, it's due to a forgotten debugging call to the first dynamic function assuming it's the test extension, which is not the case with fbo. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] code generation for dynamic extensions broken ?
George Sapountzis gsapount...@gmail.com writes: On Mon, Mar 8, 2010 at 10:37 PM, Ian Romanick i...@freedesktop.org wrote: George Sapountzis wrote: When using libGL from mesa 7.7 and swrast_dri.so from getproc-test, the extension string does contain GL_MESA_test_extension but the test segfaults. There are a few places where this could break. - The generated dispatch stub function is wrong. - The dispatch offset used by the driver is wrong. - The dispatch remapping used by the driver is wrong. It turned out that there were two bugs in glapi. One with using non-exec memory and the other with using an un-relocated function template for entry-point generation. I put fixes at: http://cgit.freedesktop.org/~gsap7/mesa/log/?h=getproc-debug Some comments: e38a234.. shouldn't get merged as-is, right? I mean, there must be some sort of mesa_debug macro or similar, so that debug messages are configurable. ditto for d0b35e9. d6c973c is a strange patch; the additions to GLAPI_SOURCES seem unrelated to the patch itself. 977d5d: it seems like there should be some other way to disable this. I've been trying to make time to have these XMLs be exhaustive in their coverage of GL and GLX extensions, for example, which is good for other reasons. Most importantly: have you tested with mangled symbols (compile w/ USE_MGL_NAMESPACE defined)? It looks like the functions added in 682971c need #ifdef MANGLE cases. A few months back, I noticed some cases of doing function lookup without considering mangled symbols, but couldn't reproduce it in my setup. I think it had to do with loading the symbols from a DRI driver. It might have even been fine, i.e. a higher level scrubbed out the mangling. I guess I'm saying that if you tested mangling it still works, great, `done' in my book :) Cheers, -tom -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] code generation for dynamic extensions broken ?
Some comments: e38a234.. shouldn't get merged as-is, right? I mean, there must be some sort of mesa_debug macro or similar, so that debug messages are configurable. ditto for d0b35e9. right. from getproc-cleaunp..getproc-debug only the two fixes will be merged d6c973c is a strange patch; the additions to GLAPI_SOURCES seem unrelated to the patch itself. mesa_exec_malloc is defined in the added sources from main/ 977d5d: it seems like there should be some other way to disable this. I've been trying to make time to have these XMLs be exhaustive in their coverage of GL and GLX extensions, for example, which is good for other reasons. that was in order to test adding fbo extensions on-the-fly, not intended for merging. Most importantly: have you tested with mangled symbols (compile w/ USE_MGL_NAMESPACE defined)? It looks like the functions added in 682971c need #ifdef MANGLE cases. the commit just moves code. I guess get_extension_proc() needs ifdef's for mangle similar to get_static_proc(), but that can be fixed separately thanks, George. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] sw-api-2 branch
Dear Keith, I've downloaded your sw-api-2 branch using the .tar.gz method again(git just won't let me).I used the same ./configure options but with the exception of doing --prefix=/usr/local instaed od /usr just in case. It was compiling fine until it hit this error: gmake[4]: Entering directory `/opt/mesa-gallium-sw-api-2/src/gallium/drivers/nv30' gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 nv30_clear.c -o nv30_clear.o gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 nv30_context.c -o nv30_context.o gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 nv30_draw.c -o nv30_draw.o gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 nv30_fragprog.c -o nv30_fragprog.o gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 nv30_fragtex.c -o nv30_fragtex.o gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 nv30_miptree.c -o nv30_miptree.o nv30_miptree.c: In function ‘nv30_screen_init_miptree_functions’: nv30_miptree.c:239: error: ‘nv50_miptree_blanket’ undeclared (first use in this function) nv30_miptree.c:239: error: (Each undeclared identifier is reported only once nv30_miptree.c:239: error: for each function it appears in.) gmake[4]: *** [nv30_miptree.o] Error 1 gmake[4]: Leaving directory `/opt/mesa-gallium-sw-api-2/src/gallium/drivers/nv30' gmake[3]: *** [default] Error 1 gmake[3]: Leaving directory `/opt/mesa-gallium-sw-api-2/src/gallium/drivers' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/opt/mesa-gallium-sw-api-2/src/gallium' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/opt/mesa-gallium-sw-api-2/src' gmake: *** [default] Error 1 Regards, STEVE555 Keith Whitwell-3 wrote: This has reached a point where I could think about merging it. There is plenty more cleanup to do, but the branch makes some big strides and introduces a couple of concepts that I've wanted for a long time. In particular the idea of a designated targets subtree which has code for explicitly constructing driver stacks. Secondly the ability to inject layers into (at least) the software stacks has been greatly improved, and I'd like to see us build on that for hardware drivers as well. There is probably still some bugfix to come,
