Re: [Mesa3d-dev] [PATCH] Fix syntax screw ups introduced in 016fc30, 6e8e4b9 and f7dde2c.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This should already be fixed. Sorry for the noise. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuPG/AACgkQX1gOwKyEAw/bqgCffi8cMZUH0+nePKUphtUInOMz QgAAn1wmaT3jZzTGzngfDXIfAaKu4bmW =SlKd -END PGP SIGNATURE- -- Download Intel® 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] Fix syntax screw ups introduced in 016fc30, 6e8e4b9 and f7dde2c.
From: Bo Ørsted Andresen
---
src/glx/indirect.h |2 +-
src/glx/indirect_size.c |2 +-
src/glx/indirect_size.h |2 +-
src/mesa/glapi/gen/gl_XML.py |2 +-
src/mesa/glapi/glapitemp.h |2 +-
src/mesa/main/compiler.h |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/glx/indirect.h b/src/glx/indirect.h
index 7064bfe..5c56f4f 100644
--- a/src/glx/indirect.h
+++ b/src/glx/indirect.h
@@ -37,7 +37,7 @@
* \author Ian Romanick
*/
-# if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) &&
defined(__ELF__)
+# if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) &&
defined(__ELF__)
#define HIDDEN __attribute__((visibility("hidden")))
# else
#define HIDDEN
diff --git a/src/glx/indirect_size.c b/src/glx/indirect_size.c
index 5a8f27b..af15a2e 100644
--- a/src/glx/indirect_size.c
+++ b/src/glx/indirect_size.c
@@ -41,7 +41,7 @@
#define FASTCALL
# endif
-# if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) &&
defined(__ELF__)
+# if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) &&
defined(__ELF__)
#define INTERNAL __attribute__((visibility("internal")))
# else
#define INTERNAL
diff --git a/src/glx/indirect_size.h b/src/glx/indirect_size.h
index 43f504a..a6445af 100644
--- a/src/glx/indirect_size.h
+++ b/src/glx/indirect_size.h
@@ -48,7 +48,7 @@
#define FASTCALL
# endif
-# if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) &&
defined(__ELF__)
+# if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) &&
defined(__ELF__)
#define INTERNAL __attribute__((visibility("internal")))
# else
#define INTERNAL
diff --git a/src/mesa/glapi/gen/gl_XML.py b/src/mesa/glapi/gen/gl_XML.py
index b769ee2..15db87b 100644
--- a/src/mesa/glapi/gen/gl_XML.py
+++ b/src/mesa/glapi/gen/gl_XML.py
@@ -224,7 +224,7 @@ class gl_print_base:
"""
self.undef_list.append(S)
- print """# if defined(__GNUC__) || (defined(__SUNPRO_C) &&
(__SUNPRO_C >= 0x590))) && defined(__ELF__)
+ print """# if (defined(__GNUC__) || (defined(__SUNPRO_C) &&
(__SUNPRO_C >= 0x590))) && defined(__ELF__)
#define %s __attribute__((visibility("%s")))
# else
#define %s
diff --git a/src/mesa/glapi/glapitemp.h b/src/mesa/glapi/glapitemp.h
index f9b803e..92023c3 100644
--- a/src/mesa/glapi/glapitemp.h
+++ b/src/mesa/glapi/glapitemp.h
@@ -27,7 +27,7 @@
*/
-# if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) &&
defined(__ELF__)
+# if (defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))) &&
defined(__ELF__)
#define HIDDEN __attribute__((visibility("hidden")))
# else
#define HIDDEN
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 05e69e5..81704ae 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -173,7 +173,7 @@ extern "C" {
* We also need to define a USED attribute, so the optimizer doesn't
* inline a static function that we later use in an alias. - ajax
*/
-#if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590)
+#if defined(__GNUC__) || (defined(__SUNPRO_C) && (__SUNPRO_C >= 0x590))
# define PUBLIC __attribute__((visibility("default")))
# define USED __attribute__((used))
#else
--
1.7.0.1
--
Download Intel® 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] [Bug 26875] src/mesa/main/compiler.h:176:26: error: missing ')' in expression
http://bugs.freedesktop.org/show_bug.cgi?id=26875 Thomas Anderson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Thomas Anderson 2010-03-03 17:54:12 PST --- (In reply to comment #0) > Hi! Problem compiling mesa git master: > > In file included from ../../src/mesa/main/mtypes.h:39, > from main/api_arrayelt.h:31, > from main/api_arrayelt.c:30: > ../../src/mesa/main/compiler.h:176:26: error: missing ')' in expression > In file included from ../main/mtypes.h:39, > from gen_matypes.c:36: > ../main/compiler.h:176:26: error: missing ')' in expression > make[3]: *** [gen_matypes] Error 1 > make[3]: Leaving directory `/home/neo/mesa/src/mesa/x86' > make[2]: *** [asm_subdirs] Error 1 > make[2]: *** Waiting for unfinished jobs > make[2]: *** [main/api_arrayelt.o] Error 1 > make[2]: Leaving directory `/home/neo/mesa/src/mesa' > make[1]: *** [subdirs] Error 1 > make[1]: Leaving directory `/home/neo/mesa/src' > make: *** [default] Error 1 > > If I did something wrong and this isn't valid, please let me know what I did > wrong. Thank you. > idr just fixed it. Thanks! -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel® 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] [Bug 26875] New: src/mesa/main/compiler.h:176:26: error: missing ')' in expression
http://bugs.freedesktop.org/show_bug.cgi?id=26875 Summary: src/mesa/main/compiler.h:176:26: error: missing ')' in expression Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: neotheu...@ymail.com Hi! Problem compiling mesa git master: In file included from ../../src/mesa/main/mtypes.h:39, from main/api_arrayelt.h:31, from main/api_arrayelt.c:30: ../../src/mesa/main/compiler.h:176:26: error: missing ')' in expression In file included from ../main/mtypes.h:39, from gen_matypes.c:36: ../main/compiler.h:176:26: error: missing ')' in expression make[3]: *** [gen_matypes] Error 1 make[3]: Leaving directory `/home/neo/mesa/src/mesa/x86' make[2]: *** [asm_subdirs] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [main/api_arrayelt.o] Error 1 make[2]: Leaving directory `/home/neo/mesa/src/mesa' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/neo/mesa/src' make: *** [default] Error 1 If I did something wrong and this isn't valid, please let me know what I did wrong. Thank you. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel® 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] writing line emulation for hw driver?
Hello all!
I recently plugged in old TNT2 (nv05) card and started to playing with it.
This hardware can do quads and triangles, but not lines or points So, i
need to emulate them.
utah-glx has some code exactly for this generation of hardware:
http://utah-glx.cvs.sourceforge.net/viewvc/utah-glx/glx-xf3/servGL/hwglx/nv/riva_prim.c?revision=1.11&view=markup
I tried to cook up something like this for current nouveau driver, but nearly
failed.
Lack of hardware PolygonOffset support lead me into
src/mesa/tnl_dd/t_dd_tritmp.h , used in many drivers. Currently, it can only
DE-compose triangles, but can (or better - should) it be abjusted for
creating additional vertex info (2->4, 1->4) ?
Should one still use this file in modern world? On non-hw-tcl capable hw .
diff --git a/src/mesa/drivers/dri/nouveau/nv04_render.c b/src/mesa/drivers/dri/nouveau/nv04_render.c
index b5943d9..ce6bf98 100644
--- a/src/mesa/drivers/dri/nouveau/nv04_render.c
+++ b/src/mesa/drivers/dri/nouveau/nv04_render.c
@@ -148,11 +148,128 @@ swtnl_reset_stipple(GLcontext *ctx)
static void
swtnl_points(GLcontext *ctx, GLuint first, GLuint last)
{
+GLfloat pointSize;
+
+pointSize = ctx->Point.Size * 0.75;
+
+
+#if 0
+ BEGIN_PRIMITIVE(4);
+ OUT_VERTEX(first);
+ OUT_VERTEX(last);
+ OUT_VERTEX(first);
+ OUT_VERTEX(last);
+ END_PRIMITIVE(0x320210);
+#endif
}
static void
swtnl_line(GLcontext *ctx, GLuint v1, GLuint v2)
{
+#if 1
+typedef unsigned int U032;
+
+typedef struct
+{
+ float ScreenX;
+ float ScreenY;
+ float ScreenZ;
+ float EyeM;
+ U032 Color;
+ U032 Specular;
+ float TextureS;
+ float TextureT;
+} NV_HW_Vertex;
+
+
+
+ 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 *) _tnl_get_vertex( ctx, v1 ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, v1 ))[7];
+
+ vertex_four[1].ScreenX = x1 + dx;
+ vertex_four[1].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 *) _tnl_get_vertex( ctx, v1 ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, v1 ))[7];
+
+ vertex_four[2].ScreenX = x2 + dx;
+ vertex_four[2].ScreenY = y2 + dy;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, v2 ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, v2 ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, v2 ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, v2 ))[5];
+ vertex_four[0].TextureS = ((float *) _tnl_get_vertex( ctx, v2 ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, v2 ))[7];
+
+ vertex_four[3].ScreenX = x2 - dx;
+ vertex_four[3].ScreenY = y2 - dy;
+ vertex_four[0].ScreenZ = ((float *) _tnl_get_vertex( ctx, v2 ))[2];
+ vertex_four[0].EyeM = ((float *) _tnl_get_vertex( ctx, v2 ))[3];
+ vertex_four[0].Color = ((unsigned int *) _tnl_get_vertex( ctx, v2 ))[4];
+ vertex_four[0].Specular = ((unsigned int *) _tnl_get_vertex( ctx, v2 ))[5];
+ vertex_four[0].TextureS = ((float *) _tnl_get_vertex( ctx, v2 ))[6];
+ vertex_four[0].TextureT = ((float *) _tnl_get_vertex( ctx, v2 ))[7];
+
+
+
+
+#endif
+ BEGIN_PRIMITIVE(4);
+ OUT_VERTEX(v1);
+ OUT_VERTEX(v1);
+ OUT_VERTEX(v2);
+ OUT_VERTEX(v2);
+ END_PRIMITIVE(0x320210);
}
static void
--
Download Intel® 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-
[Mesa3d-dev] [PATCH] st/vega: Fix OpenVG demo segfaults.
From: Chia-I Wu When the paint is color, paint_bind_samplers binds a dummy sampler without a texture. It causes demos requiring a sampler (those use a mask or an image) to crash. --- src/gallium/state_trackers/vega/paint.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/src/gallium/state_trackers/vega/paint.c b/src/gallium/state_trackers/vega/paint.c index caf0c14..cdb87d3 100644 --- a/src/gallium/state_trackers/vega/paint.c +++ b/src/gallium/state_trackers/vega/paint.c @@ -639,9 +639,6 @@ VGint paint_bind_samplers(struct vg_paint *paint, struct pipe_sampler_state **sa } break; default: - samplers[0] = &paint->pattern.sampler; /* dummy */ - textures[0] = 0; - return 0; break; } return 0; -- 1.7.0 -- Download Intel® 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] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
On 03.03.2010 20:23, Luca Barbieri wrote: >> And never will... It does not export PIPE_CAP_GLSL, and does not have >> the shader opcodes to ever do so. > > Any Gallium driver should be able to support the GLSL subset without > control flow. > > And if we had a proper optimization infrastructure capable of inlining > functions, converting conditionals to multiplications and unrolling > loops (e.g. look at what the nVidia Cg compiler does), then > essentially all GLSL could be supported on any driver, with only > limitations on the maximum number of loop iterations. > > Isn't it worth supporting that? > > BTW, proprietary drivers do this: for instance nVidia supports GLSL on > nv30, which can't do control flow in fragment shaders and doesn't > support SM3. I think the i915 is a lot closer to r300 in that regard (which is quite a bit more limited than nv30), and it's true that ATI also supported glsl on that. As far as I know though it was quite easy to bump into shaders which wouldn't compile. There's only so much you can do if you have 4 blocks of (max) 16 instructions to run without any control flow if you need to unroll loops, not to mention lacking instructions for derivatives, or the fact things like sin/cos will take quite a few instructions... nv30, while processing fragment shaders slowly, had a LOT higher instruction count, IIRC supported derivatives and predication and had no dependent texturing limit. So that makes it a lot better suited for glsl hacks. So, I'm not sure it really makes a whole lot of sense to support glsl on i915. It'll really only ever work for very simple things (granted there are apps out there which indeed will only use glsl shaders which are known to compile fine on r300...) Roland -- Download Intel® 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] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
On Wed, 2010-03-03 at 06:58 -0800, Luca Barbieri wrote: > BTW, i915 is also limited to 0-7 generic indices, and thus doesn't > work with GLSL at all right now. > > This should be relatively easy to fix since it should be enough to > store the generic indices in the "texCoords" arrays, and then pass > them to draw_find_shader_output. Luca, If you want to go ahead and send a patch, I don't have a problem with it. Like you say, it should be an easy change. Keith -- Download Intel® 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] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
On Wed, 2010-03-03 at 11:23 -0800, Luca Barbieri wrote: > > And never will... It does not export PIPE_CAP_GLSL, and does not have > > the shader opcodes to ever do so. > > Any Gallium driver should be able to support the GLSL subset without > control flow. > > And if we had a proper optimization infrastructure capable of inlining > functions, converting conditionals to multiplications and unrolling > loops (e.g. look at what the nVidia Cg compiler does), then > essentially all GLSL could be supported on any driver, with only > limitations on the maximum number of loop iterations. > > Isn't it worth supporting that? > > BTW, proprietary drivers do this: for instance nVidia supports GLSL on > nv30, which can't do control flow in fragment shaders and doesn't > support SM3. OK, maybe never is too strong... But it's certainly a long way off... Keith -- Download Intel® 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] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
> And never will... It does not export PIPE_CAP_GLSL, and does not have > the shader opcodes to ever do so. Any Gallium driver should be able to support the GLSL subset without control flow. And if we had a proper optimization infrastructure capable of inlining functions, converting conditionals to multiplications and unrolling loops (e.g. look at what the nVidia Cg compiler does), then essentially all GLSL could be supported on any driver, with only limitations on the maximum number of loop iterations. Isn't it worth supporting that? BTW, proprietary drivers do this: for instance nVidia supports GLSL on nv30, which can't do control flow in fragment shaders and doesn't support SM3. -- Download Intel® 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] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
On Wed, 2010-03-03 at 06:58 -0800, Luca Barbieri wrote: > BTW, i915 is also limited to 0-7 generic indices, and thus doesn't > work with GLSL at all right now. And never will... It does not export PIPE_CAP_GLSL, and does not have the shader opcodes to ever do so. Keith -- Download Intel® 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] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
Florian Mickler wrote: > On Tue, 2 Mar 2010 11:50:05 -0800 > Jesse Barnes wrote: > >> So the server is hanging when the client tries to get buffers? Can you >> see what it's doing at the time? >> > > i'll try tomorrow... > > meanwhile, i watched a film and did some other things and now glxgears > doesn't start anymore: > > d...@schatten ~ $glxgears > Mesa: Mesa 7.8-devel DEBUG build Mar 2 2010 19:57:41 > Mesa warning: couldn't open libtxc_dxtn.so, software DXTn > compression/decompression unavailable > Mesa: Initializing x86-64 optimizations > Running synchronized to the vertical refresh. The framerate should be > approximately 1/8504368 the monitor refresh rate. > X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) > Major opcode of failed request: 133 (DRI2) > Minor opcode of failed request: 8 (DRI2SwapBuffers ) > Resource id in failed request: 0x1c2 > Serial number of failed request: 32 > Current serial number in output stream: 32 > > > does this 1/[bignumber] look alright? maybe that is the culprit... > waiting some 10^6 time ... i think the monitor refresh rate is > something about 60 hz? not over some khz? which means that 1khz/8504368 > is something about 1/8500 hz which amounts to about 140 secs? (it is > late and i may have switched nominater and denominator a bit too > often... but if i don't have crossed anything, than that could > cause some hang... don't it?) FWIW, my glxgears says: The framerate should beapproximately 1/1835103081 the monitor refresh rate. It then runs fine. I'm on radeon r200, but since my update yesterday (git master stack using gentoo overlay) I also have OpenGL problems, most notably, KWin 4.4's compositing doesn't work any more. Probably, this isn't just intel then. My old X did work fine, dating from when the DRI2 Swapbuffers lifetime bugfix hit master (711e26466ae04ae93ff4c48d377d83d68a6320e9). If it helps, I can provide anything that doesn't take me a whole day to gather. > > > cheers, > Flo > > p.s.: my software stack is git master of libdrm, mesa > and xf86-video-intel as well as xserver-master + krh's pull request, so > that it looks light that: > 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its > buffers become invalid. > 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the > DRI2InvalidateBuffers event. > 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on > DRI2GetBuffers if they're just being reused. > 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the > intel DDX. > 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. > de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled > compat_output > fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for > det_monrec_parameter sync_source > 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in > DRI2SwapEvent > 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith' > > > ___ > xorg-devel mailing list > xorg-de...@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-devel > -- Download Intel® 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] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
On Wed, 03 Mar 2010 12:31:24 +0100 Francisco Jerez wrote: > Florian Mickler writes: > > > [...] > > p.s.: my software stack is git master of libdrm, mesa > > and xf86-video-intel as well as xserver-master + krh's pull request, so > > that it looks light that: > > 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when > > its buffers become invalid. > > 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the > > DRI2InvalidateBuffers event. > > 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front > > on DRI2GetBuffers if they're just being reused. > > 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from > > the intel DDX. > > 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. > > de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled > > compat_output > > fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for > > det_monrec_parameter sync_source > > 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable > > in DRI2SwapEvent > > 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch > > 'whot/for-keith' > > Is it a side effect of this patch series? Could you try without? Ah yes. Of course. Should have checked that before... Anyway, I just did, and with current xserver-master it is hanging nontheless... , Flo -- Download Intel® 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: gallium-format-cleanup branch (was Gallium format swizzles)
On 03.03.2010 14:07, José Fonseca wrote: > On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote: >>> PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. >>> PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be >>> unnecessary. So it doesn't make sense to rename. >> How about D3DFMT_X8B8G8R8? That should map to >> PIPE_FORMAT_R8G8B8X8_UNORM. > > Yes, you're right. > >> BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5, >> D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, >> D3DFMT_D24X4S4, D3DFMT_CxV8U8 and perhaps others I did not notice. > > D3DFMT_L6V5U5 is there (PIPE_FORMAT_R5SG5SB6U_NORM). The others are > indeed missing. Neither of the mentioned formats is required for D3D9 > conformance, but we could add them to gallium. > > D3DFMT_A1 is special: it has less than 1 byte per pixel. Probably the > best way to support it would be to treat it as a 8x1 macro pixel, > 8bits, similarly to compressed formats. > > D3DFMT_CxV8U8 too as special semantics. And not only are those formats optional, some would be completely pointless in gallium (D15S1, D24X4S4). There's simply no modern hardware which supports 1 bit stencil (I think pretty much the only chip supporting that was savage3d), nor 4 bit stencil (can't remember off-hand any chip supporting that, maybe some of the then professional chips did). The others sound a bit more plausible and hardware may support them, but I'm not sure they are really missed (A4L4, X4R4G4B4, X1R5G5B5). As José said, CxV8U8 isn't really a format only, and we'll need to add 1-bit format for DX10. Roland -- Download Intel® 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] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
BTW, i915 is also limited to 0-7 generic indices, and thus doesn't work with GLSL at all right now. This should be relatively easy to fix since it should be enough to store the generic indices in the "texCoords" arrays, and then pass them to draw_find_shader_output. -- Download Intel® 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] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
On Tue, Mar 02, 2010 at 09:43:51PM +0100, Luca Barbieri wrote: > - Not sure about i965 On i965 interpolators are not a dedicated piece of hardware, they're programs like the other shaders. So the problem is entirely different, and more at the level of space allocation in the thread-to-thread communication packets in the pipeline vs. register allocation in the shaders (there's a semi-direct mapping). OG. -- Download Intel® 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] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
On Wed, 2010-03-03 at 13:31 +0100, Simon Thum wrote: > > It then runs fine. I'm on radeon r200, but since my update yesterday > (git master stack using gentoo overlay) I also have OpenGL problems, > most notably, KWin 4.4's compositing doesn't work any more. Probably, > this isn't just intel then. If your mesa Git checkout doesn't have commit 5f40a7aed12500fd6792e2453f49c3b5c54d yet, try updating again. Anyway, I think it's unlikely your problem is the same. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel® 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: gallium-format-cleanup branch (was Gallium format swizzles)
On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote: > > PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. > > PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be > > unnecessary. So it doesn't make sense to rename. > > How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM. Yes, you're right. > BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5, > D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, D3DFMT_D24X4S4, > D3DFMT_CxV8U8 and perhaps others I did not notice. D3DFMT_L6V5U5 is there (PIPE_FORMAT_R5SG5SB6U_NORM). The others are indeed missing. Neither of the mentioned formats is required for D3D9 conformance, but we could add them to gallium. D3DFMT_A1 is special: it has less than 1 byte per pixel. Probably the best way to support it would be to treat it as a 8x1 macro pixel, 8bits, similarly to compressed formats. D3DFMT_CxV8U8 too as special semantics. Jose -- Download Intel® 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: gallium-format-cleanup branch (was Gallium format swizzles)
> PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM > doesn't exist hence it appears to be unnecessary. So it doesn't make sense to > rename. How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM. BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5, D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, D3DFMT_D24X4S4, D3DFMT_CxV8U8 and perhaps others I did not notice. -- Download Intel® 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] [Intel-gfx] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
On Tue, 2 Mar 2010 13:59:00 -0800
Jesse Barnes wrote:
> commit 529bf185fbcb9f7705b315a5106054ee25c1c77f
> Author: Eric Anholt
> Date: Wed Feb 24 17:54:13 2010 -0800
>
> In frame event handling, track drawable id instead of drawable
> pointer.
>
> in your xf86-video-intel tree?
>
yes. before that, glxgears wouldn't ever start ... the error goes away if i
restart the xserver...
Am Dienstag, den 02.03.2010, 22:48 +0100 schrieb Florian Mickler:
> On Tue, 2 Mar 2010 11:50:05 -0800
> Jesse Barnes wrote:
>
> > So the server is hanging when the client tries to get buffers? Can you
> > see what it's doing at the time?
> >
>
> i'll try tomorrow...
btw, no. it is glxgears which is hanging. everything else works as it
should.
and it is hanging on this _XReply (@428) here:
@line 428 in mesa/src/glx/dri2.c:
416XextCheckExtension(dpy, info, dri2ExtensionName, False);
417
418LockDisplay(dpy);
419GetReqExtra(DRI2GetBuffers, count * (4 * 2), req);
420req->reqType = info->codes->major_opcode;
421req->dri2ReqType = X_DRI2GetBuffersWithFormat;
422req->drawable = drawable;
423req->count = count;
424p = (CARD32 *) & req[1];
425for (i = 0; i < (count * 2); i++)
426 p[i] = attachments[i];
427
428if (!_XReply(dpy, (xReply *) & rep, 0, xFalse)) {
429 UnlockDisplay(dpy);
430 SyncHandle();
431 return NULL;
432}
433
434*width = rep.width;
435*height = rep.height;
it's not looping... i verified with strace that glxgears is blocking on
that poll() here...
I tried to follow the program flow up into that.. but besides me
thinking that this _XReply is surfacing in the xserver's dispatch.c
i'm not really advancing here ;) where does this request get handled?
when does _XReply return?
cheers,
Flo
p.s.: if the screen is idle and get's turned off, glxgears is running
fine... (started via ssh... i see the framerate reporting...)
p.p.s.: the whole backtrace when glxgears is hanging:
(gdb) bt full
#0 0x7f3aef5ea10f in poll () from /lib/libc.so.6
No symbol table info available.
#1 0x7f3aee19fa32 in _xcb_conn_wait () from /usr/lib/libxcb.so.1
No symbol table info available.
#2 0x7f3aee1a15e1 in xcb_wait_for_reply ()
from /usr/lib/libxcb.so.1
No symbol table info available.
#3 0x7f3aef2460be in _XReply () from /usr/lib/libX11.so.6
No symbol table info available.
#4 0x7f3aefb44f76 in DRI2GetBuffersWithFormat (dpy=0x234c010,
drawable=, width=0x235f3b4, height=0x235f3b8,
attachments=0x7fffc5ac6450, count=2, outCount=0x7fffc5ac648c) at
dri2.c:428
info = 0x2357960
rep = {type = 112 'p', pad1 = 100 'd', sequenceNumber = 50604,
length = 32767, width = 3984539715, height = 32570, count =
0,
pad2 = 0, pad3 = 37116448, pad4 = 0}
buffers =
repBuffer = {attachment = 41009200, name = 0, pitch =
3985030468,
cpp = 32570, flags = 2097152}
i =
#5 0x7f3aefb43ca8 in dri2GetBuffersWithFormat (
driDrawable=, width=0x235f3b4,
height=0x, attachments=0x234d6d8, count=5277,
out_count=0x7fffc5ac648c, loaderPrivate=0x235f2c0) at dri2_glx.c:435
---Type to continue, or q to quit---
pdraw =
buffers =
#6 0x7f3aed6de927 in intel_update_renderbuffers (
context=, drawable=0x235f380) at
intel_context.c:252
rb =
region =
depth_region =
intel = 0x2365a20
front_rb =
back_rb = 0x3
depth_rb = 0x26b9340
stencil_rb = 0x26b9340
buffers =
screen = 0x235cf20
i = 3
count =
attachments = {1, 32, 9, 32, 13, 0, 0, 0, 655360, 0}
region_name =
__func__ = "intel_update_renderbuffers"
#7 0x7f3aed6decef in intel_prepare_render (intel=0x2365a20)
at intel_context.c:395
driContext = 0x2361d70
drawable = 0x235f380
---Type to continue, or q to quit---
#8 0x7f3aed70d3ca in brw_try_draw_prims (ctx=0x2365a20,
arrays=0x23b54a8,
prim=0x7fffc5ac65a0, nr_prims=1, ib=0x0,
index_bounds_valid=, min_index=0, max_index=3)
at brw_draw.c:340
retval =
warn =
first_time =
i =
intel = 0x7fffc5ac6200
__FUNCTION__ = "brw_try_draw_prims"
warned = 0 '\000'
#9 brw_draw_prims (ctx=0x2365a20, arrays=0x23b54a8,
prim=0x7fffc5ac65a0,
nr_prims=1, ib=0x0, index_bounds_valid=,
min_index=0,
max_index=3) at brw_draw.c:441
No locals.
#10 0x7f3aed7c91bf in vbo_exec_DrawArrays (mode=6, start=0, count=4)
at vbo/vbo_exec_array.c:524
ctx = 0x2365a20
prim = {{mode = 6, indexed = 0, begin = 1, end = 1, weak = 0,
pad = 0,
start = 0, count = 4, basevertex = 0}}
__FUNCTION__ = "vbo_exec_DrawArrays"
#11 0x7f3aed847910 in _mesa_meta_Clear (ctx=0x2365a20, buffers=0)
at drivers/common/meta.c:1461
---Type to continue, or q to quit---
clear = 0x26b47e4
verts = {
Re: [Mesa3d-dev] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)
Florian Mickler writes: > [...] > p.s.: my software stack is git master of libdrm, mesa > and xf86-video-intel as well as xserver-master + krh's pull request, so > that it looks light that: > 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its > buffers become invalid. > 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the > DRI2InvalidateBuffers event. > 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on > DRI2GetBuffers if they're just being reused. > 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the > intel DDX. > 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook. > de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled > compat_output > fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for > det_monrec_parameter sync_source > 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in > DRI2SwapEvent > 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith' Is it a side effect of this patch series? Could you try without? pgpND6QtaP7UL.pgp Description: PGP signature -- Download Intel® 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] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?
On Tue, 2010-03-02 at 12:43 -0800, Luca Barbieri wrote: > The difference between an easier and harder life for (some) drivers is > whether the limit is tied to hardware interpolators or not. > Once we decide to not tie it, whether the limit is 128 or 256 is of > course quite inconsequential. > Allowing arbitrary 32-bit values would however require use of binary > search or an hash table. > > I think you or someone else from the Mesa team should decide how to > proceed, and most drivers would need to be fixed. > > As I understand, the constraints are the following: > > Hardware with no capabilities. > - nv30 does not support any mapping. However, we already need to patch > fragment programs to insert constants, so we can patch input register > numbers as well. The current driver only supports 0-7 generic indices, > but I already implemented support for 0-255 indices with in-driver > linkage and patching. Note that nv30 lacks control flow in fragment > programs. > - nv40 is like nv30, but supports fp control flow, and may have some > configurable mapping support, with unknown behavior > > Hardware with capabilities that must be configured for each fp/vp pair. > - nv40 might have this but the nVidia OpenGL driver does not use them > - nv50 has configurable vp->gp and gp->fp mappings with 64 entries. > The current driver seems to support arbitrary 0-2^32 indices. > - r300 appears to have a configurable vp->fp mapping. The current > driver only supports 0-15 generic indices, but redefining > ATTR_GENERIC_COUNT could be enough to have it support larger numbers. > > Hardware with automatic linkage when semantics match: > - VMWare svga appears to support 14 * 16 semantics, but the current > driver only supports 0-15 generic indices. This could be fixed by > mapping GENERIC into all non-special SM3 semantics. > > Hardware that can do both configurable mappings and automatic linkage: > - r600 supports linkage in hardware between matching apparently > byte-sized semantic ids > > Other hardware; > - i915 has no hardware vertex shading > - Not sure about i965 > > Software: > 1. SM3 wants to use 14 * 16 indices overall. This is apparently only > supported by the VMware closed source state tracker. > 2. SM2 and non-GLSL OpenGL just want to use as many indices as the > hardware interpolator count > 3. Current GLSL currently wants to use at most about 10 indices more > than the hardware interpolator count. This can be fixed since we see > both the fragment and vertex shaders during linkage (the patch I sent > did that) > 4. GLSL with EXT_separate_shader_objects does not add requirements > because only gl_TexCoord and other builtin varyings are supported. > User-defined varyings are not supported > 5. An hypotetical version of EXT_separate_shader_objects extended to > support user-defining varyings would either want arbitrary 32-bit > generic indices (by interning strings to generate the indices) or the > ability to specify a custom mapping between shader indices > 6. An hypotetical "no-op" implementation of the GLSL linker would have > the same requirement > > Also note that non-GENERIC indices have peculiar properties. > > For COLOR and BCOLOR: > 1. SM3 and OpenGL with glColorClamp appropriately set wants it to > _not_ be clamped to [0, 1] > 2. SM2 and normal OpenGL apparently want it to be clamped to [0, 1] > (sometimes for fixed point targets only) and may also allow using > U8_UNORM precision for it instead of FP32 > 3. OpenGL allows to enable two-sided lighting, in which case COLOR in > the fragment shader is automagically set to BCOLOR for back faces > 4. Older hardware (e.g. nv30) tends to support BCOLOR but not FACING. > Some hardware (e.g. nv40) supports both FACING and BCOLOR in hardware. > The latest hardware probably supports FACING only. > > Any API that requires special semantics for COLOR and BCOLOR (i.e. > non-SM3) seems to only want 0-1 indices. > > Note that SM3 does *not* include BCOLOR, so basically the limits for > generic indices would need to be conditional on BCOLOR being present > or not (e.g. if it is present, we must reserve two semantic slots in > svga for it). > > POSITION0 is obviously special. > PSIZE0 is also special for points. > > FOG0 seems right now to just be a GENERIC with a single component. > Gallium could be extended to support fixed function fog, which most > DX9 hardware supports (nv30/nv40 and r300). This is mostly orthogonal > to the semantic issue. > > TGSI_SEMANTIC_NORMAL is essentially unused and should probably be removed > > The options are the ones you outlined, plus: > (e) Allow arbitrary 32-bit indices. This requires slightly more > complicated data structures in some cases, and will require svga and > r600 to fallback to software linkage if numbers are too high. > (f) Limit semantic indices to hardware interpolators _and_ introduce > an interface to let the user specify an > > Personally I think the simplest idea for now could be to have all > drivers s
Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)
Consistency between different formats is not always a good metric here, as there are all sort of historical reasons which make the used set of formats out of all possible quite asymmetric. PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename. But I think you stumbled on something: PIPE_FORMAT_R8G8B8X8_SNORM might not be needed. It's not used anywhere, nor can I find mention of such format in D3D9/10. I'll remove it if nobody opposes. Jose From: Luca Barbieri [luca.barbi...@gmail.com] Sent: Tuesday, March 02, 2010 22:16 To: Jose Fonseca Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles) Shouldn't PIPE_FORMAT_X8B8G8R8_UNORM= 68, be instead R8G8B8X8_UNORM, which is currently missing, for consistency with: PIPE_FORMAT_R8G8B8X8_SNORM= 81, with X8B8G8R8_UNORM perhaps put at the end next to PIPE_FORMAT_A8B8G8R8_UNORM? -- Download Intel® 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
