[Mesa-dev] [PATCH 1/4] gallium: add fragment shader property for color writes to all buffers.
For GL fragColor semantics we need to tell the pipe drivers that the fragment shader color result is to be replicated to all bound color buffers, this adds the basic TGSI + documentation. Signed-off-by: Dave Airlie airl...@redhat.com --- src/gallium/auxiliary/tgsi/tgsi_text.c |3 +++ src/gallium/auxiliary/tgsi/tgsi_ureg.c | 16 +++- src/gallium/auxiliary/tgsi/tgsi_ureg.h |4 src/gallium/docs/source/tgsi.rst |5 + src/gallium/include/pipe/p_shader_tokens.h |3 ++- 5 files changed, 29 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 9a38c37..d868b5b 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1265,6 +1265,7 @@ static const char *property_names[] = GS_MAX_OUTPUT_VERTICES, FS_COORD_ORIGIN, FS_COORD_PIXEL_CENTER + FS_COLOR0_WRITE_ALL_CBUFS }; static const char *primitive_names[] = @@ -1398,6 +1399,8 @@ static boolean parse_property( struct translate_ctx *ctx ) return FALSE; } break; + case TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS: + break; default: if (!parse_uint(ctx-cur, values[0] )) { report_error( ctx, Expected unsigned integer as property! ); diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c b/src/gallium/auxiliary/tgsi/tgsi_ureg.c index 7d13a17..02de12d 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c @@ -148,6 +148,7 @@ struct ureg_program unsigned property_gs_max_vertices; unsigned char property_fs_coord_origin; /* = TGSI_FS_COORD_ORIGIN_* */ unsigned char property_fs_coord_pixel_center; /* = TGSI_FS_COORD_PIXEL_CENTER_* */ + unsigned char property_fs_color0_writes_all_cbufs; /* = TGSI_FS_COLOR0_WRITES_ALL_CBUFS * */ unsigned nr_addrs; unsigned nr_preds; @@ -284,7 +285,12 @@ ureg_property_fs_coord_pixel_center(struct ureg_program *ureg, ureg-property_fs_coord_pixel_center = fs_coord_pixel_center; } - +void +ureg_property_fs_color0_writes_all_cbufs(struct ureg_program *ureg, +unsigned fs_color0_writes_all_cbufs) +{ + ureg-property_fs_color0_writes_all_cbufs = fs_color0_writes_all_cbufs; +} struct ureg_src ureg_DECL_fs_input_cyl_centroid(struct ureg_program *ureg, @@ -1278,6 +1284,14 @@ static void emit_decls( struct ureg_program *ureg ) ureg-property_fs_coord_pixel_center); } + if (ureg-property_fs_color0_writes_all_cbufs) { + assert(ureg-processor == TGSI_PROCESSOR_FRAGMENT); + + emit_property(ureg, +TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS, +ureg-property_fs_color0_writes_all_cbufs); + } + if (ureg-processor == TGSI_PROCESSOR_VERTEX) { for (i = 0; i UREG_MAX_INPUT; i++) { if (ureg-vs_inputs[i/32] (1 (i%32))) { diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h b/src/gallium/auxiliary/tgsi/tgsi_ureg.h index acc4632..807128a 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h @@ -153,6 +153,10 @@ void ureg_property_fs_coord_pixel_center(struct ureg_program *ureg, unsigned fs_coord_pixel_center); +void +ureg_property_fs_color0_writes_all_cbufs(struct ureg_program *ureg, +unsigned fs_color0_writes_all_cbufs); + /*** * Build shader declarations: */ diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index 7eb6bd0..d986e66 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -1516,6 +1516,11 @@ GL_ARB_fragment_coord_conventions extension. DirectX 9 uses INTEGER. DirectX 10 uses HALF_INTEGER. +FS_COLOR0_WRITES_ALL_CBUFS + +Specifies that writes to the fragment shader color 0 are replicated to all +bound cbufs. This facilitates OpenGL's fragColor output vs fragData[0] where +fragData is directed to a single color buffer, but fragColor is broadcast. Texture Sampling and Texture Formats diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h index ba433b2..0a9e141 100644 --- a/src/gallium/include/pipe/p_shader_tokens.h +++ b/src/gallium/include/pipe/p_shader_tokens.h @@ -177,7 +177,8 @@ union tgsi_immediate_data #define TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES 2 #define TGSI_PROPERTY_FS_COORD_ORIGIN3 #define TGSI_PROPERTY_FS_COORD_PIXEL_CENTER 4 -#define TGSI_PROPERTY_COUNT 5 +#define TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS 5 +#define TGSI_PROPERTY_COUNT 6 struct tgsi_property { unsigned Type : 4; /** TGSI_TOKEN_TYPE_PROPERTY */ -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org
[Mesa-dev] [PATCH 2/4] softpipe: add support for color writes all color bufs property
--- src/gallium/drivers/softpipe/sp_quad_blend.c | 14 +++--- src/gallium/drivers/softpipe/sp_state.h|2 +- src/gallium/drivers/softpipe/sp_state_shader.c |2 ++ 3 files changed, 14 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c b/src/gallium/drivers/softpipe/sp_quad_blend.c index 6af1b2d..76cfc0b 100644 --- a/src/gallium/drivers/softpipe/sp_quad_blend.c +++ b/src/gallium/drivers/softpipe/sp_quad_blend.c @@ -35,6 +35,7 @@ #include util/u_memory.h #include util/u_format.h #include sp_context.h +#include sp_state.h #include sp_quad.h #include sp_tile_cache.h #include sp_quad_pipe.h @@ -794,6 +795,9 @@ blend_fallback(struct quad_stage *qs, struct softpipe_context *softpipe = qs-softpipe; const struct pipe_blend_state *blend = softpipe-blend; unsigned cbuf; + boolean write_all; + + write_all = softpipe-fs-color0_writes_all_cbufs; for (cbuf = 0; cbuf softpipe-framebuffer.nr_cbufs; cbuf++) { @@ -806,15 +810,19 @@ blend_fallback(struct quad_stage *qs, quads[0]-input.y0); boolean has_dst_alpha = util_format_has_alpha(softpipe-framebuffer.cbufs[cbuf]-format); - uint q, i, j; + uint q, i, j, qbuf; + + qbuf = write_all ? 0 : cbuf; for (q = 0; q nr; q++) { struct quad_header *quad = quads[q]; - float (*quadColor)[4] = quad-output.color[cbuf]; + float (*quadColor)[4]; const int itx = (quad-input.x0 (TILE_SIZE-1)); const int ity = (quad-input.y0 (TILE_SIZE-1)); - /* get/swizzle dest colors + quadColor = quad-output.color[qbuf]; + + /* get/swizzle dest colors */ for (j = 0; j QUAD_SIZE; j++) { int x = itx + (j 1); diff --git a/src/gallium/drivers/softpipe/sp_state.h b/src/gallium/drivers/softpipe/sp_state.h index 525bf23..bb19f8c 100644 --- a/src/gallium/drivers/softpipe/sp_state.h +++ b/src/gallium/drivers/softpipe/sp_state.h @@ -74,7 +74,7 @@ struct sp_fragment_shader { boolean origin_lower_left; /** fragment shader uses lower left position origin? */ boolean pixel_center_integer; /** fragment shader uses integer pixel center? */ - + boolean color0_writes_all_cbufs; /** fragment shader writes color0 to all bound cbufs */ void (*prepare)( const struct sp_fragment_shader *shader, struct tgsi_exec_machine *machine, struct tgsi_sampler **samplers); diff --git a/src/gallium/drivers/softpipe/sp_state_shader.c b/src/gallium/drivers/softpipe/sp_state_shader.c index 7fff338..66ddc56 100644 --- a/src/gallium/drivers/softpipe/sp_state_shader.c +++ b/src/gallium/drivers/softpipe/sp_state_shader.c @@ -78,6 +78,8 @@ softpipe_create_fs_state(struct pipe_context *pipe, state-origin_lower_left = state-info.properties[i].data[0]; else if (state-info.properties[i].name == TGSI_PROPERTY_FS_COORD_PIXEL_CENTER) state-pixel_center_integer = state-info.properties[i].data[0]; + else if (state-info.properties[i].name == TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS) +state-color0_writes_all_cbufs = state-info.properties[i].data[0]; } return state; -- 1.7.2.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] openGL ES with OSMesa
Hi all, Iam using mesa 7.8-gles version for my project. I need to use opengl es with osmesa driver for off screen rendering. I was able to build both using makefiles in associate folders. But i was not able to debug my application program. I am using gdb to debug. Am i doing anything wrong. Also i am doing it for powerpc platform without operating system support. How should i proceed. Is there any other rendering library which don't need OS support Firos ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add fragment shader property for color writes to all buffers.
Dave Airlie [2010-12-23 18:43]: --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1265,6 +1265,7 @@ static const char *property_names[] = GS_MAX_OUTPUT_VERTICES, FS_COORD_ORIGIN, FS_COORD_PIXEL_CENTER + FS_COLOR0_WRITE_ALL_CBUFS }; It looks like you forgot to add a comma to the second to last entry. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? pgplFrwU5O7gl.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30694] wincopy will crash on r600g when going to front buffer
https://bugs.freedesktop.org/show_bug.cgi?id=30694 --- Comment #5 from Kevin DeKorte kdeko...@yahoo.com 2010-12-23 07:32:59 PST --- Alex, are you sure this is core mesa issue as the code does not crash on my intel based machine. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30694] wincopy will crash on r600g when going to front buffer
https://bugs.freedesktop.org/show_bug.cgi?id=30694 --- Comment #6 from Alex Deucher ag...@yahoo.com 2010-12-23 07:36:16 PST --- (In reply to comment #5) Alex, are you sure this is core mesa issue as the code does not crash on my intel based machine. It looks like a gallium state tracker bug. The Intel drivers don't use gallium. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] gallium: add fragment shader property for color writes to all buffers.
Dave, This all looks good to me (modulo the glitch Tilman pointed out). Keith On Thu, 2010-12-23 at 00:43 -0800, Dave Airlie wrote: For GL fragColor semantics we need to tell the pipe drivers that the fragment shader color result is to be replicated to all bound color buffers, this adds the basic TGSI + documentation. Signed-off-by: Dave Airlie airl...@redhat.com --- src/gallium/auxiliary/tgsi/tgsi_text.c |3 +++ src/gallium/auxiliary/tgsi/tgsi_ureg.c | 16 +++- src/gallium/auxiliary/tgsi/tgsi_ureg.h |4 src/gallium/docs/source/tgsi.rst |5 + src/gallium/include/pipe/p_shader_tokens.h |3 ++- 5 files changed, 29 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 9a38c37..d868b5b 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@ -1265,6 +1265,7 @@ static const char *property_names[] = GS_MAX_OUTPUT_VERTICES, FS_COORD_ORIGIN, FS_COORD_PIXEL_CENTER + FS_COLOR0_WRITE_ALL_CBUFS }; static const char *primitive_names[] = @@ -1398,6 +1399,8 @@ static boolean parse_property( struct translate_ctx *ctx ) return FALSE; } break; + case TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS: + break; default: if (!parse_uint(ctx-cur, values[0] )) { report_error( ctx, Expected unsigned integer as property! ); diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c b/src/gallium/auxiliary/tgsi/tgsi_ureg.c index 7d13a17..02de12d 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c @@ -148,6 +148,7 @@ struct ureg_program unsigned property_gs_max_vertices; unsigned char property_fs_coord_origin; /* = TGSI_FS_COORD_ORIGIN_* */ unsigned char property_fs_coord_pixel_center; /* = TGSI_FS_COORD_PIXEL_CENTER_* */ + unsigned char property_fs_color0_writes_all_cbufs; /* = TGSI_FS_COLOR0_WRITES_ALL_CBUFS * */ unsigned nr_addrs; unsigned nr_preds; @@ -284,7 +285,12 @@ ureg_property_fs_coord_pixel_center(struct ureg_program *ureg, ureg-property_fs_coord_pixel_center = fs_coord_pixel_center; } - +void +ureg_property_fs_color0_writes_all_cbufs(struct ureg_program *ureg, +unsigned fs_color0_writes_all_cbufs) +{ + ureg-property_fs_color0_writes_all_cbufs = fs_color0_writes_all_cbufs; +} struct ureg_src ureg_DECL_fs_input_cyl_centroid(struct ureg_program *ureg, @@ -1278,6 +1284,14 @@ static void emit_decls( struct ureg_program *ureg ) ureg-property_fs_coord_pixel_center); } + if (ureg-property_fs_color0_writes_all_cbufs) { + assert(ureg-processor == TGSI_PROCESSOR_FRAGMENT); + + emit_property(ureg, +TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS, +ureg-property_fs_color0_writes_all_cbufs); + } + if (ureg-processor == TGSI_PROCESSOR_VERTEX) { for (i = 0; i UREG_MAX_INPUT; i++) { if (ureg-vs_inputs[i/32] (1 (i%32))) { diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.h b/src/gallium/auxiliary/tgsi/tgsi_ureg.h index acc4632..807128a 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.h +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.h @@ -153,6 +153,10 @@ void ureg_property_fs_coord_pixel_center(struct ureg_program *ureg, unsigned fs_coord_pixel_center); +void +ureg_property_fs_color0_writes_all_cbufs(struct ureg_program *ureg, +unsigned fs_color0_writes_all_cbufs); + /*** * Build shader declarations: */ diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index 7eb6bd0..d986e66 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -1516,6 +1516,11 @@ GL_ARB_fragment_coord_conventions extension. DirectX 9 uses INTEGER. DirectX 10 uses HALF_INTEGER. +FS_COLOR0_WRITES_ALL_CBUFS + +Specifies that writes to the fragment shader color 0 are replicated to all +bound cbufs. This facilitates OpenGL's fragColor output vs fragData[0] where +fragData is directed to a single color buffer, but fragColor is broadcast. Texture Sampling and Texture Formats diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h index ba433b2..0a9e141 100644 --- a/src/gallium/include/pipe/p_shader_tokens.h +++ b/src/gallium/include/pipe/p_shader_tokens.h @@ -177,7 +177,8 @@ union tgsi_immediate_data #define TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES 2 #define TGSI_PROPERTY_FS_COORD_ORIGIN3 #define TGSI_PROPERTY_FS_COORD_PIXEL_CENTER 4 -#define TGSI_PROPERTY_COUNT 5 +#define TGSI_PROPERTY_FS_COLOR0_WRITES_ALL_CBUFS 5 +#define
[Mesa-dev] [Bug 30694] wincopy will crash on Gallium drivers when going to front buffer
https://bugs.freedesktop.org/show_bug.cgi?id=30694 Vinson Lee v...@vmware.com changed: What|Removed |Added Summary|wincopy will crash on r600g |wincopy will crash on |when going to front buffer |Gallium drivers when going ||to front buffer Severity|normal |critical --- Comment #7 from Vinson Lee v...@vmware.com 2010-12-23 09:28:41 PST --- mesa: aedbf05d31c1a8d7d3c2742524abf2db2422b2fe (master) swrast - ok softpipe - crash llvmpipe - crash -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TLS autodetection support in the X server
Dan Nicholson dbn.li...@gmail.com writes: On Wed, Dec 22, 2010 at 3:18 PM, tom fogal tfo...@sci.utah.edu wrote: Alan Coopersmith alan.coopersm...@oracle.com writes: On 12/22/10 02:30 PM, tom fogal wrote: We generally don't copy macros from the autoconf-archive into xorg-macros, [. . .] Is there any reason not to do that here? Why should we add multiple levels of indirection to keep in sync? We shouldn't, I was just ignorant. I'll respin. ... and I have. Attached. Both against xorg/xserver this time. Tom, I thought the issue here was that mesa glx would get built with TLS, but xserver glx wouldn't. It seems like what you'd really want to do is get this macro into mesa so it could autodetect TLS capabilities and then use some value from mesa pkgconfig to detect how mesa glx was built. I tried that, and others pointed out that a TLS-enabled X server can load any kind of driver, so it's better to aggressively enable TLS there, and then it basically doesn't matter what we do in Mesa. The patch I sent to do exactly what you say was shot down: http://lists.freedesktop.org/archives/mesa-dev/2010-December/004397.html Julien had expressed interest in getting the X server to do this, though. What do you think? I don't have an opinion, really ;) My lone goal at present is to get Mesa to auto-enable TLS. I'm just trying to do whatever's asked so I can get that in... but it seems there is some disagreement within the community as to the best approach. I think it's basically you and Eric A. advocating contradictory approaches; if you two could work out what you'd like to see, I'll implement it... Thanks, -tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] i915: policy for enabling texture tiling
Hello everyone, I recently found a problem with the i915 driver. An OpenGL application using lots of small textures gets OOM-killed after about 1000 textures, depending on the amount of system memory. The ticket is here: https://bugs.freedesktop.org/show_bug.cgi?id=32579 Even though I have not confirmed it yet, Chris Wilson indicates that linux-next has a patch that makes the problem disappear. All current systems (Ubuntu 10.10 and anything including a recent Mesa) have the problem. The i915 driver enables texture tiling by default, which the kernel handles by making 1024x1024 allocations even for small textures. As it stands, any combination of Linux 2.6.38 and Mesa 7.9 will be doing crazy memory allocations. Given that the currently released versions of the Linux kernel behave in a manner that is not reasonable, I believe a fix of some sort should be taken to users. One possibility is to disable texture tiling by default on i915 in Mesa 7.9, by reverting http://cgit.freedesktop.org/mesa/mesa/commit/?id=8e7a8d65931a650534e0f5c4e0d8118cd6f7636e It will be slower, but at least it won't get the application OOM-killed. Another would be to backport the modifications of the DRM that enable tiled textures to eat up less than 1MB of system memory, from linux-next to the stable 2.6 branches (and upcoming 2.6.37), but according to Chris this is difficult to do because the modifications are non trivial. A third option seems to be the use of I915_PARAM_HAS_RELAXED_FENCING that would allow a smarter behavior, but I am not sure I would be able to write the patch myself. What are your thoughts on the matter? Thanks -- Greetings, A. Huillet ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32618] New: d3d1x state tracker misses oaidl.idl file (maybe others?)
https://bugs.freedesktop.org/show_bug.cgi?id=32618 Summary: d3d1x state tracker misses oaidl.idl file (maybe others?) Product: Mesa Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: papo...@hotmail.com Building mesa with the D3D1x state tracker produces the following error: /usr/bin/makedepend -fdepend -I/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include -I/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed -I. -I../../../../../src/gallium/include -I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers 2 /dev/null make[5]: Leaving directory `/home/dema1701/projects/mesa/src/gallium/state_trackers/d3d1x/d3dapi' make[5]: Entering directory `/home/dema1701/projects/mesa/src/gallium/state_trackers/d3d1x/d3dapi' widl -I../gd3dapi -I../d3dapi -I../w32api -U /dev/null -H d3d10_1.h d3d10_1.idl widl -I../gd3dapi -I../d3dapi -I../w32api -U /dev/null -H d3d10.h d3d10.idl widl -I../gd3dapi -I../d3dapi -I../w32api -U /dev/null -H d3d10shader.h d3d10shader.idl widl -I../gd3dapi -I../d3dapi -I../w32api -U /dev/null -H d3d11.h d3d11.idl widl -I../gd3dapi -I../d3dapi -I../w32api -U /dev/null -H d3d11shader.h d3d11shader.idl widl -I../gd3dapi -I../d3dapi -I../w32api -U /dev/null -H d3dcommon.h d3dcommon.idl widl -I../gd3dapi -I../d3dapi -I../w32api -U /dev/null -H dxgiformat.h dxgiformat.idl widl -I../gd3dapi -I../d3dapi -I../w32api -U /dev/null -H dxgi.h dxgi.idl d3d10_1.idl:27: error: Unable to open include file oaidl.idl make[5]: *** [d3d10_1.h] Error 1 make[5]: *** Waiting for unfinished jobs d3d10.idl:24: error: Unable to open include file oaidl.idl make[5]: *** [d3d10.h] Error 1 d3dcommon.idl:27: error: Unable to open include file oaidl.idl make[5]: *** [d3dcommon.h] Error 1 d3dcommon.idl:27: error: Unable to open include file oaidl.idl make[5]: *** [d3d11shader.h] Error 1 d3d11.idl:27: error: Unable to open include file oaidl.idl make[5]: *** [d3d11.h] Error 1 d3d10.idl:24: error: Unable to open include file oaidl.idl make[5]: *** [d3d10shader.h] Error 1 dxgitype.idl:21: error: Unable to open include file oaidl.idl Tested on two different computers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Floating-point formats from GL_ARB_texture_rg implemented
On Wed, 22 Dec 2010 22:12:18 +0100, Marek Olšák mar...@gmail.com wrote: Hi, in case anyone is interested, I have implemented the floating-point formats from GL_ARB_texture_rg, namely R16F, RG16F, R32F, RG32F, for both core Mesa and st/mesa. The commits are here: http://cgit.freedesktop.org/~mareko/mesa/commit/?h=floating2id=a68e9890451140f493d09f1dd2dd8dfc77ed29de http://cgit.freedesktop.org/~mareko/mesa/commit/?h=floating2id=7216311b553bcc9331492d4d03a25d36348567d5 FWIW there is also experimental support of floating-point rendering for r300g in that 'floating2' branch, and trivial support of GL_ATI_texture_float. It's based on Luca's 'floating' branch. BTW, is there any progress on the floating-point patent matter? We should probably also take into account non-US Linux distributions like some variants of Mint, because they don't have to care about software patents and they already freely distribute patented stuff like some multimedia codecs. I think they would use whatever Mesa has to offer, patented or not. We should just put enabling patented extensions under --enable configure flags and call it good. pgp9l2X83QV8U.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH Resend] mesa: Optionally build a dricore support library.
On Tue, 21 Dec 2010 08:58:24 +, Keith Whitwell kei...@vmware.com wrote: This promotes a private interface to a public one, right? If so that isn't really doing us any favours as next people will complain when that newly public interface varies between releases. If you want to save disk space by sharing components, what about an alternate approach -- investigate methods for building all the DRI drivers into a single binary? That would keep the internal interface private possibly share more space than this approach. Keith The point of being optional was that distros that have a clue and know that these are private interfaces for the drivers built against that shared core could save disk space (and us driver developers could save build time, too). Note that there is no version number on the library -- ABI stability is very much not guaranteed, and you have to ship them all as one big package (which is no big deal once you've gone to shared core). pgpe5C0IO16uz.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH Resend] mesa: Optionally build a dricore support library.
On Tue, 2010-12-21 at 08:58 +, Keith Whitwell wrote: This promotes a private interface to a public one, right? If so that isn't really doing us any favours as next people will complain when that newly public interface varies between releases. Not really; the new libraries are private (contained within $DRI_INSTALL_DIR, so /usr/lib/dri by default) and unversioned. This is not significantly different to, say, the shared objects in /usr/lib/egl which have come and gone without complaint. This patch does *not* expose any additional interfaces in the public libGL, GLES, etc libraries. Where objects need to be built with default visibility, they're built twice; once with -fvisibility=hidden for the code destined for the public libraries, once without for the shared, private libraries. If you want to save disk space by sharing components, what about an alternate approach -- investigate methods for building all the DRI drivers into a single binary? That would keep the internal interface private possibly share more space than this approach. It would indeed save a bit more space, and also apply more easily to the gallium drivers. It'd require a much larger patch though - we'd need to change the libGL←→dri driver interface and patch X to keep up, right? If that's the direction you'd prefer to go, I could look at doing that. I think it'd be substantially more invasive, though, and more difficult to make optional. Keith On Mon, 2010-12-20 at 20:34 -0800, Christopher James Halse Rogers wrote: This an adds --enable-shared-dricore option to configure. When enabled, DRI modules will link against a shared copy of the common mesa routines rather than statically linking these. This saves about 30MB on disc with a full complement of classic DRI drivers. --- Resending as it seems to have been ignored the first time. We've applied this in Ubuntu as we are (as always) scrabbling for CD space on the LiveCDs, but Fedora had a similar patch in the dim distant past. This seems to be something that distros generally will be interested in. configs/autoconf.in|8 - configs/default|3 ++ configs/freebsd-dri|4 ++- configs/linux-dri |4 ++- configs/linux-dri-xcb |4 ++- configs/linux-egl |4 ++- configs/linux-indirect |3 +- configure.ac | 32 +- src/glsl/Makefile | 20 ++- src/mesa/Makefile | 57 +++ src/mesa/drivers/dri/Makefile.template | 12 +++ src/mesa/drivers/osmesa/Makefile |2 +- src/mesa/x86/read_rgba_span_x86.S |8 13 files changed, 136 insertions(+), 25 deletions(-) diff --git a/configs/autoconf.in b/configs/autoconf.in index e2d70c6..37a137d 100644 --- a/configs/autoconf.in +++ b/configs/autoconf.in @@ -33,6 +33,8 @@ LLVM_LDFLAGS = @LLVM_LDFLAGS@ LLVM_LIBS = @LLVM_LIBS@ GLW_CFLAGS = @GLW_CFLAGS@ GLUT_CFLAGS = @GLUT_CFLAGS@ +DRI_CFLAGS = @DRI_CFLAGS@ +DRI_CXXFLAGS = @DRI_CXXFLAGS@ TALLOC_LIBS = @TALLOC_LIBS@ TALLOC_CFLAGS = @TALLOC_CFLAGS@ @@ -103,7 +105,10 @@ GALLIUM_AUXILIARIES = $(TOP)/src/gallium/auxiliary/libgallium.a GALLIUM_DRIVERS = $(foreach DIR,$(GALLIUM_DRIVERS_DIRS),$(TOP)/src/gallium/drivers/$(DIR)/lib$(DIR).a) # Driver specific build vars -DRI_DIRS = @DRI_DIRS@ +DRI_DIRS = @DRI_DIRS@ +DRICORE_GLSL_LIBS = @DRICORE_GLSL_LIBS@ +DRICORE_LIBS = @DRICORE_LIBS@ +DRICORE_LIB_DEPS = @DRICORE_LIB_DEPS@ EGL_PLATFORMS = @EGL_PLATFORMS@ EGL_CLIENT_APIS = @EGL_CLIENT_APIS@ @@ -131,6 +136,7 @@ GLESv2_LIB_DEPS = $(EXTRA_LIB_PATH) @GLESv2_LIB_DEPS@ VG_LIB_DEPS = $(EXTRA_LIB_PATH) @VG_LIB_DEPS@ # DRI dependencies +MESA_MODULES = @MESA_MODULES@ DRI_LIB_DEPS = $(EXTRA_LIB_PATH) @DRI_LIB_DEPS@ LIBDRM_CFLAGS = @LIBDRM_CFLAGS@ LIBDRM_LIB = @LIBDRM_LIBS@ diff --git a/configs/default b/configs/default index 0301345..1feeb97 100644 --- a/configs/default +++ b/configs/default @@ -85,6 +85,9 @@ VG_LIB_GLOB = $(VG_LIB_NAME)* TALLOC_LIBS = `pkg-config --libs talloc` TALLOC_CFLAGS = `pkg-config --cflags talloc` +DRI_CFLAGS = $(CFLAGS) +DRI_CXXFLAGS = $(CXXFLAGS) + # Optional assembly language optimization files for libGL MESA_ASM_SOURCES = diff --git a/configs/freebsd-dri b/configs/freebsd-dri index a4aa82e..23cf58a 100644 --- a/configs/freebsd-dri +++ b/configs/freebsd-dri @@ -30,9 +30,11 @@ ASM_SOURCES = MESA_ASM_SOURCES = # Library/program dependencies +MESA_MODULES = $(TOP)/src/mesa/libmesa.a + LIBDRM_CFLAGS = `pkg-config --cflags libdrm` LIBDRM_LIB = `pkg-config --libs libdrm` -DRI_LIB_DEPS = -L/usr/local/lib -lm -pthread -lexpat $(LIBDRM_LIB) +DRI_LIB_DEPS =