[Mesa-dev] [PATCH 1/4] gallium: add fragment shader property for color writes to all buffers.

2010-12-23 Thread Dave Airlie
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

2010-12-23 Thread Dave Airlie
---
 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

2010-12-23 Thread firos ismail
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.

2010-12-23 Thread Tilman Sauerbeck
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

2010-12-23 Thread bugzilla-daemon
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

2010-12-23 Thread bugzilla-daemon
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.

2010-12-23 Thread Keith Whitwell
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

2010-12-23 Thread bugzilla-daemon
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

2010-12-23 Thread tom fogal
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

2010-12-23 Thread Arthur Huillet
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?)

2010-12-23 Thread bugzilla-daemon
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

2010-12-23 Thread Eric Anholt
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.

2010-12-23 Thread Eric Anholt
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.

2010-12-23 Thread Christopher James Halse Rogers
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 =