[Mesa-dev] [PATCH] nouveau: Fix bugs in nouveau_video_buffer

[Maarten Lankhorst]

Double free and array overflow, even if only 2 members are
used the last one needs to be set to NULL explicitly.

Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com

---
 src/gallium/drivers/nouveau/nouveau_video.c |1 -
 src/gallium/drivers/nouveau/nouveau_video.h |6 +++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_video.c 
b/src/gallium/drivers/nouveau/nouveau_video.c
index 162e1aa..a442537 100644
--- a/src/gallium/drivers/nouveau/nouveau_video.c
+++ b/src/gallium/drivers/nouveau/nouveau_video.c
@@ -835,7 +835,6 @@ nouveau_video_buffer_create(struct pipe_context *pipe,
 
 error:
nouveau_video_buffer_destroy(buffer-base);
-   FREE(buffer);
return NULL;
 }
 
diff --git a/src/gallium/drivers/nouveau/nouveau_video.h 
b/src/gallium/drivers/nouveau/nouveau_video.h
index c6875c3..22593ff 100644
--- a/src/gallium/drivers/nouveau/nouveau_video.h
+++ b/src/gallium/drivers/nouveau/nouveau_video.h
@@ -7,10 +7,10 @@
 struct nouveau_video_buffer {
struct pipe_video_buffer base;
unsigned num_planes;
-   struct pipe_resource *resources[2];
-   struct pipe_sampler_view *sampler_view_planes[2];
+   struct pipe_resource *resources[3];
+   struct pipe_sampler_view *sampler_view_planes[3];
struct pipe_sampler_view *sampler_view_components[3];
-   struct pipe_surface  *surfaces[2];
+   struct pipe_surface  *surfaces[3];
 };
 
 struct nouveau_decoder {
-- 
1.7.7.4



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] vdpau: Add support for parameters

[Maarten Lankhorst]

Currently only validating, since nothing else can be done with it yet

Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com

---
 src/gallium/state_trackers/vdpau/mixer.c |   95 +-
 src/gallium/state_trackers/vdpau/query.c |   41 +-
 src/gallium/state_trackers/vdpau/vdpau_private.h |3 +
 3 files changed, 133 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index 1588744..276f5d5 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -49,12 +49,16 @@ vlVdpVideoMixerCreate(VdpDevice device,
vlVdpVideoMixer *vmixer = NULL;
VdpStatus ret;
float csc[16];
+   struct pipe_screen *screen;
+   unsigned max_width, max_height, i;
+   enum pipe_video_profile prof = PIPE_VIDEO_PROFILE_UNKNOWN;
 
VDPAU_MSG(VDPAU_TRACE, [VDPAU] Creating VideoMixer\n);
 
vlVdpDevice *dev = vlGetDataHTAB(device);
if (!dev)
   return VDP_STATUS_INVALID_HANDLE;
+   screen = dev-vscreen-pscreen;
 
vmixer = CALLOC(1, sizeof(vlVdpVideoMixer));
if (!vmixer)
@@ -72,7 +76,7 @@ vlVdpVideoMixerCreate(VdpDevice device,
vl_compositor_set_csc_matrix(vmixer-compositor, csc);
 
/*
-* TODO: Handle features and parameters
+* TODO: Handle features
 */
 
*mixer = vlAddDataHTAB(vmixer);
@@ -80,10 +84,49 @@ vlVdpVideoMixerCreate(VdpDevice device,
   ret = VDP_STATUS_ERROR;
   goto no_handle;
}
-
+   vmixer-chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
+   ret = VDP_STATUS_INVALID_VIDEO_MIXER_PARAMETER;
+   for (i = 0; i  parameter_count; ++i) {
+  switch (parameters[i]) {
+  case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_WIDTH:
+ vmixer-video_width = *(uint32_t*)parameter_values[i];
+ break;
+  case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_HEIGHT:
+ vmixer-video_height = *(uint32_t*)parameter_values[i];
+ break;
+  case VDP_VIDEO_MIXER_PARAMETER_CHROMA_TYPE:
+ vmixer-chroma_format = 
ChromaToPipe(*(VdpChromaType*)parameter_values[i]);
+ break;
+  case VDP_VIDEO_MIXER_PARAMETER_LAYERS:
+ vmixer-max_layers = *(uint32_t*)parameter_values[i];
+ break;
+  default: goto no_params;
+  }
+   }
+   ret = VDP_STATUS_INVALID_VALUE;
+   if (vmixer-max_layers  4) {
+  VDPAU_MSG(VDPAU_TRACE, [VDPAU] Max layers  4 not supported\n, 
vmixer-max_layers);
+  goto no_params;
+   }
+   max_width = screen-get_video_param(screen, prof, PIPE_VIDEO_CAP_MAX_WIDTH);
+   max_height = screen-get_video_param(screen, prof, 
PIPE_VIDEO_CAP_MAX_HEIGHT);
+   if (vmixer-video_width  48 ||
+   vmixer-video_width  max_width) {
+  VDPAU_MSG(VDPAU_TRACE, [VDPAU] 48  %u  %u not valid for width\n, 
vmixer-video_width, max_width);
+  goto no_params;
+   }
+   if (vmixer-video_height  48 ||
+   vmixer-video_height  max_height) {
+  VDPAU_MSG(VDPAU_TRACE, [VDPAU] 48  %u  %u  not valid for height\n, 
vmixer-video_height, max_height);
+  goto no_params;
+   }
return VDP_STATUS_OK;
 
+no_params:
+   vlRemoveDataHTAB(*mixer);
 no_handle:
+   vl_compositor_cleanup(vmixer-compositor);
+   FREE(vmixer);
return ret;
 }
 
@@ -100,6 +143,7 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
vmixer = vlGetDataHTAB(mixer);
if (!vmixer)
   return VDP_STATUS_INVALID_HANDLE;
+   vlRemoveDataHTAB(mixer);
 
vl_compositor_cleanup(vmixer-compositor);
 
@@ -133,6 +177,18 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
return VDP_STATUS_OK;
 }
 
+static VdpStatus
+check_video_surface(vlVdpVideoMixer *mixer, vlVdpSurface *surf)
+{
+   if (surf-device != mixer-device)
+  return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+   if (mixer-video_width  surf-video_buffer-width ||
+   mixer-video_height  surf-video_buffer-height ||
+   mixer-chroma_format != surf-video_buffer-chroma_format)
+  return VDP_STATUS_INVALID_SIZE;
+   return VDP_STATUS_OK;
+}
+
 /**
  * Perform a video post-processing and compositing operation.
  */
@@ -153,6 +209,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
 VdpLayer const *layers)
 {
struct pipe_video_rect src_rect, dst_rect, dst_clip;
+   VdpStatus ret;
 
vlVdpVideoMixer *vmixer;
vlVdpSurface *surf;
@@ -165,6 +222,11 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
surf = vlGetDataHTAB(video_surface_current);
if (!surf)
   return VDP_STATUS_INVALID_HANDLE;
+   ret = check_video_surface(vmixer, surf);
+   if (ret)
+  return ret;
+   if (layer_count  vmixer-max_layers)
+  return VDP_STATUS_INVALID_VALUE;
 
dst = vlGetDataHTAB(destination_surface);
if (!dst)
@@ -237,7 +299,34 @@ vlVdpVideoMixerGetParameterValues(VdpVideoMixer mixer,
   VdpVideoMixerParameter const *parameters,
   void *const *parameter_values)
 {
-   return 

[Mesa-dev] [PATCH 2/3] vdpau: Add support for mixer attributes

[Maarten Lankhorst]

It's harmless to add support for attributes we don't support,
since they require a feature enabled for them to affect
something. As long as they aren't enabled, nothing happens.

This enables support for custom colorspaces and background colors.

Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com

---
 src/gallium/state_trackers/vdpau/mixer.c |  125 +++---
 src/gallium/state_trackers/vdpau/query.c |   37 ++-
 src/gallium/state_trackers/vdpau/vdpau_private.h |4 +-
 3 files changed, 149 insertions(+), 17 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index 276f5d5..a05ad57 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -48,7 +48,6 @@ vlVdpVideoMixerCreate(VdpDevice device,
 {
vlVdpVideoMixer *vmixer = NULL;
VdpStatus ret;
-   float csc[16];
struct pipe_screen *screen;
unsigned max_width, max_height, i;
enum pipe_video_profile prof = PIPE_VIDEO_PROFILE_UNKNOWN;
@@ -67,13 +66,9 @@ vlVdpVideoMixerCreate(VdpDevice device,
vmixer-device = dev;
vl_compositor_init(vmixer-compositor, dev-context-pipe);
 
-   vl_csc_get_matrix
-   (
-  debug_get_bool_option(G3DVL_NO_CSC, FALSE) ?
-  VL_CSC_COLOR_STANDARD_IDENTITY : VL_CSC_COLOR_STANDARD_BT_601,
-  NULL, true, csc
-   );
-   vl_compositor_set_csc_matrix(vmixer-compositor, csc);
+   vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, true, vmixer-csc);
+   if (!debug_get_bool_option(G3DVL_NO_CSC, FALSE))
+  vl_compositor_set_csc_matrix(vmixer-compositor, vmixer-csc);
 
/*
 * TODO: Handle features
@@ -120,6 +115,10 @@ vlVdpVideoMixerCreate(VdpDevice device,
   VDPAU_MSG(VDPAU_TRACE, [VDPAU] 48  %u  %u  not valid for height\n, 
vmixer-video_height, max_height);
   goto no_params;
}
+   vmixer-luma_key_min = 0.f;
+   vmixer-luma_key_max = 1.f;
+   vmixer-noise_reduction_level = 0.f;
+   vmixer-sharpness = 0.f;
return VDP_STATUS_OK;
 
 no_params:
@@ -178,7 +177,7 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
 }
 
 static VdpStatus
-check_video_surface(vlVdpVideoMixer *mixer, vlVdpSurface *surf)
+vl_check_video_surface(vlVdpVideoMixer *mixer, vlVdpSurface *surf)
 {
if (surf-device != mixer-device)
   return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
@@ -222,7 +221,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
surf = vlGetDataHTAB(video_surface_current);
if (!surf)
   return VDP_STATUS_INVALID_HANDLE;
-   ret = check_video_surface(vmixer, surf);
+   ret = vl_check_video_surface(vmixer, surf);
if (ret)
   return ret;
if (layer_count  vmixer-max_layers)
@@ -252,6 +251,12 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer,
   VdpVideoMixerAttribute const *attributes,
   void const *const *attribute_values)
 {
+   const VdpColor *background_color;
+   union pipe_color_union color;
+   const float *vdp_csc;
+   float val;
+   unsigned i;
+
if (!(attributes  attribute_values))
   return VDP_STATUS_INVALID_POINTER;
 
@@ -259,9 +264,59 @@ vlVdpVideoMixerSetAttributeValues(VdpVideoMixer mixer,
if (!vmixer)
   return VDP_STATUS_INVALID_HANDLE;
 
-   /*
-* TODO: Implement the function
-*/
+   for (i = 0; i  attribute_count; ++i) {
+  switch (attributes[i]) {
+  case VDP_VIDEO_MIXER_ATTRIBUTE_BACKGROUND_COLOR:
+ background_color = attribute_values[i];
+ color.f[0] = background_color-red;
+ color.f[1] = background_color-green;
+ color.f[2] = background_color-blue;
+ color.f[3] = background_color-alpha;
+ vl_compositor_set_clear_color(vmixer-compositor, color);
+ break;
+  case VDP_VIDEO_MIXER_ATTRIBUTE_CSC_MATRIX:
+ vdp_csc = attribute_values[i];
+ vmixer-custom_csc = !!vdp_csc;
+ if (!vdp_csc)
+vl_csc_get_matrix(VL_CSC_COLOR_STANDARD_BT_601, NULL, 1, 
vmixer-csc);
+ else
+memcpy(vmixer-csc, vdp_csc, sizeof(float)*12);
+ if (!debug_get_bool_option(G3DVL_NO_CSC, FALSE))
+vl_compositor_set_csc_matrix(vmixer-compositor, vmixer-csc);
+ break;
+  case VDP_VIDEO_MIXER_ATTRIBUTE_NOISE_REDUCTION_LEVEL:
+ val = *(float*)attribute_values[i];
+ if (val  0.f || val  1.f)
+return VDP_STATUS_INVALID_VALUE;
+ vmixer-noise_reduction_level = val;
+ break;
+  case VDP_VIDEO_MIXER_ATTRIBUTE_LUMA_KEY_MIN_LUMA:
+ val = *(float*)attribute_values[i];
+ if (val  0.f || val  1.f)
+return VDP_STATUS_INVALID_VALUE;
+ vmixer-luma_key_min = val;
+ break;
+  case VDP_VIDEO_MIXER_ATTRIBUTE_LUMA_KEY_MAX_LUMA:
+ val = *(float*)attribute_values[i];
+ if (val  0.f || val  1.f)
+return VDP_STATUS_INVALID_VALUE;
+ vmixer-luma_key_max = val;
+ break;
+  case 

[Mesa-dev] [PATCH 3/3] vdpau: Add background surface support

[Maarten Lankhorst]

Sets rgba layer as zeroth layer if a custom background_surface is specified.

Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com

---
Can be applied without dependency on previous 2 patches in this series

 src/gallium/state_trackers/vdpau/mixer.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index a05ad57..cd15739 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -209,6 +209,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
 {
struct pipe_video_rect src_rect, dst_rect, dst_clip;
VdpStatus ret;
+   unsigned layer = 0;
 
vlVdpVideoMixer *vmixer;
vlVdpSurface *surf;
@@ -231,8 +232,16 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
if (!dst)
   return VDP_STATUS_INVALID_HANDLE;
 
+   if (background_surface != VDP_INVALID_HANDLE) {
+  vlVdpOutputSurface *bg = vlGetDataHTAB(background_surface);
+  if (!bg)
+ return VDP_STATUS_INVALID_HANDLE;
+  vl_compositor_set_rgba_layer(vmixer-compositor, layer++, 
bg-sampler_view,
+   RectToPipe(background_source_rect, 
src_rect), NULL);
+   }
+
vl_compositor_clear_layers(vmixer-compositor);
-   vl_compositor_set_buffer_layer(vmixer-compositor, 0, surf-video_buffer,
+   vl_compositor_set_buffer_layer(vmixer-compositor, layer, 
surf-video_buffer,
   RectToPipe(video_source_rect, src_rect), 
NULL);
vl_compositor_render(vmixer-compositor, dst-surface,
 RectToPipe(destination_video_rect, dst_rect),
-- 
1.7.7.4



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)

[Dave Airlie]

On Wed, Dec 7, 2011 at 6:32 PM, Eric Anholt e...@anholt.net wrote:
 On Wed,  7 Dec 2011 10:24:09 +, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 This keeps track of the creation process and stores a drawable type,
 it then blocks DRI2 from getting called if the drawable is a pixmap.

 v2: check if we have a GLX drawable, which means we aren't a pbuffer,
 avoid doing flush at all since its meant to be a no-op.

 I still think this is the wrong way to go.  As ajax pointed out, there's
 all sorts of races available from trying to guess client-side, and
 there's no way anybody's relying on the current (print an error message
 in the xorg log) behavior of the DRI2 protocol for single-buffered, so
 we might as well resolve that DRI2 protocol should do what we want for
 GLX.

I've been thinking about the races, and I'm not sure they really
apply, like we would have all those races now with the current code,

Look at the patch, when the glx_drawable struct is created we record
the type of the pixmap, we then call GetGLXDrawable, which looks the
XID up in the hash,
so if the XID has been reused or raced, then we would have to expect
the hash to be incorrect, or else avoid using it in a lot of other
places.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] softpipe: fix shadow 2d texture array sampling

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

The 4th texcoord is used in this case for the comparison.

This fixes piglit glsl-fs-shadow2DArray* on softpipe.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/gallium/auxiliary/tgsi/tgsi_exec.c   |   11 ++-
 src/gallium/drivers/softpipe/sp_tex_sample.c |   17 -
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index a44ba80..4115e35 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -1822,7 +1822,6 @@ exec_tex(struct tgsi_exec_machine *mach,
   break;
 
case TGSI_TEXTURE_2D_ARRAY:
-   case TGSI_TEXTURE_SHADOW2D_ARRAY:
   FETCH(r[0], 0, CHAN_X);
   FETCH(r[1], 0, CHAN_Y);
   FETCH(r[2], 0, CHAN_Z);
@@ -1837,7 +1836,17 @@ exec_tex(struct tgsi_exec_machine *mach,
   control,
   r[0], r[1], r[2], r[3]);  /* outputs */
   break;
+   case TGSI_TEXTURE_SHADOW2D_ARRAY:
+  FETCH(r[0], 0, CHAN_X);
+  FETCH(r[1], 0, CHAN_Y);
+  FETCH(r[2], 0, CHAN_Z);
+  FETCH(r[3], 0, CHAN_W);
 
+  fetch_texel(mach-Samplers[unit],
+  r[0], r[1], r[2], r[3], /* S, T, P, LOD */
+  control,
+  r[0], r[1], r[2], r[3]);  /* outputs */
+  break;
case TGSI_TEXTURE_3D:
case TGSI_TEXTURE_CUBE:
   FETCH(r[0], 0, CHAN_X);
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c 
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index 43f201f..8123d7b 100644
--- a/src/gallium/drivers/softpipe/sp_tex_sample.c
+++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
@@ -2113,15 +2113,22 @@ sample_compare(struct tgsi_sampler *tgsi_sampler,
 
/**
 * Compare texcoord 'p' (aka R) against texture value 'rgba[0]'
+* for 2D Array texture we need to use the 'c0' (aka Q).
 * When we sampled the depth texture, the depth value was put into all
 * RGBA channels.  We look at the red channel here.
 */
 
-   pc0 = CLAMP(p[0], 0.0F, 1.0F);
-   pc1 = CLAMP(p[1], 0.0F, 1.0F);
-   pc2 = CLAMP(p[2], 0.0F, 1.0F);
-   pc3 = CLAMP(p[3], 0.0F, 1.0F);
-
+   if (samp-view-texture-target == PIPE_TEXTURE_2D_ARRAY) {
+  pc0 = CLAMP(c0[0], 0.0F, 1.0F);
+  pc1 = CLAMP(c0[1], 0.0F, 1.0F);
+  pc2 = CLAMP(c0[2], 0.0F, 1.0F);
+  pc3 = CLAMP(c0[3], 0.0F, 1.0F);
+   } else {
+  pc0 = CLAMP(p[0], 0.0F, 1.0F);
+  pc1 = CLAMP(p[1], 0.0F, 1.0F);
+  pc2 = CLAMP(p[2], 0.0F, 1.0F);
+  pc3 = CLAMP(p[3], 0.0F, 1.0F);
+   }
/* compare four texcoords vs. four texture samples */
switch (sampler-compare_func) {
case PIPE_FUNC_LESS:
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] softpipe: fix shadow1d tests.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This fixes the piglit glsl-1.10 shadow1D related tests.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/gallium/auxiliary/tgsi/tgsi_exec.c |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 4115e35..8df81d1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -1760,7 +1760,6 @@ exec_tex(struct tgsi_exec_machine *mach,
 
switch (inst-Texture.Texture) {
case TGSI_TEXTURE_1D:
-   case TGSI_TEXTURE_SHADOW1D:
   FETCH(r[0], 0, CHAN_X);
 
   if (modifier == TEX_MODIFIER_PROJECTED) {
@@ -1772,6 +1771,19 @@ exec_tex(struct tgsi_exec_machine *mach,
   control,
   r[0], r[1], r[2], r[3]); /* R, G, B, A */
   break;
+   case TGSI_TEXTURE_SHADOW1D:
+  FETCH(r[0], 0, CHAN_X);
+  FETCH(r[2], 0, CHAN_Z);
+
+  if (modifier == TEX_MODIFIER_PROJECTED) {
+ micro_div(r[0], r[0], r[3]);
+  }
+
+  fetch_texel(mach-Samplers[unit],
+  r[0], ZeroVec, r[2], lod,  /* S, T, P, LOD */
+  control,
+  r[0], r[1], r[2], r[3]); /* R, G, B, A */
+  break;
 
case TGSI_TEXTURE_2D:
case TGSI_TEXTURE_RECT:
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder

[Andy Furniss]

Maarten Lankhorst wrote:


Looks like I made the checking a bit too paranoid, causing it to not always 
decode last few macroblocks because of fear of reaching end of stream..
Does this work? I removed a few paranoid asserts, and if performance is still 
bad, I'll alter the patch to swap between multiple decode buffers to fix it. 
That should bring performance back to old level.


This version does fix the macroblocks issue.

Perf is still poor.

The dvd assert is also still present. It doesn't happen with all dvds - 
and is not a regression caused by this patch.


When playing with -cache and skipping around I get a different assert - 
attached are backtraces from both types.
mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl-length' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6b49a10 (LWP 6986)]
0xe424 in __kernel_vsyscall ()
(gdb) bt full
#0  0xe424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb6d0715a in raise () from /lib/libc.so.6
No symbol table info available.
#2  0xb6d08787 in abort () from /lib/libc.so.6
No symbol table info available.
#3  0xb6d0069e in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#4  0xb5de9573 in motion_vector (bs=0xab51c50, r=value optimized out, 
s=value optimized out, dmv=0, delta=0xbfc0e2d4, dmvector=0xbfc0e2d0) at 
vl/vl_vlc.h:172
t = 1
__PRETTY_FUNCTION__ = motion_vector
#5  0xb5deab7f in decode_slice (bs=0xab51c50, code=value optimized out) at 
vl/vl_mpeg12_bitstream.c:679
inc = 4
mb = {base = {codec = PIPE_VIDEO_CODEC_MPEG12}, x = 28, y = 1, 
macroblock_type = 10 '\n', macroblock_modes = {bits = {frame_motion_type = 2, 
field_motion_type = 0, dct_type = 0}, value = 2}, motion_vertical_field_select 
= 0 '\0', PMV = {{{0, 0}, {0, 0}}, {{0, 0}, {0, 0}}}, coded_block_pattern = 58, 
  blocks = 0xbfc0dfa4, num_skipped_macroblocks = 3}
dct_blocks = {0, 0, -44, -44, -44, 44, 0 repeats 58 times, -44, -44, 
44, -44, 44, 0, 44, -44, 0 repeats 56 times, 44, 44, 0, 0, 44, 0, 0, 0, 0, 
44, -132, 0, 0, 0, 0, 0, 0, 0, -44, 0 repeats 74 times, 9220, -44, 0, 0, 0, 
0, -44, 0 repeats 156 times}
dct_scale = 44
x = value optimized out
__PRETTY_FUNCTION__ = decode_slice
#6  0xb5deb72b in vl_mpg12_bs_decode (bs=0xab51c50, n=value optimized out, 
len=107065, lens=0xbfc0e390, buffer=0xbfc0e3b0) at vl/vl_mpeg12_bitstream.c:982
__PRETTY_FUNCTION__ = vl_mpg12_bs_decode
#7  0xb5de808b in vl_mpeg12_decode_bitstream (decoder=0xaab5f98, 
target=0xaac3c70, picture=0xbfc0e3f8, n=1, total_len=107065, lens=0xbfc0e390, 
data=0xbfc0e3b0) at vl/vl_mpeg12_decoder.c:707
i = 3
__PRETTY_FUNCTION__ = vl_mpeg12_decode_bitstream
#8  0xb5d84dd4 in vlVdpDecoderRender (decoder=9, target=19, 
picture_info=0x8ae38b4, bitstream_buffer_count=1, bitstream_buffers=0xaac3330) 
at decode.c:382
total_size = 107065
ret = VDP_STATUS_OK
dec = (struct pipe_video_decoder *) 0xaab5f98
i = 6986
desc = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, mpeg12 = 
{base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0xaabb7f8, 
ref_backward = 0x0, picture_coding_type = 2, picture_structure = 3, 
frame_pred_frame_dct = 1, q_scale_type = 1, alternate_scan = 0, 
intra_vlc_format = 1, 
concealment_motion_vectors = 0, intra_dc_precision = 2, f_code = {{5, 5}, 
{14, 14}}, top_field_first = 1, full_pel_forward_vector = 0, 
full_pel_backward_vector = 0, num_slices = 35, 
intra_matrix = 0x8ae38cf 
\b\b\b\b\b\b\b\t\b\b\b\b\b\b\t\t\b\b\b\b\b\t\t\n\b\b\b\b\b\t\t\n\b\b\b\b\b\t\n\f\b\b\b\b\t\n\f\017\b\b\b\t\n\f\016\021\b\b\t\n\f\016\021\025,
 '\b' repeats 64 times, non_intra_matrix = 0x8ae390f '\b' repeats 64 
times}, mpeg4 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, 
ref_forward = 0xaabb7f8, ref_backward = 0x0, trd = {2, 3}, trb = {1, 1}, 
vop_time_increment_resolution = 0, vop_coding_type = 0 '\0', vop_fcode_forward 
= 0 '\0', vop_fcode_backward = 1 '\001', resync_marker_disable = 0 '\0', 
interlaced = 0 '\0', quant_type = 0 '\0', quarter_sample = 0 '\0', 
short_video_header = 0 '\0', rounding_control = 0 '\0', 
alternate_vertical_scan_flag = 0 '\0', top_field_first = 2 '\002', intra_matrix 
= 0x5 Address 0x5 out of bounds, non_intra_matrix = 0x5 Address 0x5 out of 
bounds}, vc1 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward 
= 0xaabb7f8, 
ref_backward = 0x0, slice_count = 2, picture_type = 3 '\003', 
frame_coding_mode = 0 '\0', postprocflag = 0 '\0', pulldown = 0 '\0', interlace 
= 1 '\001', tfcntrflag = 0 '\0', finterpflag = 0 '\0', psf = 0 '\0', dquant = 1 
'\001', panscan_flag = 0 '\0', refdist_flag = 0 '\0', quantizer = 0 '\0', 
extended_mv = 0 '\0', extended_dmv = 0 '\0', overlap = 0 '\0', vstransform 
= 0 '\0', loopfilter = 1 '\001', fastuvmc = 0 '\0', range_mapy_flag = 0 '\0', 
range_mapy = 0 '\0', range_mapuv_flag = 0 '\0', range_mapuv = 0 '\0', multires 
= 0 

Re: [Mesa-dev] [PATCH 1/3] vdpau: Add support for parameters

[Christian König]

Committed all three with just a minor change:

removed check_video_surface in favor of doing the checks directly in the 
render function.



On 19.12.2011 10:10, Maarten Lankhorst wrote:

Currently only validating, since nothing else can be done with it yet

Signed-off-by: Maarten Lankhorstm.b.lankho...@gmail.com

---
  src/gallium/state_trackers/vdpau/mixer.c |   95 +-
  src/gallium/state_trackers/vdpau/query.c |   41 +-
  src/gallium/state_trackers/vdpau/vdpau_private.h |3 +
  3 files changed, 133 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index 1588744..276f5d5 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -49,12 +49,16 @@ vlVdpVideoMixerCreate(VdpDevice device,
 vlVdpVideoMixer *vmixer = NULL;
 VdpStatus ret;
 float csc[16];
+   struct pipe_screen *screen;
+   unsigned max_width, max_height, i;
+   enum pipe_video_profile prof = PIPE_VIDEO_PROFILE_UNKNOWN;

 VDPAU_MSG(VDPAU_TRACE, [VDPAU] Creating VideoMixer\n);

 vlVdpDevice *dev = vlGetDataHTAB(device);
 if (!dev)
return VDP_STATUS_INVALID_HANDLE;
+   screen = dev-vscreen-pscreen;

 vmixer = CALLOC(1, sizeof(vlVdpVideoMixer));
 if (!vmixer)
@@ -72,7 +76,7 @@ vlVdpVideoMixerCreate(VdpDevice device,
 vl_compositor_set_csc_matrix(vmixer-compositor, csc);

 /*
-* TODO: Handle features and parameters
+* TODO: Handle features
  */

 *mixer = vlAddDataHTAB(vmixer);
@@ -80,10 +84,49 @@ vlVdpVideoMixerCreate(VdpDevice device,
ret = VDP_STATUS_ERROR;
goto no_handle;
 }
-
+   vmixer-chroma_format = PIPE_VIDEO_CHROMA_FORMAT_420;
+   ret = VDP_STATUS_INVALID_VIDEO_MIXER_PARAMETER;
+   for (i = 0; i  parameter_count; ++i) {
+  switch (parameters[i]) {
+  case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_WIDTH:
+ vmixer-video_width = *(uint32_t*)parameter_values[i];
+ break;
+  case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_HEIGHT:
+ vmixer-video_height = *(uint32_t*)parameter_values[i];
+ break;
+  case VDP_VIDEO_MIXER_PARAMETER_CHROMA_TYPE:
+ vmixer-chroma_format = 
ChromaToPipe(*(VdpChromaType*)parameter_values[i]);
+ break;
+  case VDP_VIDEO_MIXER_PARAMETER_LAYERS:
+ vmixer-max_layers = *(uint32_t*)parameter_values[i];
+ break;
+  default: goto no_params;
+  }
+   }
+   ret = VDP_STATUS_INVALID_VALUE;
+   if (vmixer-max_layers  4) {
+  VDPAU_MSG(VDPAU_TRACE, [VDPAU] Max layers  4 not supported\n, 
vmixer-max_layers);
+  goto no_params;
+   }
+   max_width = screen-get_video_param(screen, prof, PIPE_VIDEO_CAP_MAX_WIDTH);
+   max_height = screen-get_video_param(screen, prof, 
PIPE_VIDEO_CAP_MAX_HEIGHT);
+   if (vmixer-video_width  48 ||
+   vmixer-video_width  max_width) {
+  VDPAU_MSG(VDPAU_TRACE, [VDPAU] 48  %u  %u not valid for width\n, 
vmixer-video_width, max_width);
+  goto no_params;
+   }
+   if (vmixer-video_height  48 ||
+   vmixer-video_height  max_height) {
+  VDPAU_MSG(VDPAU_TRACE, [VDPAU] 48  %u  %u  not valid for height\n, 
vmixer-video_height, max_height);
+  goto no_params;
+   }
 return VDP_STATUS_OK;

+no_params:
+   vlRemoveDataHTAB(*mixer);
  no_handle:
+   vl_compositor_cleanup(vmixer-compositor);
+   FREE(vmixer);
 return ret;
  }

@@ -100,6 +143,7 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
 vmixer = vlGetDataHTAB(mixer);
 if (!vmixer)
return VDP_STATUS_INVALID_HANDLE;
+   vlRemoveDataHTAB(mixer);

 vl_compositor_cleanup(vmixer-compositor);

@@ -133,6 +177,18 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
 return VDP_STATUS_OK;
  }

+static VdpStatus
+check_video_surface(vlVdpVideoMixer *mixer, vlVdpSurface *surf)
+{
+   if (surf-device != mixer-device)
+  return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+   if (mixer-video_width  surf-video_buffer-width ||
+   mixer-video_height  surf-video_buffer-height ||
+   mixer-chroma_format != surf-video_buffer-chroma_format)
+  return VDP_STATUS_INVALID_SIZE;
+   return VDP_STATUS_OK;
+}
+
  /**
   * Perform a video post-processing and compositing operation.
   */
@@ -153,6 +209,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
  VdpLayer const *layers)
  {
 struct pipe_video_rect src_rect, dst_rect, dst_clip;
+   VdpStatus ret;

 vlVdpVideoMixer *vmixer;
 vlVdpSurface *surf;
@@ -165,6 +222,11 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
 surf = vlGetDataHTAB(video_surface_current);
 if (!surf)
return VDP_STATUS_INVALID_HANDLE;
+   ret = check_video_surface(vmixer, surf);
+   if (ret)
+  return ret;
+   if (layer_count  vmixer-max_layers)
+  return VDP_STATUS_INVALID_VALUE;

 dst = vlGetDataHTAB(destination_surface);
 if (!dst)
@@ -237,7 +299,34 @@ 

[Mesa-dev] [Bug 43949] New: OSMesa does not work with 565 pixel format

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=43949

 Bug #: 43949
   Summary: OSMesa does not work with 565 pixel format
Classification: Unclassified
   Product: Mesa
   Version: 7.11
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: agalak...@gmail.com


Created attachment 54568
  -- https://bugs.freedesktop.org/attachment.cgi?id=54568
Fix for 565 pixel format

The following code did not work due to forgotten case statement:

ctx = OSMesaCreateContext(OSMESA_RGB_565, NULL);
OSMesaMakeCurrent(ctx, fb, GL_UNSIGNED_SHORT_5_6_5, 800, 480);

The attached patch fixes the problem.

-- 
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/2] linker: fix strdup memory leak

[Pekka Paalanen]

On Fri, 16 Dec 2011 10:46:11 -0800
Ian Romanick i...@freedesktop.org wrote:

 On 12/14/2011 11:26 PM, Pekka Paalanen wrote:
  string_to_uint_map::put() already does a strdup() for the key
  argument, so we leak the memory allocated by strdup() in
  link_uniforms.cpp.
 
  Remove the extra strdup(), fixes a few Valgrind detected leaks.
 
 Have you run piglit on this?  I seem to recall adding the extra
 strdup for a reason.  The hash table keeps a copy of the key pointer
 passed to it, and the underlying object may be deleted before the
 hash table is deleted.  This can happen if the back-end optimizes
 some uniforms away after the linker has generated the list of
 active uniforms.  I'm pretty sure there were one or two test cases
 that hit this on i965.

Sorry, I didn't. Finally got piglit running, though readPixSanity
failed on stencil values. Anyway it's running all.tests now for the
upstream Mesa master, and then I'll run it with my patches.

Oh, this is Sandybridge, btw.

  --- a/src/glsl/link_uniforms.cpp
  +++ b/src/glsl/link_uniforms.cpp
  @@ -174,8 +174,7 @@ private:
  if (this-map-get(id, name))
   return;
 
  -  char *key = strdup(name);
  -  this-map-put(this-num_active_uniforms, key);
  +  this-map-put(this-num_active_uniforms, name);
 
  /* Each leaf uniform occupies one entry in the list of
  active
   * uniforms.

The whole visit_field() function is this:

   virtual void visit_field(const glsl_type *type, const char *name)
   {
  assert(!type-is_record());
  assert(!(type-is_array()  type-fields.array-is_record()));

  /* Count the number of samplers regardless of whether the uniform is
   * already in the hash table.  The hash table prevents adding the same
   * uniform for multiple shader targets, but in this case we want to
   * count it for each shader target.
   */
  const unsigned values = values_for_type(type);
  if (type-contains_sampler()) {
 this-num_shader_samplers +=
type-is_array() ? type-array_size() : 1;
  } else {
 /* Accumulate the total number of uniform slots used by this shader.
  * Note that samplers do not count against this limit because they
  * don't use any storage on current hardware.
  */
 this-num_shader_uniform_components += values;
  }

  /* If the uniform is already in the map, there's nothing more to do.
   */
  unsigned id;
  if (this-map-get(id, name))
 return;

  char *key = strdup(name);
  this-map-put(this-num_active_uniforms, key);

  /* Each leaf uniform occupies one entry in the list of active
   * uniforms.
   */
  this-num_active_uniforms++;
  this-num_values += values;
   }

The variable 'key' is not used anywhere else but passed to
string_to_uint_map::put(). That function in its whole is:

   void put(unsigned value, const char *key)
   {
  /* The low-level hash table structure returns NULL if key is not in the
   * hash table.  However, users of this map might want to store zero as a
   * valid value in the table.  Bias the value by +1 so that a
   * user-specified zero is stored as 1.  This enables ::get to tell the
   * difference between a user-specified zero (returned as 1 by
   * hash_table_find) and the key not in the table (returned as 0 by
   * hash_table_find).
   *
   * The net effect is that we can't store UINT_MAX in the table.  This is
   * because UINT_MAX+1 = 0.
   */
  assert(value != UINT_MAX);
  hash_table_replace(this-ht,
 (void *) (intptr_t) (value + 1),
 strdup(key));
   }

Therefore, as far as I see, 'key' is not used for anything else than
passed again through strdup(), which would effectively be:

   hash_table_replace(..., ..., strdup(strdup(name)));

I don't see any case where this could not be a leak, or prevent a bug.

What do I miss? Is there somewhere another put() that overwrites or
overloads this version of put()?


Thanks,
pq

ps. As for the other patch, thanks for the advice on how to fix it
properly. I don't think I can do that this year, though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] softpipe: fix shadow1d tests.

[Brian Paul]

On 12/19/2011 04:53 AM, Dave Airlie wrote:

From: Dave Airlieairl...@redhat.com

This fixes the piglit glsl-1.10 shadow1D related tests.

Signed-off-by: Dave Airlieairl...@redhat.com
---
  src/gallium/auxiliary/tgsi/tgsi_exec.c |   14 +-
  1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 4115e35..8df81d1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -1760,7 +1760,6 @@ exec_tex(struct tgsi_exec_machine *mach,

 switch (inst-Texture.Texture) {
 case TGSI_TEXTURE_1D:
-   case TGSI_TEXTURE_SHADOW1D:
FETCH(r[0], 0, CHAN_X);

if (modifier == TEX_MODIFIER_PROJECTED) {
@@ -1772,6 +1771,19 @@ exec_tex(struct tgsi_exec_machine *mach,
control,
r[0],r[1],r[2],r[3]); /* R, G, B, A */
break;
+   case TGSI_TEXTURE_SHADOW1D:
+  FETCH(r[0], 0, CHAN_X);
+  FETCH(r[2], 0, CHAN_Z);
+
+  if (modifier == TEX_MODIFIER_PROJECTED) {
+ micro_div(r[0],r[0],r[3]);
+  }
+
+  fetch_texel(mach-Samplers[unit],
+r[0],ZeroVec,r[2], lod,  /* S, T, P, LOD */
+  control,
+r[0],r[1],r[2],r[3]); /* R, G, B, A */
+  break;

 case TGSI_TEXTURE_2D:
 case TGSI_TEXTURE_RECT:


That looks better.  Would you mind checking that the TGSI docs 
properly describe which coordinate components are used for array 
indexing, shadow distance, etc.


Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] softpipe: fix shadow 2d texture array sampling

[Brian Paul]

On 12/19/2011 04:53 AM, Dave Airlie wrote:

From: Dave Airlieairl...@redhat.com

The 4th texcoord is used in this case for the comparison.

This fixes piglit glsl-fs-shadow2DArray* on softpipe.

Signed-off-by: Dave Airlieairl...@redhat.com
---
  src/gallium/auxiliary/tgsi/tgsi_exec.c   |   11 ++-
  src/gallium/drivers/softpipe/sp_tex_sample.c |   17 -
  2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index a44ba80..4115e35 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -1822,7 +1822,6 @@ exec_tex(struct tgsi_exec_machine *mach,
break;

 case TGSI_TEXTURE_2D_ARRAY:
-   case TGSI_TEXTURE_SHADOW2D_ARRAY:
FETCH(r[0], 0, CHAN_X);
FETCH(r[1], 0, CHAN_Y);
FETCH(r[2], 0, CHAN_Z);
@@ -1837,7 +1836,17 @@ exec_tex(struct tgsi_exec_machine *mach,
control,
r[0],r[1],r[2],r[3]);  /* outputs */
break;
+   case TGSI_TEXTURE_SHADOW2D_ARRAY:
+  FETCH(r[0], 0, CHAN_X);
+  FETCH(r[1], 0, CHAN_Y);
+  FETCH(r[2], 0, CHAN_Z);
+  FETCH(r[3], 0, CHAN_W);

+  fetch_texel(mach-Samplers[unit],
+r[0],r[1],r[2],r[3], /* S, T, P, LOD */
+  control,
+r[0],r[1],r[2],r[3]);  /* outputs */
+  break;
 case TGSI_TEXTURE_3D:
 case TGSI_TEXTURE_CUBE:
FETCH(r[0], 0, CHAN_X);
diff --git a/src/gallium/drivers/softpipe/sp_tex_sample.c 
b/src/gallium/drivers/softpipe/sp_tex_sample.c
index 43f201f..8123d7b 100644
--- a/src/gallium/drivers/softpipe/sp_tex_sample.c
+++ b/src/gallium/drivers/softpipe/sp_tex_sample.c
@@ -2113,15 +2113,22 @@ sample_compare(struct tgsi_sampler *tgsi_sampler,

 /**
  * Compare texcoord 'p' (aka R) against texture value 'rgba[0]'
+* for 2D Array texture we need to use the 'c0' (aka Q).
  * When we sampled the depth texture, the depth value was put into all
  * RGBA channels.  We look at the red channel here.
  */

-   pc0 = CLAMP(p[0], 0.0F, 1.0F);
-   pc1 = CLAMP(p[1], 0.0F, 1.0F);
-   pc2 = CLAMP(p[2], 0.0F, 1.0F);
-   pc3 = CLAMP(p[3], 0.0F, 1.0F);
-
+   if (samp-view-texture-target == PIPE_TEXTURE_2D_ARRAY) {
+  pc0 = CLAMP(c0[0], 0.0F, 1.0F);
+  pc1 = CLAMP(c0[1], 0.0F, 1.0F);
+  pc2 = CLAMP(c0[2], 0.0F, 1.0F);
+  pc3 = CLAMP(c0[3], 0.0F, 1.0F);
+   } else {
+  pc0 = CLAMP(p[0], 0.0F, 1.0F);
+  pc1 = CLAMP(p[1], 0.0F, 1.0F);
+  pc2 = CLAMP(p[2], 0.0F, 1.0F);
+  pc3 = CLAMP(p[3], 0.0F, 1.0F);
+   }
 /* compare four texcoords vs. four texture samples */
 switch (sampler-compare_func) {
 case PIPE_FUNC_LESS:



Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 43949] OSMesa does not work with 565 pixel format

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=43949

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Brian Paul bri...@vmware.com 2011-12-19 06:41:47 PST ---
Thanks for finding that.  Patch committed as
d334a0fb8cbb368c337858b16cb567a28a35f688

-- 
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 43896] Mesa assembly breaks Super Meat Boy, Shank

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=43896

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #5 from Brian Paul bri...@vmware.com 2011-12-19 07:00:39 PST ---
(In reply to comment #3)
 (In reply to comment #2)
  Sounds like a bug in the application to me. From the GLX 1.4 spec (though
  that's certainly not new in 1.4):
  
  A non-NULL return value for glXGetProcAddress does not guarantee that an
  extension function is actually supported at runtime. The client must also 
  query
  glGetString() or glXQueryExtensionsString to determine if an extension is
  supported by a particular context.
 
 I'm not sure what behaviour is correct. I relied on the the description of
 glXGetProcAddress:
 http://www.opengl.org/sdk/docs/man/xhtml/glXGetProcAddress.xml
 
 A NULL pointer is returned if function requested is not suported in the
 implementation being queried.

There's no conflict between the quotes above.  Getting a non-NULL pointer is no
indication whatsoever about whether the extension is supported or not
supported.

The reason is this:  suppose the very first call in main() is
glXGetProcAddress(glGenTransformFeedbacks).  At this point, the GL library
can't determine whether the extension is supported because it hasn't even
opened an X display connection.  Depending on which display/GPU is used, the
extension may or may not be supported.  So if libGL implements the function (or
can generate a dispatch stub for it) it must return the pointer for it right
away.

Later on, the app has to check GL_EXTENSIONS to see if
GL_ARB_transform_feedback2 is really supported.  If the extension is not
supported and the function is called anyway, things might blow up.

This is an application bug.

-- 
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 2/2] st/mesa: add support for gl_ClipDistance

[Brian Paul]

On 12/17/2011 03:15 PM, Bryan Cain wrote:

---
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   49 +---
  src/mesa/state_tracker/st_program.c|   18 ++
  2 files changed, 62 insertions(+), 5 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index b929806..3e8df78 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -304,6 +304,7 @@ public:
 int samplers_used;
 bool indirect_addr_temps;
 bool indirect_addr_consts;
+   int num_clip_distances;

 int glsl_version;
 bool native_integers;
@@ -4618,9 +4619,16 @@ st_translate_program(
}

for (i = 0; i  numOutputs; i++) {
- t-outputs[i] = ureg_DECL_output(ureg,
-  outputSemanticName[i],
-  outputSemanticIndex[i]);
+ if (outputSemanticName[i] == TGSI_SEMANTIC_CLIPDIST) {
+int mask = ((1  (program-num_clip_distances - 
4*outputSemanticIndex[i])) - 1)  0xf;


Being nit-picky, but 0xf should be replaced by TGSI_WRITEMASK_XYZW to 
be totally clear.




+t-outputs[i] = ureg_DECL_output_masked(ureg,
+outputSemanticName[i],
+outputSemanticIndex[i],
+mask);
+ } else
+t-outputs[i] = ureg_DECL_output(ureg,
+ outputSemanticName[i],
+ outputSemanticIndex[i]);


I'd like to see { } braces around the else clause.



   if ((outputSemanticName[i] == TGSI_SEMANTIC_PSIZE)  proginfo-Id) {
  /* Writing to the point size result register requires special
   * handling to implement clamping.
@@ -4797,7 +4805,8 @@ out:
  static struct gl_program *
  get_mesa_program(struct gl_context *ctx,
   struct gl_shader_program *shader_program,
-struct gl_shader *shader)
+ struct gl_shader *shader,
+ int num_clip_distances)
  {
 glsl_to_tgsi_visitor* v = new glsl_to_tgsi_visitor();
 struct gl_program *prog;
@@ -4842,6 +4851,7 @@ get_mesa_program(struct gl_context *ctx,
 v-options = options;
 v-glsl_version = ctx-Const.GLSLVersion;
 v-native_integers = ctx-Const.NativeIntegers;
+   v-num_clip_distances = num_clip_distances;

 _mesa_generate_parameters_list_for_uniforms(shader_program, shader,
   prog-Parameters);
@@ -4971,6 +4981,27 @@ get_mesa_program(struct gl_context *ctx,
 return prog;
  }

+/**
+ * Searches through the IR for a declaration of gl_ClipDistance and returns the
+ * declared size of the gl_ClipDistance array.  Returns 0 if gl_ClipDistance is
+ * not declared in the IR.
+ */
+int get_clip_distance_size(exec_list *ir)
+{
+   foreach_iter (exec_list_iterator, iter, *ir) {
+  ir_instruction *inst = (ir_instruction *)iter.get();
+  ir_variable *var = inst-as_variable();
+  if (var == NULL) continue;
+  if (!strcmp(var-name, gl_ClipDistance))
+  {


The { should go on the same line as the 'if' like elsewhere.



+ fprintf(stderr, gl_ClipDistance found with size %i\n, 
var-type-length);


Left-over debug code?



+ return var-type-length;
+  }
+   }
+
+   return 0;
+}
+
  extern C {

  struct gl_shader *
@@ -5009,6 +5040,7 @@ st_new_shader_program(struct gl_context *ctx, GLuint name)
  GLboolean
  st_link_shader(struct gl_context *ctx, struct gl_shader_program *prog)
  {
+   int num_clip_distances[MESA_SHADER_TYPES];
 assert(prog-LinkStatus);

 for (unsigned i = 0; i  MESA_SHADER_TYPES; i++) {
@@ -5020,6 +5052,11 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
const struct gl_shader_compiler_options *options =
  
ctx-ShaderCompilerOptions[_mesa_shader_type_to_index(prog-_LinkedShaders[i]-Type)];

+  /* We have to determine the length of the gl_ClipDistance array before
+   * the array is lowered to two vec4s by lower_clip_distance().
+   */
+  num_clip_distances[i] = get_clip_distance_size(ir);
+
do {
   progress = false;

@@ -5036,6 +5073,7 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
   || progress;

   progress = lower_quadop_vector(ir, false) || progress;
+ progress = lower_clip_distance(ir) || progress;

   if (options-MaxIfDepth == 0)
  progress = lower_discard(ir) || progress;
@@ -5070,7 +5108,8 @@ st_link_shader(struct gl_context *ctx, struct 
gl_shader_program *prog)
if (prog-_LinkedShaders[i] == NULL)
   continue;

-  linked_prog = get_mesa_program(ctx, prog, prog-_LinkedShaders[i]);
+  linked_prog = get_mesa_program(ctx, 

Re: [Mesa-dev] [PATCH 1/2] gallium: add support for clip distances

[Brian Paul]

On 12/17/2011 03:15 PM, Bryan Cain wrote:

---
  src/gallium/auxiliary/tgsi/tgsi_dump.c |3 +-
  src/gallium/auxiliary/tgsi/tgsi_text.c |3 +-
  src/gallium/auxiliary/tgsi/tgsi_ureg.c |   36 +---
  src/gallium/auxiliary/tgsi/tgsi_ureg.h |6 
  src/gallium/include/pipe/p_shader_tokens.h |3 +-
  5 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_dump.c 
b/src/gallium/auxiliary/tgsi/tgsi_dump.c
index e830aa5..bd299b0 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_dump.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_dump.c
@@ -129,7 +129,8 @@ static const char *semantic_names[] =
 PRIM_ID,
 INSTANCEID,
 VERTEXID,
-   STENCIL
+   STENCIL,
+   CLIPDIST
  };

  static const char *immediate_type_names[] =
diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c 
b/src/gallium/auxiliary/tgsi/tgsi_text.c
index eb9190c..f46ba19 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_text.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
@@ -1024,7 +1024,8 @@ static const char *semantic_names[TGSI_SEMANTIC_COUNT] =
 PRIM_ID,
 INSTANCEID,
 VERTEXID,
-   STENCIL
+   STENCIL,
+   CLIPDIST
  };



Just FYI: it looks like semantic_names[] and interplate_names[] (and 
possibly) other arrays like that are duplicated in at least two tgsi 
files.


It would be nice if someone could move those to a shared header. 
Also, use STATIC_ASSERT() to check that there's enough entries in the 
arrays.




  static const char *interpolate_names[TGSI_INTERPOLATE_COUNT] =
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c 
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 17f9ce2..56c4492 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -122,6 +122,7 @@ struct ureg_program
 struct {
unsigned semantic_name;
unsigned semantic_index;
+  unsigned usage_mask;


Maybe add a comment indicating that the values are TGSI_WRITEMASK_*



 } output[UREG_MAX_OUTPUT];
 unsigned nr_outputs;

@@ -396,21 +397,25 @@ ureg_DECL_system_value(struct ureg_program *ureg,


  struct ureg_dst
-ureg_DECL_output( struct ureg_program *ureg,
-  unsigned name,
-  unsigned index )
+ureg_DECL_output_masked( struct ureg_program *ureg,
+ unsigned name,
+ unsigned index,
+ unsigned usage_mask )
  {
 unsigned i;


I think we could assert that usage_mask != 0, right?  A while back I 
found a bug in st_glsl_to_tgsi.cpp where we had a writemask=0.  It 
took quite a while to find it so an assertion like this could be good.




 for (i = 0; i  ureg-nr_outputs; i++) {
if (ureg-output[i].semantic_name == name
-  ureg-output[i].semantic_index == index)
+  ureg-output[i].semantic_index == index) {
+ ureg-output[i].usage_mask |= usage_mask;
   goto out;
+  }
 }

 if (ureg-nr_outputs  UREG_MAX_OUTPUT) {
ureg-output[i].semantic_name = name;
ureg-output[i].semantic_index = index;
+  ureg-output[i].usage_mask = usage_mask;
ureg-nr_outputs++;
 }
 else {
@@ -422,6 +427,15 @@ out:
  }


+struct ureg_dst
+ureg_DECL_output( struct ureg_program *ureg,
+  unsigned name,
+  unsigned index )
+{
+   return ureg_DECL_output_masked(ureg, name, index, TGSI_WRITEMASK_XYZW);
+}
+
+
  /* Returns a new constant register.  Keep track of which have been
   * referred to so that we can emit decls later.
   *
@@ -1181,7 +1195,8 @@ emit_decl_semantic(struct ureg_program *ureg,
 unsigned file,
 unsigned index,
 unsigned semantic_name,
-   unsigned semantic_index)
+   unsigned semantic_index,
+   unsigned usage_mask)
  {
 union tgsi_any_token *out = get_tokens(ureg, DOMAIN_DECL, 3);


assert(usage_mask != 0)?



@@ -1189,7 +1204,7 @@ emit_decl_semantic(struct ureg_program *ureg,
 out[0].decl.Type = TGSI_TOKEN_TYPE_DECLARATION;
 out[0].decl.NrTokens = 3;
 out[0].decl.File = file;
-   out[0].decl.UsageMask = TGSI_WRITEMASK_XYZW; /* FIXME! */
+   out[0].decl.UsageMask = usage_mask;
 out[0].decl.Semantic = 1;

 out[1].value = 0;
@@ -1427,7 +1442,8 @@ static void emit_decls( struct ureg_program *ureg )
  TGSI_FILE_INPUT,
  ureg-gs_input[i].index,
  ureg-gs_input[i].semantic_name,
-ureg-gs_input[i].semantic_index);
+ureg-gs_input[i].semantic_index,
+TGSI_WRITEMASK_XYZW);
}
 }

@@ -1436,7 +1452,8 @@ static void emit_decls( struct ureg_program *ureg )
   TGSI_FILE_SYSTEM_VALUE,
   ureg-system_value[i].index,
   

Re: [Mesa-dev] [PATCH] gallium: remove PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_ATTRIBS

[Brian Paul]

On 12/17/2011 01:09 PM, Marek Olšák wrote:

It's the same as PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS.
---
  src/gallium/drivers/nvc0/nvc0_screen.c |2 --
  src/gallium/drivers/r300/r300_screen.c |1 -
  src/gallium/drivers/r600/r600_pipe.c   |1 -
  src/gallium/include/pipe/p_defines.h   |1 -
  src/mesa/state_tracker/st_extensions.c |2 +-
  5 files changed, 1 insertions(+), 6 deletions(-)




Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)

[Adam Jackson]

On Mon, 2011-12-19 at 09:40 +, Dave Airlie wrote:
 On Wed, Dec 7, 2011 at 6:32 PM, Eric Anholt e...@anholt.net wrote:
  On Wed,  7 Dec 2011 10:24:09 +, Dave Airlie airl...@gmail.com wrote:
  From: Dave Airlie airl...@redhat.com
 
  This keeps track of the creation process and stores a drawable type,
  it then blocks DRI2 from getting called if the drawable is a pixmap.
 
  v2: check if we have a GLX drawable, which means we aren't a pbuffer,
  avoid doing flush at all since its meant to be a no-op.
 
  I still think this is the wrong way to go.  As ajax pointed out, there's
  all sorts of races available from trying to guess client-side, and
  there's no way anybody's relying on the current (print an error message
  in the xorg log) behavior of the DRI2 protocol for single-buffered, so
  we might as well resolve that DRI2 protocol should do what we want for
  GLX.
 
 I've been thinking about the races, and I'm not sure they really
 apply, like we would have all those races now with the current code,
 
 Look at the patch, when the glx_drawable struct is created we record
 the type of the pixmap, we then call GetGLXDrawable, which looks the
 XID up in the hash,
 so if the XID has been reused or raced, then we would have to expect
 the hash to be incorrect, or else avoid using it in a lot of other
 places.

True, but we could fix that by moving the UnlockDisplay() to after the
DRI2 stanza (and fixing the called code to not try to take the lock
itself).  There'd still be a race between the GLX and DRI2 requests, in
that someone else could Destroy that which you just created, but that's
a race against an actively malicious client; it would have to be
spamming the server with Destroy requests, since there's no way it can
know what XIDs you're going to pick.

In contrast, trying to track pixmapness like you're doing here races
against at least two app programming techniques that GLX allows and apps
actually use: multiple threads, and XID passing between applications.
In the latter case you'll not have fixed anything: glx_draw will be NULL
because we've not tracked this pixmap since its creation, so we'll carry
on with the DRI request.

The server is the only thing that knows how to handle this scenario, and
it _can_ get this request, so you have to fix it there anyway.  All you
can do in the client is optimize out sending some requests you know will
be no-ops.

But thanks for prompting me to re-read that code, it's less thread-safe
than I remembered.

- ajax


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: DrawTFB should use the vertex count from the last call of EndTFB

[Brian Paul]

On 12/17/2011 06:41 AM, Marek Olšák wrote:

 From ARB_transform_feedback2:
 ... the vertex count used for the rendering operation is
 set by the previous EndTransformFeedback command.
---
  src/mesa/state_tracker/st_cb_xformfb.c |   53 +--
  1 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_xformfb.c 
b/src/mesa/state_tracker/st_cb_xformfb.c
index 2fc28dc..e699fb6 100644
--- a/src/mesa/state_tracker/st_cb_xformfb.c
+++ b/src/mesa/state_tracker/st_cb_xformfb.c
@@ -55,6 +55,11 @@ struct st_transform_feedback_object {

 unsigned num_targets;
 struct pipe_stream_output_target *targets[PIPE_MAX_SO_BUFFERS];
+
+   /* This encapsulates the count that can be used as a source for draw_vbo.
+* It contains a stream output target from the last call of
+* EndTransformFeedback. */
+   struct pipe_stream_output_target *draw_count;
  };


@@ -81,6 +86,8 @@ st_delete_transform_feedback(struct gl_context *ctx,
   (struct st_transform_feedback_object*)obj;
 unsigned i;

+   pipe_so_target_reference(sobj-draw_count, NULL);
+
 /* Unreference targets. */
 for (i = 0; i  sobj-num_targets; i++) {
pipe_so_target_reference(sobj-targets[i], NULL);
@@ -115,6 +122,7 @@ st_begin_transform_feedback(struct gl_context *ctx, GLenum 
mode,
if (bo) {
   /* Check whether we need to recreate the target. */
   if (!sobj-targets[i] ||
+ sobj-targets[i] == sobj-draw_count ||
   sobj-targets[i]-buffer != bo-buffer ||
   sobj-targets[i]-buffer_offset != sobj-base.Offset[i] ||
   sobj-targets[i]-buffer_size != sobj-base.Size[i]) {
@@ -141,7 +149,7 @@ st_begin_transform_feedback(struct gl_context *ctx, GLenum 
mode,


  static void
-st_stop_transform_feedback(struct gl_context *ctx,
+st_pause_transform_feedback(struct gl_context *ctx,
 struct gl_transform_feedback_object *obj)
  {
 struct st_context *st = st_context(ctx);
@@ -161,11 +169,9 @@ st_resume_transform_feedback(struct gl_context *ctx,
~0);
  }

-/* Set count_from_stream_output to any stream output target
- * from the transform feedback object. */
-void
-st_transform_feedback_draw_init(struct gl_transform_feedback_object *obj,
-struct pipe_draw_info *out)
+
+static struct pipe_stream_output_target *
+st_transform_feedback_get_draw_target(struct gl_transform_feedback_object *obj)
  {
 struct st_transform_feedback_object *sobj =
   (struct st_transform_feedback_object*)obj;
@@ -173,13 +179,38 @@ st_transform_feedback_draw_init(struct 
gl_transform_feedback_object *obj,

 for (i = 0; i  Elements(sobj-targets); i++) {
if (sobj-targets[i]) {
- out-count_from_stream_output = sobj-targets[i];
- return;
+ return sobj-targets[i];
}
 }

 assert(0);
-   out-count_from_stream_output = NULL;
+   return NULL;
+}
+
+
+static void
+st_end_transform_feedback(struct gl_context *ctx,
+  struct gl_transform_feedback_object *obj)
+{
+   struct st_context *st = st_context(ctx);
+   struct st_transform_feedback_object *sobj =
+ (struct st_transform_feedback_object*)obj;
+
+   cso_set_stream_outputs(st-cso_context, 0, NULL, 0);
+
+   pipe_so_target_reference(sobj-draw_count,
+st_transform_feedback_get_draw_target(obj));
+}
+
+
+void
+st_transform_feedback_draw_init(struct gl_transform_feedback_object *obj,
+struct pipe_draw_info *out)
+{
+   struct st_transform_feedback_object *sobj =
+ (struct st_transform_feedback_object*)obj;
+
+   out-count_from_stream_output = sobj-draw_count;
  }


Minor nit: instead of using casts for st_transform_feedback_object, 
define a cast wrapper as we do for other types:


static INLINE struct st_transform_feedback_object *
st_transform_feedback_object(struct gl_transform_feedback_object *obj)
{
   return (struct st_transform_feedback_object *) obj;
}


Looks good otherwise.




@@ -189,8 +220,8 @@ st_init_xformfb_functions(struct dd_function_table 
*functions)
 functions-NewTransformFeedback = st_new_transform_feedback;
 functions-DeleteTransformFeedback = st_delete_transform_feedback;
 functions-BeginTransformFeedback = st_begin_transform_feedback;
-   functions-EndTransformFeedback = st_stop_transform_feedback;
-   functions-PauseTransformFeedback = st_stop_transform_feedback;
+   functions-EndTransformFeedback = st_end_transform_feedback;
+   functions-PauseTransformFeedback = st_pause_transform_feedback;
 functions-ResumeTransformFeedback = st_resume_transform_feedback;
  }



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965 gen6: Implement rasterizer discard.

[Paul Berry]

On 16 December 2011 19:53, Kenneth Graunke kenn...@whitecape.org wrote:

 On 12/14/2011 11:59 AM, Paul Berry wrote:
  This patch enables rasterizer discard functionality (a part of
  transform feedback) in Gen6, by generating an alternate GS program
  when rasterizer discard is active.  Instead of forwarding vertices
  down the pipeline, the alternate GS program uses a URB Write message
  to deallocate the URB entry that was allocated by FF sync and
  terminate the thread.
 
  Note: parts of the Sandy Bridge PRM seem to imply that we could do
  this more efficiently, by clearing the GEN6_GS_RENDERING_ENABLE bit,
  and not allocating a URB entry at all.  However, it's not clear how we
  are supposed to terminate the thread if we do that.  Volume 2 part 1,
  section 4.5.4, says GS threads must terminate by sending a URB_WRITE
  message with the EOT and Complete bits set., and my experiments so
  far confirm that.
  ---
 
  This patch needs to be applied on top of the series [PATCH 0/8] i965
  gen6: Initial implementation of transform feedback., which is still
  under review on the mailing list.

 Assuming the dirty bit gets sorted out,
 Reviewed-by: Kenneth Graunke kenn...@whitecape.org


Thanks, Ken.  Fortunately, this patch is independent of the dirty bit stuff
(since this patch adds a use of ctx-TransformFeedback.RasterDiscard to
brw_gs_prog, which already depends on _NEW_TRANSFORM).  So I'll push it as
soon as the remaining discussion on my main transform feedback series is
resolved.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/mesa: use SINT/UINT formats for VertexAttribIPointer

[Christoph Bumiller]

---
 src/mesa/state_tracker/st_draw.c  |   63 +++--
 src/mesa/state_tracker/st_draw.h  |2 +-
 src/mesa/state_tracker/st_draw_feedback.c |3 +-
 3 files changed, 62 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 87a9978..e8a7fe3 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -102,6 +102,13 @@ static GLuint uint_types_scale[4] = {
PIPE_FORMAT_R32G32B32A32_USCALED
 };
 
+static GLuint uint_types_int[4] = {
+   PIPE_FORMAT_R32_UINT,
+   PIPE_FORMAT_R32G32_UINT,
+   PIPE_FORMAT_R32G32B32_UINT,
+   PIPE_FORMAT_R32G32B32A32_UINT
+};
+
 static GLuint int_types_norm[4] = {
PIPE_FORMAT_R32_SNORM,
PIPE_FORMAT_R32G32_SNORM,
@@ -116,6 +123,13 @@ static GLuint int_types_scale[4] = {
PIPE_FORMAT_R32G32B32A32_SSCALED
 };
 
+static GLuint int_types_int[4] = {
+   PIPE_FORMAT_R32_SINT,
+   PIPE_FORMAT_R32G32_SINT,
+   PIPE_FORMAT_R32G32B32_SINT,
+   PIPE_FORMAT_R32G32B32A32_SINT
+};
+
 static GLuint ushort_types_norm[4] = {
PIPE_FORMAT_R16_UNORM,
PIPE_FORMAT_R16G16_UNORM,
@@ -130,6 +144,13 @@ static GLuint ushort_types_scale[4] = {
PIPE_FORMAT_R16G16B16A16_USCALED
 };
 
+static GLuint ushort_types_int[4] = {
+   PIPE_FORMAT_R16_UINT,
+   PIPE_FORMAT_R16G16_UINT,
+   PIPE_FORMAT_R16G16B16_UINT,
+   PIPE_FORMAT_R16G16B16A16_UINT
+};
+
 static GLuint short_types_norm[4] = {
PIPE_FORMAT_R16_SNORM,
PIPE_FORMAT_R16G16_SNORM,
@@ -144,6 +165,13 @@ static GLuint short_types_scale[4] = {
PIPE_FORMAT_R16G16B16A16_SSCALED
 };
 
+static GLuint short_types_int[4] = {
+   PIPE_FORMAT_R16_SINT,
+   PIPE_FORMAT_R16G16_SINT,
+   PIPE_FORMAT_R16G16B16_SINT,
+   PIPE_FORMAT_R16G16B16A16_SINT
+};
+
 static GLuint ubyte_types_norm[4] = {
PIPE_FORMAT_R8_UNORM,
PIPE_FORMAT_R8G8_UNORM,
@@ -158,6 +186,13 @@ static GLuint ubyte_types_scale[4] = {
PIPE_FORMAT_R8G8B8A8_USCALED
 };
 
+static GLuint ubyte_types_int[4] = {
+   PIPE_FORMAT_R8_UINT,
+   PIPE_FORMAT_R8G8_UINT,
+   PIPE_FORMAT_R8G8B8_UINT,
+   PIPE_FORMAT_R8G8B8A8_UINT
+};
+
 static GLuint byte_types_norm[4] = {
PIPE_FORMAT_R8_SNORM,
PIPE_FORMAT_R8G8_SNORM,
@@ -172,6 +207,13 @@ static GLuint byte_types_scale[4] = {
PIPE_FORMAT_R8G8B8A8_SSCALED
 };
 
+static GLuint byte_types_int[4] = {
+   PIPE_FORMAT_R8_SINT,
+   PIPE_FORMAT_R8G8_SINT,
+   PIPE_FORMAT_R8G8B8_SINT,
+   PIPE_FORMAT_R8G8B8A8_SINT
+};
+
 static GLuint fixed_types[4] = {
PIPE_FORMAT_R32_FIXED,
PIPE_FORMAT_R32G32_FIXED,
@@ -186,7 +228,7 @@ static GLuint fixed_types[4] = {
  */
 enum pipe_format
 st_pipe_vertex_format(GLenum type, GLuint size, GLenum format,
-  GLboolean normalized)
+  GLboolean normalized, GLboolean integer)
 {
assert((type = GL_BYTE  type = GL_DOUBLE) ||
   type == GL_FIXED || type == GL_HALF_FLOAT ||
@@ -234,7 +276,18 @@ st_pipe_vertex_format(GLenum type, GLuint size, GLenum 
format,
   return PIPE_FORMAT_B8G8R8A8_UNORM;
}
 
-   if (normalized) {
+   if (integer) {
+  switch (type) {
+  case GL_INT: return int_types_int[size-1];
+  case GL_SHORT: return short_types_int[size-1];
+  case GL_BYTE: return byte_types_int[size-1];
+  case GL_UNSIGNED_INT: return uint_types_int[size-1];
+  case GL_UNSIGNED_SHORT: return ushort_types_int[size-1];
+  case GL_UNSIGNED_BYTE: return ubyte_types_int[size-1];
+  default: assert(0); return 0;
+  }
+   }
+   else if (normalized) {
   switch (type) {
   case GL_DOUBLE: return double_types[size-1];
   case GL_FLOAT: return float_types[size-1];
@@ -407,7 +460,8 @@ setup_interleaved_attribs(struct gl_context *ctx,
   velements[attr].src_format = st_pipe_vertex_format(array-Type,
  array-Size,
  array-Format,
- array-Normalized);
+ array-Normalized,
+array-Integer);
   assert(velements[attr].src_format);
 
   if (!usingVBO) {
@@ -564,7 +618,8 @@ setup_non_interleaved_attribs(struct gl_context *ctx,
   velements[attr].src_format = st_pipe_vertex_format(array-Type,
  array-Size,
  array-Format,
- array-Normalized);
+ array-Normalized,
+ array-Integer);
   assert(velements[attr].src_format);
}
 
diff --git a/src/mesa/state_tracker/st_draw.h b/src/mesa/state_tracker/st_draw.h
index 2623cdb..47bdb11 100644
--- a/src/mesa/state_tracker/st_draw.h
+++ 

[Mesa-dev] [PATCH] vl: Use pipe clear_render_target instead of util_clear_render_target

[Maarten Lankhorst]

Mapping to software and uploading again clearing is killing performance.

Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
 src/gallium/auxiliary/vl/vl_compositor.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index 85507ba..1bdd775 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -1002,8 +1002,8 @@ vl_compositor_render(struct vl_compositor   *c,
if (dirty_area  (dirty_area-x0  dirty_area-x1 ||
   dirty_area-y0  dirty_area-y1)) {
 
-  util_clear_render_target(c-pipe, dst_surface, c-clear_color,
-   0, 0, dst_surface-width, dst_surface-height);
+  c-pipe-clear_render_target(c-pipe, dst_surface, c-clear_color,
+   0, 0, dst_surface-width, 
dst_surface-height);
   dirty_area-x0 = dirty_area-y0 = MAX_DIRTY;
   dirty_area-x0 = dirty_area-y1 = MIN_DIRTY;
}


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)

[Michel Dänzer]

On Mon, 2011-12-19 at 10:14 -0500, Adam Jackson wrote: 
 On Mon, 2011-12-19 at 09:40 +, Dave Airlie wrote:
  On Wed, Dec 7, 2011 at 6:32 PM, Eric Anholt e...@anholt.net wrote:
   On Wed,  7 Dec 2011 10:24:09 +, Dave Airlie airl...@gmail.com wrote:
   From: Dave Airlie airl...@redhat.com
  
   This keeps track of the creation process and stores a drawable type,
   it then blocks DRI2 from getting called if the drawable is a pixmap.
  
   v2: check if we have a GLX drawable, which means we aren't a pbuffer,
   avoid doing flush at all since its meant to be a no-op.
  
   I still think this is the wrong way to go.  As ajax pointed out, there's
   all sorts of races available from trying to guess client-side, and
   there's no way anybody's relying on the current (print an error message
   in the xorg log) behavior of the DRI2 protocol for single-buffered, so
   we might as well resolve that DRI2 protocol should do what we want for
   GLX.
  
  I've been thinking about the races, and I'm not sure they really
  apply, like we would have all those races now with the current code,
  
  Look at the patch, when the glx_drawable struct is created we record
  the type of the pixmap, we then call GetGLXDrawable, which looks the
  XID up in the hash,
  so if the XID has been reused or raced, then we would have to expect
  the hash to be incorrect, or else avoid using it in a lot of other
  places.
 
 True, but we could fix that by moving the UnlockDisplay() to after the
 DRI2 stanza (and fixing the called code to not try to take the lock
 itself).  There'd still be a race between the GLX and DRI2 requests, in
 that someone else could Destroy that which you just created, but that's
 a race against an actively malicious client; it would have to be
 spamming the server with Destroy requests, since there's no way it can
 know what XIDs you're going to pick.
 
 In contrast, trying to track pixmapness like you're doing here races
 against at least two app programming techniques that GLX allows and apps
 actually use: multiple threads, and XID passing between applications.
 In the latter case you'll not have fixed anything: glx_draw will be NULL
 because we've not tracked this pixmap since its creation, so we'll carry
 on with the DRI request.
 
 The server is the only thing that knows how to handle this scenario, and
 it _can_ get this request, so you have to fix it there anyway.

Actually no, the DRI2 code in the server can't know, as this is a
perfectly legitimate request for a GLXPbuffer.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] vertex array regression

[Brian Paul]

On 12/16/2011 11:28 AM, Mathias Fröhlich wrote:


Brian,

On Thursday, December 15, 2011 22:36:24 you wrote:

I found the problem.  It's this chunk in vbo_context.c:

[...]

For fixed function, the point is to simply place the per-vertex
material attributes in the generic attribute arrays.  There are 12
such material attributes.  So there's four slots left over.


Yep, and these map with the old scheme to often used attributes like the
vertex position.


I still don't get what the purpose of the special mapping of the last 
four/five elements is all about.  Can you explain that?





Thanks to your hints I believe that I found the underlying problem:

If you look at the resulting bitmasks for the enabled vertex program inputs in
isosurf by commenting out the printf in _mesa_set_varying_vp_inputs you will
see surprising results with the old numbering. The current checked in
numbering looks much more plausible.
It turns out that this wrong varying_vp_inputs mask sets the _NEW_ARRAY bit
through _mesa_set_varying_vp_inputs. That in turn cares for some (by now in my
debug session untracked) state updates. This helps in the end for isosurf.
If the varying_vp_inputs mask looks plausible the _NEW_ARRAY bit is not set
and isosurf fails.

This also explaines that only draw paths going through vbo_exec_array.c are
affected, since the imm variants in vbo_exec_{safe,draw} always set the
_NEW_ARRAY bit on any draw.


Yeah, I see how the incorrect varying_inputs values was causing 
_NEW_ARRAY to get set, thus hiding the problem.  The solution looks 
correct, but I'm a little worried about performance, as is mentioned 
in the comment.


Marek, made that change back in March.  Maybe he can take a look at 
this too.





So for me this change

diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index a6e41e9..a2851c4 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -446,7 +446,7 @@ recalculate_input_bindings(struct gl_context *ctx)
 * to revalidate vertex arrays. Not marking the state as dirty also
 * improves performance (quite significantly in some apps).
 */
-  if (!ctx-VertexProgram._MaintainTnlProgram)
+  /* if (!ctx-VertexProgram._MaintainTnlProgram) */
   ctx-NewState |= _NEW_ARRAY;
break;

makes isosurf work reliable.

I will prepare a patch for that.

Greetings

Mathias


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] gallium/draw: fix two side handling

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

The previous fix linked the vertex/fragment shader handling in softpipe for
the unspecified front color output case, but specified back color case.

However in that case we were doing a copy from back to non-existant front,
this code checks we have existant front/backs and only does the copy when
they both exist.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/gallium/auxiliary/draw/draw_pipe_twoside.c |   27 
 1 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_twoside.c 
b/src/gallium/auxiliary/draw/draw_pipe_twoside.c
index 9a3f3fe..b1a70a0 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_twoside.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_twoside.c
@@ -38,8 +38,8 @@
 struct twoside_stage {
struct draw_stage stage;
float sign; /** +1 or -1 */
-   uint attrib_front0, attrib_back0;
-   uint attrib_front1, attrib_back1;
+   int attrib_front0, attrib_back0;
+   int attrib_front1, attrib_back1;
 };
 
 
@@ -48,9 +48,6 @@ static INLINE struct twoside_stage *twoside_stage( struct 
draw_stage *stage )
return (struct twoside_stage *)stage;
 }
 
-
-
-
 /**
  * Copy back color(s) to front color(s).
  */
@@ -60,12 +57,12 @@ copy_bfc( struct twoside_stage *twoside,
   unsigned idx )
 {   
struct vertex_header *tmp = dup_vert( twoside-stage, v, idx );
-   
-   if (twoside-attrib_back0) {
+
+   if (twoside-attrib_back0 = 0  twoside-attrib_front0 = 0) {
   COPY_4FV(tmp-data[twoside-attrib_front0],
tmp-data[twoside-attrib_back0]);
}
-   if (twoside-attrib_back1) {
+   if (twoside-attrib_back1 = 0  twoside-attrib_front1 = 0) {
   COPY_4FV(tmp-data[twoside-attrib_front1],
tmp-data[twoside-attrib_back1]);
}
@@ -109,10 +106,10 @@ static void twoside_first_tri( struct draw_stage *stage,
const struct draw_vertex_shader *vs = stage-draw-vs.vertex_shader;
uint i;
 
-   twoside-attrib_front0 = 0;
-   twoside-attrib_front1 = 0;
-   twoside-attrib_back0 = 0;
-   twoside-attrib_back1 = 0;
+   twoside-attrib_front0 = -1;
+   twoside-attrib_front1 = -1;
+   twoside-attrib_back0 = -1;
+   twoside-attrib_back1 = -1;
 
/* Find which vertex shader outputs are front/back colors */
for (i = 0; i  vs-info.num_outputs; i++) {
@@ -130,12 +127,6 @@ static void twoside_first_tri( struct draw_stage *stage,
   }
}
 
-   if (!twoside-attrib_back0)
-  twoside-attrib_front0 = 0;
-
-   if (!twoside-attrib_back1)
-  twoside-attrib_front1 = 0;
-
/*
 * We'll multiply the primitive's determinant by this sign to determine
 * if the triangle is back-facing (negative).
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] softpipe two sided fixes

[Dave Airlie]

These two patches fix 13 piglit tests in softpipe, GL2 vertex-program-two-side
and glsl-1.10 interpolation tests.

I'm not 100% sure that my fixes are the correct way to fix the problem,
but I'd probably need some direction if someone knows better, I'm not entirely
happy that the fix is in two places, but I'm not really sure where the best
place to pick between front/back is, and it might be nice to avoid the copying
completely.

Dave.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

In the case where a front and back output are specified, the draw code will
copy the back output into the front color slot and everything is happy.

However if no front is specified then the draw code will do a bad copy 
(separate patch), but also the frag shader won't pick up the color as there 
there is
no write to COLOR from the vertex shader just BCOLOR.

This patch fixes that problem so if it can't find a vertex shader output
for the front color slot, it will go and lookup and use one for the back color
slot.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/gallium/drivers/softpipe/sp_state_derived.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c 
b/src/gallium/drivers/softpipe/sp_state_derived.c
index f89d23c..5685997 100644
--- a/src/gallium/drivers/softpipe/sp_state_derived.c
+++ b/src/gallium/drivers/softpipe/sp_state_derived.c
@@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context *softpipe)
  src = draw_find_shader_output(softpipe-draw,
fsInfo-input_semantic_name[i],
fsInfo-input_semantic_index[i]);
+if (fsInfo-input_semantic_name[i] == TGSI_SEMANTIC_COLOR  src == 0)
+  /* try and find a bcolor */
+  src = draw_find_shader_output(softpipe-draw,
+TGSI_SEMANTIC_BCOLOR, 
fsInfo-input_semantic_index[i]);
+
  draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src);
   }
 
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] tgsi: update documents with some info on texture lookup

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

this mentions which channels are used for slice and depth comparison values.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 src/gallium/docs/source/tgsi.rst |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index d7f50b1..45af528 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -585,6 +585,17 @@ This instruction replicates its result.
 
   dst = texture_sample(unit, coord, bias)
 
+  for array textures src0.y contains the slice for 1D,
+  and src0.z contain the slice for 2D.
+  for shadow textures with no arrays, src0.z contains
+  the reference value.
+  for shadow textures with arrays, src0.z contains
+  the reference value for 1D arrays, and src0.w contains
+  the reference value for 2D arrays.
+  There is no way to pass a bias in the .w value for
+  shadow arrays, and GLSL doesn't allow this.
+  GLSL does allow cube shadows maps to take a bias value,
+  and we have to determine how this will look in TGSI.
 
 .. opcode:: TXD - Texture Lookup with Derivatives
 
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] softpipe: fix shadow1d tests.

[Dave Airlie]

 That looks better.  Would you mind checking that the TGSI docs properly
 describe which coordinate components are used for array indexing, shadow
 distance, etc.

I've sent a tgsi doc update, not really sure how we plan on handling,

float texture (samplerCubeShadow sampler, vec4 P [, float bias] )

from GLSL, but that isn't a problem I'm looking at now, I was just
trying to make softpipe pass as many tests as possible for GL2.1, out
of idle curiosity.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] softpipe color interpolation

[Dave Airlie]

Hi guys,

So we have some piglit tests
generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test
that piglit fails

This seems to be due to its linear interpolation not producing the
correct answers compared to the hardware, on the rendered triangle,
there is a obvious circle of darkness that isn't there on hw rendered.

Looking at tri_linear_coeff I notice a large comment explaining that
this could be done better, llvmpipe also uses the same code, is this
what is causing the fail?

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx: block attempt to swapbuffer on pixmap. (v2)

[Adam Jackson]

On Mon, 2011-12-19 at 16:45 +0100, Michel Dänzer wrote:
 On Mon, 2011-12-19 at 10:14 -0500, Adam Jackson wrote: 

  The server is the only thing that knows how to handle this scenario, and
  it _can_ get this request, so you have to fix it there anyway.
 
 Actually no, the DRI2 code in the server can't know, as this is a
 perfectly legitimate request for a GLXPbuffer.

Only as an artifact of how we implement pbuffers (which is,
stylistically, a disaster).  And even then I don't think that's true,
just that the implementation would be unpleasant.  xserver gets
DRI2SwapBuffers on an XID for an X pixmap.  It can either be backing a
GLXPixmap or a GLXPbuffer, but not both*.  Therefore DRI2 needs to wrap
the glx drawable create path in the server, and stash a note on the
PixmapRec private for the GLXPixmap and GLXPbuffer cases.  That way
SwapBuffers has type information without needing to walk all GLXPixmaps
looking for an XID match with the backing pixmap.

This works because Pixmaps have to be created before GLXPixmaps, but the
backing pixmap for a pbuffer is created after the pbuffer.  So
technically that * above is a lie.  We create the backing pixmap for the
pbuffer inside xlib, and we don't leak that XID outside libGL, but the
client could guess.  The failure cases would be:

a) create pbuffer, guess Pixmap XID, bind a GLXPixmap to it
b) create Pixmap, create GLXPixmap, fabricate your own protocol for
CreatePbuffer and DRI2CreateDrawable to bind to the Pixmap

Both of which are detectable, because they involve calling
DRI2CreateDrawable a second time after you've already inferred type.

Or, better yet, if DRI2 insists on keeping the current weird 'alias'
semantics for DRI2CreateDrawable, it could alias based on the GLX
resource ID.  This would mean moving the creation of the backing pixmap
for pbuffers inside the server, but honestly that's a lot cleaner
anyway.  Among other things, there'd be no possibility of leaking an XID
to the client for the backing resource.

- ajax


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] tgsi: update documents with some info on texture lookup

[Brian Paul]

On 12/19/2011 09:40 AM, Dave Airlie wrote:

From: Dave Airlieairl...@redhat.com

this mentions which channels are used for slice and depth comparison values.

Signed-off-by: Dave Airlieairl...@redhat.com
---
  src/gallium/docs/source/tgsi.rst |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index d7f50b1..45af528 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -585,6 +585,17 @@ This instruction replicates its result.

dst = texture_sample(unit, coord, bias)

+  for array textures src0.y contains the slice for 1D,
+  and src0.z contain the slice for 2D.
+  for shadow textures with no arrays, src0.z contains
+  the reference value.
+  for shadow textures with arrays, src0.z contains
+  the reference value for 1D arrays, and src0.w contains
+  the reference value for 2D arrays.
+  There is no way to pass a bias in the .w value for
+  shadow arrays, and GLSL doesn't allow this.
+  GLSL does allow cube shadows maps to take a bias value,
+  and we have to determine how this will look in TGSI.

  .. opcode:: TXD - Texture Lookup with Derivatives



Thanks!

Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] softpipe color interpolation

[Brian Paul]

On 12/19/2011 10:10 AM, Dave Airlie wrote:

Hi guys,

So we have some piglit tests
generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test
that piglit fails

This seems to be due to its linear interpolation not producing the
correct answers compared to the hardware, on the rendered triangle,
there is a obvious circle of darkness that isn't there on hw rendered.

Looking at tri_linear_coeff I notice a large comment explaining that
this could be done better, llvmpipe also uses the same code, is this
what is causing the fail?


Quite possibly.  It shouldn't be hard to hack softpipe to use 
perspective-corrected color interpolation to see if that helps.


-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] gallium/draw: fix two side handling

[Brian Paul]

On 12/19/2011 09:29 AM, Dave Airlie wrote:

From: Dave Airlieairl...@redhat.com

The previous fix linked the vertex/fragment shader handling in softpipe for
the unspecified front color output case, but specified back color case.

However in that case we were doing a copy from back to non-existant front,
this code checks we have existant front/backs and only does the copy when
they both exist.

Signed-off-by: Dave Airlieairl...@redhat.com
---
  src/gallium/auxiliary/draw/draw_pipe_twoside.c |   27 
  1 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe_twoside.c 
b/src/gallium/auxiliary/draw/draw_pipe_twoside.c
index 9a3f3fe..b1a70a0 100644
--- a/src/gallium/auxiliary/draw/draw_pipe_twoside.c
+++ b/src/gallium/auxiliary/draw/draw_pipe_twoside.c
@@ -38,8 +38,8 @@
  struct twoside_stage {
 struct draw_stage stage;
 float sign; /**  +1 or -1 */
-   uint attrib_front0, attrib_back0;
-   uint attrib_front1, attrib_back1;
+   int attrib_front0, attrib_back0;
+   int attrib_front1, attrib_back1;
  };


@@ -48,9 +48,6 @@ static INLINE struct twoside_stage *twoside_stage( struct 
draw_stage *stage )
 return (struct twoside_stage *)stage;
  }

-
-
-
  /**
   * Copy back color(s) to front color(s).
   */
@@ -60,12 +57,12 @@ copy_bfc( struct twoside_stage *twoside,
unsigned idx )
  {
 struct vertex_header *tmp = dup_vert(twoside-stage, v, idx );
-
-   if (twoside-attrib_back0) {
+
+   if (twoside-attrib_back0= 0  twoside-attrib_front0= 0) {
COPY_4FV(tmp-data[twoside-attrib_front0],
 tmp-data[twoside-attrib_back0]);
 }
-   if (twoside-attrib_back1) {
+   if (twoside-attrib_back1= 0  twoside-attrib_front1= 0) {
COPY_4FV(tmp-data[twoside-attrib_front1],
 tmp-data[twoside-attrib_back1]);
 }
@@ -109,10 +106,10 @@ static void twoside_first_tri( struct draw_stage *stage,
 const struct draw_vertex_shader *vs = stage-draw-vs.vertex_shader;
 uint i;

-   twoside-attrib_front0 = 0;
-   twoside-attrib_front1 = 0;
-   twoside-attrib_back0 = 0;
-   twoside-attrib_back1 = 0;
+   twoside-attrib_front0 = -1;
+   twoside-attrib_front1 = -1;
+   twoside-attrib_back0 = -1;
+   twoside-attrib_back1 = -1;

 /* Find which vertex shader outputs are front/back colors */
 for (i = 0; i  vs-info.num_outputs; i++) {
@@ -130,12 +127,6 @@ static void twoside_first_tri( struct draw_stage *stage,
}
 }

-   if (!twoside-attrib_back0)
-  twoside-attrib_front0 = 0;
-
-   if (!twoside-attrib_back1)
-  twoside-attrib_front1 = 0;
-
 /*
  * We'll multiply the primitive's determinant by this sign to determine
  * if the triangle is back-facing (negative).


This looks like a good fix in general.

Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.

[Brian Paul]

On 12/19/2011 09:29 AM, Dave Airlie wrote:

From: Dave Airlieairl...@redhat.com

In the case where a front and back output are specified, the draw code will
copy the back output into the front color slot and everything is happy.

However if no front is specified then the draw code will do a bad copy 
(separate patch), but also the frag shader won't pick up the color as there 
there is
no write to COLOR from the vertex shader just BCOLOR.

This patch fixes that problem so if it can't find a vertex shader output
for the front color slot, it will go and lookup and use one for the back color
slot.

Signed-off-by: Dave Airlieairl...@redhat.com
---
  src/gallium/drivers/softpipe/sp_state_derived.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c 
b/src/gallium/drivers/softpipe/sp_state_derived.c
index f89d23c..5685997 100644
--- a/src/gallium/drivers/softpipe/sp_state_derived.c
+++ b/src/gallium/drivers/softpipe/sp_state_derived.c
@@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context *softpipe)
   src = draw_find_shader_output(softpipe-draw,
 fsInfo-input_semantic_name[i],
 fsInfo-input_semantic_index[i]);
+if (fsInfo-input_semantic_name[i] == TGSI_SEMANTIC_COLOR  src == 0)
+  /* try and find a bcolor */
+  src = draw_find_shader_output(softpipe-draw,
+TGSI_SEMANTIC_BCOLOR, 
fsInfo-input_semantic_index[i]);
+
   draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src);
}



And if the VS emits neither a front color or back color, what happens?

It seems to me that if the VS doesn't emit a front color and the 
polygon ends up being front-facing, the polygon color is undefined.


Off-hand I don't recall what the GL/GLSL specs say about this.  What 
is the piglit test expecting?


-Brain
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Fix compilation on cygwin after commit 762c9766c93697af8d7fbaa729aed118789dbe8e

[Jon TURNEY]

Fix compilation on cygwin after commit 762c9766c93697af8d7fbaa729aed118789dbe8e
Use VERT_ATTRIB_* indexed array in gl_array_object added the first non-driver
use of ffsll(), which exposes the fact that this isn't provided on cygwin.

Found by tinderbox, see [1]

[1] http://tinderbox.freedesktop.org/builds/2011-11-30-0017/logs/libGL/#build

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
 src/mesa/main/imports.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index 797f357..d5e3859 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -568,7 +568,7 @@ _mesa_init_sqrt_table(void);
 
 #ifdef __GNUC__
 
-#if defined(__MINGW32__) || defined(ANDROID)
+#if defined(__MINGW32__) || defined(__CYGWIN__) || defined(ANDROID)
 #define ffs __builtin_ffs
 #define ffsll __builtin_ffsll
 #endif
-- 
1.7.5.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.

[Dave Airlie]

On Mon, Dec 19, 2011 at 5:39 PM, Brian Paul bri...@vmware.com wrote:
 On 12/19/2011 09:29 AM, Dave Airlie wrote:

 From: Dave Airlieairl...@redhat.com

 In the case where a front and back output are specified, the draw code
 will
 copy the back output into the front color slot and everything is happy.

 However if no front is specified then the draw code will do a bad copy
 (separate patch), but also the frag shader won't pick up the color as there
 there is
 no write to COLOR from the vertex shader just BCOLOR.

 This patch fixes that problem so if it can't find a vertex shader output
 for the front color slot, it will go and lookup and use one for the back
 color
 slot.

 Signed-off-by: Dave Airlieairl...@redhat.com
 ---
  src/gallium/drivers/softpipe/sp_state_derived.c |    5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

 diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c
 b/src/gallium/drivers/softpipe/sp_state_derived.c
 index f89d23c..5685997 100644
 --- a/src/gallium/drivers/softpipe/sp_state_derived.c
 +++ b/src/gallium/drivers/softpipe/sp_state_derived.c
 @@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context
 *softpipe)
           src = draw_find_shader_output(softpipe-draw,
                                         fsInfo-input_semantic_name[i],
                                         fsInfo-input_semantic_index[i]);
 +        if (fsInfo-input_semantic_name[i] == TGSI_SEMANTIC_COLOR  src
 == 0)

 +          /* try and find a bcolor */
 +          src = draw_find_shader_output(softpipe-draw,
 +                                        TGSI_SEMANTIC_BCOLOR,
 fsInfo-input_semantic_index[i]);
 +
           draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src);
        }


 And if the VS emits neither a front color or back color, what happens?

Well the same as happens now, which from what I can see is undefined.
Since if the
VS emits no colors and the FS expects a color, you have a problem, I'm
not sure if the
linker deals with this.

 It seems to me that if the VS doesn't emit a front color and the polygon
 ends up being front-facing, the polygon color is undefined.

Yes the test seems to not care about the value in the front in this case at all,
but maybe Ian or someone with more spec can say what the chapter/verse is.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] softpipe color interpolation

[Christoph Bumiller]

On 19.12.2011 18:10, Dave Airlie wrote:
 Hi guys,

 So we have some piglit tests
 generated_tests/spec/glsl-1.10/execution/interpolation/interpolation-none-gl_FrontColor-smooth-none.shader_test
 that piglit fails

 This seems to be due to its linear interpolation not producing the
 correct answers compared to the hardware, on the rendered triangle,
 there is a obvious circle of darkness that isn't there on hw rendered.

 Looking at tri_linear_coeff I notice a large comment explaining that
 this could be done better, llvmpipe also uses the same code, is this
 what is causing the fail?

I noticed that a while ago, the lighting in a level in nexuiz was
looking weird on nv50, and I discovered it was due to colours using
linear (noperspective) interpolation instead of perspective correct
interpolation, at TGSI's behest.

It looked fine on llvmpipe, because its linear interpolation was more
like the perspective correct interpolation on nv50 ...

We should probably do GL_PERSPECTIVE_CORRECTION_HINT GL_NICEST, as newer
GL versions require anyway, and set the COLOR interpolants to
TGSI_INTERPOLATE_PERSPECTIVE in the state tracker.

For visualization: http://people.freedesktop.org/~chrisbmr/linterp.png
(that's supposed to be noperspective, iirc)

 Dave.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Implement bounds checking for transform feedback output.

[Paul Berry]

On 15 December 2011 15:20, Kenneth Graunke kenn...@whitecape.org wrote:

 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  src/mesa/drivers/dri/i965/brw_context.c |1 +
  src/mesa/drivers/dri/i965/brw_context.h |3 ++
  src/mesa/drivers/dri/i965/brw_gs_emit.c |   10 
  src/mesa/drivers/dri/i965/gen6_sol.c|   38
 +++
  4 files changed, 52 insertions(+), 0 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_context.c
 b/src/mesa/drivers/dri/i965/brw_context.c
 index 7d360b0..fd60853 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.c
 +++ b/src/mesa/drivers/dri/i965/brw_context.c
 @@ -117,6 +117,7 @@ static void brwInitDriverFunctions( struct
 dd_function_table *functions )
brw_init_queryobj_functions(functions);

functions-PrepareExecBegin = brwPrepareExecBegin;
 +   functions-BeginTransformFeedback = brw_begin_transform_feedback;
functions-EndTransformFeedback = brw_end_transform_feedback;
  }

 diff --git a/src/mesa/drivers/dri/i965/brw_context.h
 b/src/mesa/drivers/dri/i965/brw_context.h
 index 8e52488..20623d4 100644
 --- a/src/mesa/drivers/dri/i965/brw_context.h
 +++ b/src/mesa/drivers/dri/i965/brw_context.h
 @@ -1073,6 +1073,9 @@ brw_fprog_uses_noperspective(const struct
 gl_fragment_program *fprog);

  /* gen6_sol.c */
  void
 +brw_begin_transform_feedback(struct gl_context *ctx,
 +struct gl_transform_feedback_object *obj);


Argh, I fail at code review.  I found another problem: this function is
missing the argument GLenum mode, which should come after gl_context
ctx, causing the function pointer assignment in brw_context.c to generate
a warning.  It's a benign warning, because the function only uses the ctx
argument, and the calling conventions work out so that it gets passed in
the same way regardless of whether mode is present.  But for portability we
should make the function signatures match.


 +void
  brw_end_transform_feedback(struct gl_context *ctx,
struct gl_transform_feedback_object *obj);

 diff --git a/src/mesa/drivers/dri/i965/brw_gs_emit.c
 b/src/mesa/drivers/dri/i965/brw_gs_emit.c
 index 72d4eca..5dd3734 100644
 --- a/src/mesa/drivers/dri/i965/brw_gs_emit.c
 +++ b/src/mesa/drivers/dri/i965/brw_gs_emit.c
 @@ -352,6 +352,15 @@ gen6_sol_program(struct brw_gs_compile *c, struct
 brw_gs_prog_key *key,
*/
   brw_MOV(p, get_element_ud(c-reg.header, 5),
   get_element_ud(c-reg.SVBI, 0));
 +
 +  /* Make sure that the buffers have enough room for all the
 vertices. */
 +  brw_ADD(p, get_element_ud(c-reg.temp, 0),
 +get_element_ud(c-reg.SVBI, 0), brw_imm_ud(num_verts));
 +  brw_CMP(p, vec1(brw_null_reg()), BRW_CONDITIONAL_L,
 +get_element_ud(c-reg.temp, 0),
 +get_element_ud(c-reg.SVBI, 4));
 +  brw_IF(p, BRW_EXECUTE_1);
 +
   /* For each vertex, generate code to output each varying using the
* appropriate binding table entry.
*/
 @@ -392,6 +401,7 @@ gen6_sol_program(struct brw_gs_compile *c, struct
 brw_gs_prog_key *key,
 get_element_ud(c-reg.header, 5), brw_imm_ud(1));
  }
   }
 +  brw_ENDIF(p);

   /* Now, reinitialize the header register from R0 to restore the
 parts of
* the register that we overwrote while streaming out transform
 feedback
 diff --git a/src/mesa/drivers/dri/i965/gen6_sol.c
 b/src/mesa/drivers/dri/i965/gen6_sol.c
 index b11bce2..56d4a6a 100644
 --- a/src/mesa/drivers/dri/i965/gen6_sol.c
 +++ b/src/mesa/drivers/dri/i965/gen6_sol.c
 @@ -26,6 +26,7 @@
  * Code to initialize the binding table entries used by transform feedback.
  */

 +#include main/macros.h
  #include brw_context.h
  #include intel_buffer_objects.h
  #include intel_batchbuffer.h
 @@ -101,6 +102,43 @@ const struct brw_tracked_state gen6_sol_surface = {
  };

  void
 +brw_begin_transform_feedback(struct gl_context *ctx,
 +struct gl_transform_feedback_object *obj)
 +{
 +   struct intel_context *intel = intel_context(ctx);
 +   const struct gl_shader_program *vs_prog =
 +  ctx-Shader.CurrentVertexProgram;
 +   const struct gl_transform_feedback_info *linked_xfb_info =
 +  vs_prog-LinkedTransformFeedback;
 +   struct gl_transform_feedback_object *xfb_obj =
 +  ctx-TransformFeedback.CurrentObject;
 +
 +   unsigned max_index = 0x;
 +
 +   /* Compute the maximum number of vertices that we can write without
 +* overflowing any of the buffers currently being used for feedback.
 +*/
 +   for (int i = 0; i  MAX_FEEDBACK_ATTRIBS; ++i) {
 +  unsigned stride = linked_xfb_info-BufferStride[i];
 +
 +  /* Skip any inactive buffers, which have a stride of 0. */
 +  if (stride == 0)
 +continue;
 +
 +  unsigned max_for_this_buffer = xfb_obj-Size[i] / (4 * stride);
 +  max_index = MIN2(max_index, max_for_this_buffer);
 +   }
 +
 +   /* Initialize the SVBI 0 register 

[Mesa-dev] Willing to take Haiku support Patches? (Was: DEATH to old drivers!)

[Alexander von Gluck]

Good afternoon!

The Haiku OS project (not-for-profit organization, founded in 2001) has
found ourselves in a weird spot, we have a working Mesa software
render library based on a *heavily* modified Mesa 7.4.4.

http://cgit.haiku-os.org/haiku/tree/src/libs/mesa

However as you can imagine, updating that is going to be a *big*
pain point.  As Haiku is looking to get some basic 3D rendering
going on it's cards, we need to do upgrade to a newer version of
Mesa.

If we produced well thought out Haiku OS support patches, would
Mesa as a project be interested in accepting them upstream? I think
a better direction may be to move away from the heavily custom
integrated mesa library and move to stock version.

These patches would likely start as run-of-the-mill #ifdef __HAIKU__
macros.

As Haiku has a much smaller developer base then Mesa (20-30 commiters)
these first steps would greatly assist us in getting hardware assisted
3d acceleration going.

Keep in mind this is all early analysis, I haven't tried porting 7.11.2
yet :)

Thanks!
 -- Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: Don't minify depth when setting up cube map miptrees on Gen4.

[Kenneth Graunke]

Prior to Ironlake, cube maps were stored as 3D textures.  In recent
refactoring, we removed a separate layers parameter in favor of using
depth.  Unfortunately, depth was getting minified, which is only correct
for actual 3D textures.

Fixes piglit tests:
- bugs/crash-cubemap-order
- fbo/fbo-cubemap
- texturing/cubemap

Also changes texturing/cubemap npot from abort to fail.

This hasn't seen a full test run since Piglit on Mesa master hangs
GM45 a lot.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_tex_layout.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c 
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index eaea49b..4c7e88c 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -124,7 +124,8 @@ brw_miptree_layout(struct intel_context *intel, struct 
intel_mipmap_tree *mt)
 mt-total_height += y;
 width  = minify(width);
 height = minify(height);
-depth  = minify(depth);
+if (mt-target == GL_TEXTURE_3D)
+   depth = minify(depth);
 
 if (mt-compressed) {
pack_y_pitch = (height + 3) / 4;
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Willing to take Haiku support Patches? (Was: DEATH to old drivers!)

[Brian Paul]

On Mon, Dec 19, 2011 at 11:18 AM, Alexander von Gluck
kallis...@unixzen.com wrote:
 Good afternoon!

 The Haiku OS project (not-for-profit organization, founded in 2001) has
 found ourselves in a weird spot, we have a working Mesa software
 render library based on a *heavily* modified Mesa 7.4.4.

 http://cgit.haiku-os.org/haiku/tree/src/libs/mesa

 However as you can imagine, updating that is going to be a *big*
 pain point.  As Haiku is looking to get some basic 3D rendering
 going on it's cards, we need to do upgrade to a newer version of
 Mesa.

 If we produced well thought out Haiku OS support patches, would
 Mesa as a project be interested in accepting them upstream? I think
 a better direction may be to move away from the heavily custom
 integrated mesa library and move to stock version.

 These patches would likely start as run-of-the-mill #ifdef __HAIKU__
 macros.

 As Haiku has a much smaller developer base then Mesa (20-30 commiters)
 these first steps would greatly assist us in getting hardware assisted
 3d acceleration going.

 Keep in mind this is all early analysis, I haven't tried porting 7.11.2
 yet :)

In general I'm happy to take patches for Haiku.  But I wouldn't want
to see #ifdef __HAIKU__ lines scattered all over the code.  Hopefully,
that can be limited to header files as with other platforms.

What GPUs/cards do you need to support?  Does this involve restoring
any legacy drivers that were removed a few weeks ago?  Could you move
to Gallium-based drivers?

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Fix compilation on cygwin after commit 762c9766c93697af8d7fbaa729aed118789dbe8e

[Brian Paul]

On 12/19/2011 10:45 AM, Jon TURNEY wrote:

Fix compilation on cygwin after commit 762c9766c93697af8d7fbaa729aed118789dbe8e
Use VERT_ATTRIB_* indexed array in gl_array_object added the first non-driver
use of ffsll(), which exposes the fact that this isn't provided on cygwin.

Found by tinderbox, see [1]

[1] http://tinderbox.freedesktop.org/builds/2011-11-30-0017/logs/libGL/#build

Signed-off-by: Jon TURNEYjon.tur...@dronecode.org.uk
---
  src/mesa/main/imports.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index 797f357..d5e3859 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -568,7 +568,7 @@ _mesa_init_sqrt_table(void);

  #ifdef __GNUC__

-#if defined(__MINGW32__) || defined(ANDROID)
+#if defined(__MINGW32__) || defined(__CYGWIN__) || defined(ANDROID)
  #define ffs __builtin_ffs
  #define ffsll __builtin_ffsll
  #endif


LGTM.


Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/8] i965 gen6: Initial implementation of transform feedback.

[Paul Berry]

On 17 December 2011 11:50, Eric Anholt e...@anholt.net wrote:

 On Tue, 13 Dec 2011 15:35:18 -0800, Paul Berry stereotype...@gmail.com
 wrote:
  diff --git a/src/mesa/drivers/dri/i965/brw_gs.c
 b/src/mesa/drivers/dri/i965/brw_gs.c
  index f5d5898..c323a73 100644
  --- a/src/mesa/drivers/dri/i965/brw_gs.c
  +++ b/src/mesa/drivers/dri/i965/brw_gs.c
  @@ -183,7 +183,31 @@ static void populate_key( struct brw_context *brw,
  } else if (intel-gen == 6) {
 /* On Gen6, GS is used for transform feedback. */
 /* _NEW_TRANSFORM_FEEDBACK */
  -  key-need_gs_prog = ctx-TransformFeedback.CurrentObject-Active;
  +  if (ctx-TransformFeedback.CurrentObject-Active) {
  + const struct gl_shader_program *shaderprog =
  +ctx-Shader.CurrentVertexProgram;
  + const struct gl_transform_feedback_info *linked_xfb_info =
  +shaderprog-LinkedTransformFeedback;
  + int i;
  +
  + /* Make sure that the VUE slots won't overflow the unsigned
 chars in
  +  * key-transform_feedback_bindings[].
  +  */
  + assert (BRW_VERT_RESULT_MAX = 256);

 We generally don't put a space between assert and the opening paren.


I prefer to put a space before the opening paren to highlight whenever the
thing I am doing is not a function call, as a reminder that flow control or
argument evaluation may not be as expected--we follow this convention
fairly consistently in i965 for if, for, switch, and while.  I think we
should do it for assert as well, since assert has both flow control
implications (it may abort) and argument evaluation implications (it won't
evaluate its argument under non-debug builds).



 Also, this assert is really weird to me.  Neither of the two fields in
 the key are related to 256 -- there's a 7-bit field, and a
 BRW_MAX_SOL_BINDINGS field.  (Also, for compile-time checks like this,
 we now have STATIC_ASSERT.  Hooray!)


The BRW_MAX_SOL_BINDINGS field (key-transform_feedback_bindings[]) is
related to 256 because it's an array of unsigned chars.  Each entry in the
array of unsigned chars stores a gl_vert_result, so the assertion is to
make sure that all possible gl_vert_result values can fit in an unsigned
char without overflow.  In retrospect, the assertion should read
(VERT_RESULT_MAX = 256), since the brw-specific extensions to
gl_vert_result will never appear in key-transform_feedback_bindings[].
I'll fix that and change the assertion to a STATIC_ASSERT.



  @@ -107,12 +119,27 @@ static void brw_gs_overwrite_header_dw2(struct
 brw_gs_compile *c,
* of DWORD 2.  URB_WRITE messages need the primitive type in bits 6:2
 of
* DWORD 2.  So this function extracts the primitive type field,
 bitshifts it
* appropriately, and stores it in c-reg.header.
  + *
  + * Also, if num_verts is 3, it converts primitive type
  + * _3DPRIM_TRISTRIP_REVERSE to _3DPRIM_TRISTRIP, so that odd numbered
  + * triangles in a triangle strip will render correctly.
*/
  -static void brw_gs_overwrite_header_dw2_from_r0(struct brw_gs_compile
 *c)
  +static void brw_gs_overwrite_header_dw2_from_r0(struct brw_gs_compile
 *c,
  +unsigned num_verts)
   {
  struct brw_compile *p = c-func;
  brw_AND(p, get_element_ud(c-reg.header, 2),
 get_element_ud(c-reg.R0, 2),
  brw_imm_ud(0x1f));
  +   if (num_verts == 3) {
  +  brw_CMP(p, vec1(brw_null_reg()), BRW_CONDITIONAL_EQ,
  +  get_element_ud(c-reg.header, 2),
  +  brw_imm_ud(_3DPRIM_TRISTRIP_REVERSE));
  +  {
  + brw_MOV(p, get_element_ud(c-reg.header, 2),
  + brw_imm_ud(_3DPRIM_TRISTRIP));
  + brw_set_predicate_control(p, BRW_PREDICATE_NONE);
  +  }
  +   }

 This doesn't mess up normal rendering of tristrips in any way?  It looks
 like it could be a separate commit to me.


It doesn't mess up normal rendering of tristrips because we also set the
GEN6_GS_REORDER bit of gen6_gs_state.c--this causes alternate triangles in
a tristrip to be reordered so that they all have the same orientation, so
in the geometry shader we need to map _3DPRIM_TRISTRIP_REVERSE to
_3DPRIM_TRISTRIP to prevent future pipeline stages from trying to undo the
reordering.

Having said that, though, I'm going to revert this change, because the
reordering performed by GEN6_GS_REORDER is not the reordering we need for
transform feedback.  For a tristrip with vertices A, B, C, D, and E (in
that order), the hardware normally generates triangles in the order ABC,
BCD, CDE (which is wrong because BCD is improperly oriented).  With
reordering it generates ABC, BDC, CDE.  However, to ensure that the
transform feedback output will render properly when flatshading, we need
the order to be ABC, CBD, CDE.

So consider this part of the patch NAK'd.  I want to wait until we are
implementing transform feedback on Gen7 to fix ordering issues anyhow
(since on Gen7 we have less control over the ordering, and 

Re: [Mesa-dev] Willing to take Haiku support Patches? (Was: DEATH to old drivers!)

[Alexander von Gluck]

On Mon, 19 Dec 2011 11:44:51 -0700, Brian Paul wrote:

On Mon, Dec 19, 2011 at 11:18 AM, Alexander von Gluck
kallis...@unixzen.com wrote:

Good afternoon!

The Haiku OS project (not-for-profit organization, founded in 2001) 
has

found ourselves in a weird spot, we have a working Mesa software
render library based on a *heavily* modified Mesa 7.4.4.

http://cgit.haiku-os.org/haiku/tree/src/libs/mesa

However as you can imagine, updating that is going to be a *big*
pain point.  As Haiku is looking to get some basic 3D rendering
going on it's cards, we need to do upgrade to a newer version of
Mesa.

If we produced well thought out Haiku OS support patches, would
Mesa as a project be interested in accepting them upstream? I think
a better direction may be to move away from the heavily custom
integrated mesa library and move to stock version.

These patches would likely start as run-of-the-mill #ifdef __HAIKU__
macros.

As Haiku has a much smaller developer base then Mesa (20-30 
commiters)
these first steps would greatly assist us in getting hardware 
assisted

3d acceleration going.

Keep in mind this is all early analysis, I haven't tried porting 
7.11.2

yet :)


In general I'm happy to take patches for Haiku.  But I wouldn't want
to see #ifdef __HAIKU__ lines scattered all over the code.  
Hopefully,

that can be limited to header files as with other platforms.

What GPUs/cards do you need to support?  Does this involve restoring
any legacy drivers that were removed a few weeks ago?  Could you move
to Gallium-based drivers?


We are mostly looking for Radeon HD and Intel at the moment (because 
they
represent the newest chipsets we support at the moment)  It does not 
involve

restoring the legacy drivers.

We want to make sure we support do things correctly to minimize Mesa
impact / work, while keeping to the Haiku (aka BeOS) method of graphic
driver design as much as possible.

Example, in order from top to bottom:
Kernel space graphic driver
   
http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/graphics/radeon_hd


User space graphic accelerant that maps graphic driver memory
   
http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd


User space OpenGL / 3d render that ties back to the accelerant
   http://cgit.haiku-os.org/haiku/tree/src/add-ons/opengl


We can work on getting something working prior to providing patches, I
mostly wanted to test the waters to see how the Mesa developers felt 
before

putting the work in :)

Thanks!
 -- Alex
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] i965 gen6: Initial implementation of transform feedback.

[Paul Berry]

This patch adds basic transform feedback capability for Gen6 hardware.
This consists of several related pieces of functionality:

(1) In gen6_sol.c, we set up binding table entries for use by
transform feedback.  We use one binding table entry per transform
feedback varying (this allows us to avoid doing pointer arithmetic in
the shader, since we can set up the binding table entries with the
appropriate offsets and surface pitches to place each varying at the
correct address).

(2) In brw_context.c, we advertise the hardware capabilities, which
are as follows:

   MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS 64
   MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS4
   MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS16

OpenGL 3.0 requires these values to be at least 64, 4, and 4,
respectively.  The reason we advertise a larger value than required
for MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS is that we have already
set aside 64 binding table entries, so we might as well make them all
available in both separate attribs and interleaved modes.

(3) We set aside a single SVBI (streamed vertex buffer index) for
use by transform feedback.  The hardware supports four independent
SVBI's, but we only need one, since vertices are added to all
transform feedback buffers at the same rate.  Note: at the moment this
index is reset to 0 only when the driver is initialized.  It needs to
be reset to 0 whenever BeginTransformFeedback() is called, and
otherwise preserved.

(4) In brw_gs_emit.c and brw_gs.c, we modify the geometry shader
program to output transform feedback data as a side effect.

(5) In gen6_gs_state.c, we configure the geometry shader stage to
handle the SVBI pointer correctly.

Note: ordering of vertices is not yet correct for triangle strips
(alternate triangles are improperly oriented).  This will be addressed
in a future patch.

Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---

v2 has been updated to reflect Eric Anholt's comments on 12/17
11:50am, as well as Marek Olšák's suggestion to compute offsets in the
linker (from Re: [Mesa-dev] [PATCH 1/8] mesa: Record transform
feedback stride in linker output., 12/14 05:48am).

 src/mesa/drivers/dri/i965/Makefile.sources   |1 +
 src/mesa/drivers/dri/i965/brw_context.c  |   20 +
 src/mesa/drivers/dri/i965/brw_context.h  |   47 +++-
 src/mesa/drivers/dri/i965/brw_defines.h  |6 ++
 src/mesa/drivers/dri/i965/brw_eu.h   |7 ++
 src/mesa/drivers/dri/i965/brw_eu_emit.c  |   39 +
 src/mesa/drivers/dri/i965/brw_gs.c   |   26 ++-
 src/mesa/drivers/dri/i965/brw_gs.h   |   20 +
 src/mesa/drivers/dri/i965/brw_gs_emit.c  |   93 -
 src/mesa/drivers/dri/i965/brw_misc_state.c   |2 +-
 src/mesa/drivers/dri/i965/brw_state.h|1 +
 src/mesa/drivers/dri/i965/brw_state_upload.c |1 +
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |   85 
 src/mesa/drivers/dri/i965/gen6_gs_state.c|8 ++-
 src/mesa/drivers/dri/i965/gen6_sol.c |   71 
 15 files changed, 417 insertions(+), 10 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/gen6_sol.c

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index cd6a8f4..e50f9c3 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -93,6 +93,7 @@ i965_C_SOURCES := \
gen6_sampler_state.c \
gen6_scissor_state.c \
gen6_sf_state.c \
+gen6_sol.c \
gen6_urb.c \
gen6_viewport_state.c \
gen6_vs_state.c \
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index faa02bf..eb68bf4 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -178,6 +178,26 @@ brwCreateContext(int api,

ctx-Const.MaxTextureMaxAnisotropy = 16.0;
 
+   /* Hardware only supports a limited number of transform feedback buffers.
+* So we need to override the Mesa default (which is based only on software
+* limits).
+*/
+   ctx-Const.MaxTransformFeedbackSeparateAttribs = BRW_MAX_SOL_BUFFERS;
+
+   /* On Gen6, in the worst case, we use up one binding table entry per
+* transform feedback component (see comments above the definition of
+* BRW_MAX_SOL_BINDINGS, in brw_context.h), so we need to advertise a value
+* for MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS equal to
+* BRW_MAX_SOL_BINDINGS.
+*
+* In separate components mode, we need to divide this value by
+* BRW_MAX_SOL_BUFFERS, so that the total number of binding table entries
+* used up by all buffers will not exceed BRW_MAX_SOL_BINDINGS.
+*/
+   ctx-Const.MaxTransformFeedbackInterleavedComponents = BRW_MAX_SOL_BINDINGS;
+   ctx-Const.MaxTransformFeedbackSeparateComponents =
+  

[Mesa-dev] [PATCH 01/10] i965: Add missing SIMD4x2 sample_l_c message #defines.

[Kenneth Graunke]

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_defines.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 0eb7512..1854602 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -799,6 +799,7 @@ enum brw_message_target {
 #define BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_COMPARE0
 #define BRW_SAMPLER_MESSAGE_SIMD16_SAMPLE_COMPARE 2
 #define BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_BIAS_COMPARE 0
+#define BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD_COMPARE 1
 #define BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_LOD_COMPARE  1
 #define BRW_SAMPLER_MESSAGE_SIMD4X2_RESINFO   2
 #define BRW_SAMPLER_MESSAGE_SIMD16_RESINFO2
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 02/10] i965/vs: Implement vec4_visitor::generate_tex().

[Kenneth Graunke]

This is the part that takes the vec4_instruction IR and turns it into
actual Gen ISA.

v2: Add Gen4 messages, don't retype m0 to UW.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_vec4.h|4 +
 src/mesa/drivers/dri/i965/brw_vec4_emit.cpp |  106 +++
 2 files changed, 110 insertions(+), 0 deletions(-)

Somehow I completely forgot Gen4 in the last revision.

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 5bf8027..d3505c3 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -549,6 +549,10 @@ public:
struct brw_reg src0,
struct brw_reg src1);
 
+   void generate_tex(vec4_instruction *inst,
+struct brw_reg dst,
+struct brw_reg src);
+
void generate_urb_write(vec4_instruction *inst);
void generate_oword_dual_block_offsets(struct brw_reg m1,
  struct brw_reg index);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
index 54bbe13..c131343 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
@@ -355,6 +355,104 @@ vec4_visitor::generate_math2_gen4(vec4_instruction *inst,
 }
 
 void
+vec4_visitor::generate_tex(vec4_instruction *inst,
+  struct brw_reg dst,
+  struct brw_reg src)
+{
+   int msg_type = -1;
+
+   if (intel-gen = 5) {
+  switch (inst-opcode) {
+  case SHADER_OPCODE_TEX:
+  case SHADER_OPCODE_TXL:
+if (inst-shadow_compare) {
+   msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LOD_COMPARE;
+} else {
+   msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LOD;
+}
+break;
+  case SHADER_OPCODE_TXD:
+/* There is no sample_d_c message; comparisons are done manually. */
+msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_DERIVS;
+break;
+  case SHADER_OPCODE_TXF:
+msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_LD;
+break;
+  case SHADER_OPCODE_TXS:
+msg_type = GEN5_SAMPLER_MESSAGE_SAMPLE_RESINFO;
+break;
+  default:
+assert(!should not get here: invalid VS texture opcode);
+break;
+  }
+   } else {
+  switch (inst-opcode) {
+  case SHADER_OPCODE_TEX:
+  case SHADER_OPCODE_TXL:
+if (inst-shadow_compare) {
+   msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD_COMPARE;
+   assert(inst-mlen == 3);
+} else {
+   msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD;
+   assert(inst-mlen == 2);
+}
+break;
+  case SHADER_OPCODE_TXD:
+/* There is no sample_d_c message; comparisons are done manually. */
+msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_GRADIENTS;
+assert(inst-mlen == 4);
+break;
+  case SHADER_OPCODE_TXF:
+msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_LD;
+assert(inst-mlen == 2);
+break;
+  case SHADER_OPCODE_TXS:
+msg_type = BRW_SAMPLER_MESSAGE_SIMD4X2_RESINFO;
+assert(inst-mlen == 2);
+break;
+  default:
+assert(!should not get here: invalid VS texture opcode);
+break;
+  }
+   }
+
+   assert(msg_type != -1);
+
+   if (inst-header_present) {
+  /* Set up an implied move from g0 to the MRF. */
+  src = brw_vec8_grf(0, 0);
+   }
+
+   uint32_t return_format;
+
+   switch (dst.type) {
+   case BRW_REGISTER_TYPE_D:
+  return_format = BRW_SAMPLER_RETURN_FORMAT_SINT32;
+  break;
+   case BRW_REGISTER_TYPE_UD:
+  return_format = BRW_SAMPLER_RETURN_FORMAT_UINT32;
+  break;
+   default:
+  return_format = BRW_SAMPLER_RETURN_FORMAT_FLOAT32;
+  break;
+   }
+
+   brw_SAMPLE(p,
+ dst,
+ inst-base_mrf,
+ src,
+ SURF_INDEX_TEXTURE(inst-sampler),
+ inst-sampler,
+ WRITEMASK_XYZW,
+ msg_type,
+ 1, /* response length */
+ inst-mlen,
+ inst-header_present,
+ BRW_SAMPLER_SIMD_MODE_SIMD4X2,
+ return_format);
+}
+
+void
 vec4_visitor::generate_urb_write(vec4_instruction *inst)
 {
brw_urb_WRITE(p,
@@ -593,6 +691,14 @@ vec4_visitor::generate_vs_instruction(vec4_instruction 
*instruction,
   }
   break;
 
+   case SHADER_OPCODE_TEX:
+   case SHADER_OPCODE_TXD:
+   case SHADER_OPCODE_TXF:
+   case SHADER_OPCODE_TXL:
+   case SHADER_OPCODE_TXS:
+  generate_tex(inst, dst, src[0]);
+  break;
+
case VS_OPCODE_URB_WRITE:
   generate_urb_write(inst);
   break;
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 03/10] i965/vs: Implement vec4_visitor::visit(ir_texture *).

[Kenneth Graunke]

This translates the GLSL compiler's IR into vec4_instruction IR,
generating code to load coordinates, LOD info, shadow comparitors, and
so on into the appropriate message registers.

It turns out that the SIMD4x2 parameters are identical on Gen 5-7, and
the Gen4 code is similar enough that, unlike in the FS, it's easy enough
to support all generations in a single function.

v2: Load zeros for missing coordinates (fixing vs-texelFetch-sampler1D
and 2D on G45), and fix G45 message length for shadow comparisons.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  127 ++--
 1 files changed, 120 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 853c3ee..b49cf9c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -25,6 +25,7 @@
 extern C {
 #include main/macros.h
 #include program/prog_parameter.h
+#include program/sampler.h
 }
 
 namespace brw {
@@ -1755,13 +1756,125 @@ vec4_visitor::visit(ir_call *ir)
 void
 vec4_visitor::visit(ir_texture *ir)
 {
-   /* FINISHME: Implement vertex texturing.
-*
-* With 0 vertex samplers available, the linker will reject
-* programs that do vertex texturing, but after our visitor has
-* run.
-*/
-   this-result = src_reg(this, glsl_type::vec4_type);
+   int sampler = _mesa_get_sampler_uniform_value(ir-sampler, prog, vp-Base);
+   sampler = vp-Base.SamplerUnits[sampler];
+
+   /* Should be lowered by do_lower_texture_projection */
+   assert(!ir-projector);
+
+   vec4_instruction *inst;
+   switch (ir-op) {
+   case ir_tex:
+   case ir_txl:
+  inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXL);
+  break;
+   case ir_txd:
+  inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXD);
+  break;
+   case ir_txf:
+  inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXF);
+  break;
+   case ir_txs:
+  inst = new(mem_ctx) vec4_instruction(this, SHADER_OPCODE_TXS);
+  break;
+   case ir_txb:
+  assert(!TXB is not valid for vertex shaders.);
+   }
+
+   inst-header_present = intel-gen  5;
+   inst-base_mrf = 2;
+   inst-mlen = inst-header_present + 1; /* always at least one */
+   inst-sampler = sampler;
+   inst-dst = dst_reg(this, glsl_type::get_instance(ir-type-base_type,4,1));
+   inst-shadow_compare = ir-shadow_comparitor != NULL;
+
+   /* MRF for the first parameter */
+   int param_base = inst-base_mrf + inst-header_present;
+
+   if (ir-op == ir_txs) {
+  ir-lod_info.lod-accept(this);
+  int writemask = intel-gen == 4 ? WRITEMASK_W : WRITEMASK_X;
+  emit(MOV(dst_reg(MRF, param_base, ir-lod_info.lod-type, writemask),
+  this-result));
+   } else {
+  int i, coord_mask = 0, zero_mask = 0;
+  /* Load the coordinate */
+  /* FINISHME: gl_clamp_mask and saturate */
+  for (i = 0; i  ir-coordinate-type-vector_elements; i++)
+coord_mask |= (1  i);
+  for (; i  4; i++)
+zero_mask |= (1  i);
+
+  ir-coordinate-accept(this);
+  emit(MOV(dst_reg(MRF, param_base, ir-coordinate-type, coord_mask),
+  this-result));
+  emit(MOV(dst_reg(MRF, param_base, ir-coordinate-type, zero_mask),
+  src_reg(0)));
+  /* Load the shadow comparitor */
+  if (ir-shadow_comparitor) {
+ir-shadow_comparitor-accept(this);
+emit(MOV(dst_reg(MRF, param_base + 1, ir-shadow_comparitor-type,
+ WRITEMASK_X),
+ this-result));
+inst-mlen++;
+  }
+
+  /* Load the LOD info */
+  if (ir-op == ir_txl) {
+int mrf, writemask;
+if (intel-gen = 5) {
+   mrf = param_base + 1;
+   if (ir-shadow_comparitor) {
+  writemask = WRITEMASK_Y;
+  /* mlen already incremented */
+   } else {
+  writemask = WRITEMASK_X;
+  inst-mlen++;
+   }
+} else /* intel-gen == 4 */ {
+   mrf = param_base;
+   writemask = WRITEMASK_Z;
+}
+ir-lod_info.lod-accept(this);
+emit(MOV(dst_reg(MRF, mrf, ir-lod_info.lod-type, writemask),
+ this-result));
+  } else if (ir-op == ir_txf) {
+ir-lod_info.lod-accept(this);
+emit(MOV(dst_reg(MRF, param_base, ir-lod_info.lod-type, WRITEMASK_W),
+ this-result));
+  } else if (ir-op == ir_txd) {
+const glsl_type *type = ir-lod_info.grad.dPdx-type;
+
+ir-lod_info.grad.dPdx-accept(this);
+src_reg dPdx = this-result;
+ir-lod_info.grad.dPdy-accept(this);
+src_reg dPdy = this-result;
+
+if (intel-gen = 5) {
+   dPdx.swizzle = 
BRW_SWIZZLE4(SWIZZLE_X,SWIZZLE_X,SWIZZLE_Y,SWIZZLE_Y);
+   dPdy.swizzle = 
BRW_SWIZZLE4(SWIZZLE_X,SWIZZLE_X,SWIZZLE_Y,SWIZZLE_Y);
+   emit(MOV(dst_reg(MRF, 

[Mesa-dev] [PATCH 04/10] i965/fs: Factor out texture offset bitfield computation.

[Kenneth Graunke]

We'll want to reuse this for the VS, and it's complex enough that I'd
rather not cut and paste it.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Eric Anholt e...@anholt.net
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |   19 +--
 src/mesa/drivers/dri/i965/brw_shader.cpp |   23 +++
 src/mesa/drivers/dri/i965/brw_shader.h   |2 ++
 3 files changed, 26 insertions(+), 18 deletions(-)

Unchanged from v1.

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 9ce6696..1143951 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -1077,24 +1077,7 @@ fs_visitor::visit(ir_texture *ir)
fs_reg coordinate = this-result;
 
if (ir-offset != NULL) {
-  ir_constant *offset = ir-offset-as_constant();
-  assert(offset != NULL);
-
-  signed char offsets[3];
-  for (unsigned i = 0; i  ir-offset-type-vector_elements; i++)
-offsets[i] = (signed char) offset-value.i[i];
-
-  /* Combine all three offsets into a single unsigned dword:
-   *
-   *bits 11:8 - U Offset (X component)
-   *bits  7:4 - V Offset (Y component)
-   *bits  3:0 - R Offset (Z component)
-   */
-  unsigned offset_bits = 0;
-  for (unsigned i = 0; i  ir-offset-type-vector_elements; i++) {
-const unsigned shift = 4 * (2 - i);
-offset_bits |= (offsets[i]  shift)  (0xF  shift);
-  }
+  uint32_t offset_bits = brw_texture_offset(ir-offset-as_constant());
 
   /* Explicitly set up the message header by copying g0 to msg reg m1. */
   emit(BRW_OPCODE_MOV, fs_reg(MRF, 1, BRW_REGISTER_TYPE_UD),
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp 
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 33c9ae5..1845c3d 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -239,3 +239,26 @@ brw_math_function(enum opcode op)
   return 0;
}
 }
+
+uint32_t
+brw_texture_offset(ir_constant *offset)
+{
+   assert(offset != NULL);
+
+   signed char offsets[3];
+   for (unsigned i = 0; i  offset-type-vector_elements; i++)
+  offsets[i] = (signed char) offset-value.i[i];
+
+   /* Combine all three offsets into a single unsigned dword:
+*
+*bits 11:8 - U Offset (X component)
+*bits  7:4 - V Offset (Y component)
+*bits  3:0 - R Offset (Z component)
+*/
+   unsigned offset_bits = 0;
+   for (unsigned i = 0; i  offset-type-vector_elements; i++) {
+  const unsigned shift = 4 * (2 - i);
+  offset_bits |= (offsets[i]  shift)  (0xF  shift);
+   }
+   return offset_bits;
+}
diff --git a/src/mesa/drivers/dri/i965/brw_shader.h 
b/src/mesa/drivers/dri/i965/brw_shader.h
index 1054d7a..3e6f579 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.h
+++ b/src/mesa/drivers/dri/i965/brw_shader.h
@@ -23,9 +23,11 @@
 
 #include stdint.h
 #include brw_defines.h
+#include glsl/ir.h
 
 #pragma once
 
 int brw_type_for_base_type(const struct glsl_type *type);
 uint32_t brw_conditional_for_comparison(unsigned int op);
 uint32_t brw_math_function(enum opcode op);
+uint32_t brw_texture_offset(ir_constant *offset);
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 05/10] i965/vs: Add support for texel offsets.

[Kenneth Graunke]

The visit() half computes the values to put in the header based on the
IR and simply stuffs that in the vec4_instruction; the emit() half uses
this to set up the message header.  This works out well since emit() can
use brw_reg directly and access individual DWords without kludgery.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Eric Anholt e...@anholt.net
---
 src/mesa/drivers/dri/i965/brw_vec4.h   |1 +
 src/mesa/drivers/dri/i965/brw_vec4_emit.cpp|   18 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |6 +-
 3 files changed, 23 insertions(+), 2 deletions(-)

Unchanged from v1.

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index d3505c3..28da8c0 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -271,6 +271,7 @@ public:
int conditional_mod; /** BRW_CONDITIONAL_* */
 
int sampler;
+   uint32_t texture_offset; /** Texture Offset bitfield */
int target; /** MRT target. */
bool shadow_compare;
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
index c131343..b2427da 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
@@ -418,7 +418,23 @@ vec4_visitor::generate_tex(vec4_instruction *inst,
 
assert(msg_type != -1);
 
-   if (inst-header_present) {
+   /* Load the message header if present.  If there's a texture offset, we need
+* to set it up explicitly and load the offset bitfield.  Otherwise, we can
+* use an implied move from g0 to the first message register.
+*/
+   if (inst-texture_offset) {
+  /* Explicitly set up the message header by copying g0 to the MRF. */
+  brw_MOV(p, retype(brw_message_reg(inst-base_mrf), BRW_REGISTER_TYPE_UD),
+retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
+
+  /* Then set the offset bits in DWord 2. */
+  brw_set_access_mode(p, BRW_ALIGN_1);
+  brw_MOV(p,
+ retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE, inst-base_mrf, 2),
+BRW_REGISTER_TYPE_UD),
+ brw_imm_uw(inst-texture_offset));
+  brw_set_access_mode(p, BRW_ALIGN_16);
+   } else if (inst-header_present) {
   /* Set up an implied move from g0 to the MRF. */
   src = brw_vec8_grf(0, 0);
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index b49cf9c..b424a0f 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1781,13 +1781,17 @@ vec4_visitor::visit(ir_texture *ir)
   assert(!TXB is not valid for vertex shaders.);
}
 
-   inst-header_present = intel-gen  5;
+   /* Texel offsets go in the message header; Gen4 also requires headers. */
+   inst-header_present = ir-offset || intel-gen  5;
inst-base_mrf = 2;
inst-mlen = inst-header_present + 1; /* always at least one */
inst-sampler = sampler;
inst-dst = dst_reg(this, glsl_type::get_instance(ir-type-base_type,4,1));
inst-shadow_compare = ir-shadow_comparitor != NULL;
 
+   if (ir-offset != NULL)
+  inst-texture_offset = brw_texture_offset(ir-offset-as_constant());
+
/* MRF for the first parameter */
int param_base = inst-base_mrf + inst-header_present;
 
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 06/10] i965/fs: Factor out texturing related data from brw_wm_prog_key.

[Kenneth Graunke]

The idea is to reuse this for the VS and (in the future) GS as well.

v2: Include yuvtex data since we're not dropping GL_MESA_ycbycr.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Eric Anholt e...@anholt.net [v1]
---
 src/mesa/drivers/dri/i965/brw_fs.cpp |4 +-
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |   26 ++--
 src/mesa/drivers/dri/i965/brw_program.h  |   60 ++
 src/mesa/drivers/dri/i965/brw_wm.c   |  162 +
 src/mesa/drivers/dri/i965/brw_wm.h   |   19 +---
 src/mesa/drivers/dri/i965/brw_wm_emit.c  |2 +-
 src/mesa/drivers/dri/i965/brw_wm_fp.c|   10 +-
 7 files changed, 168 insertions(+), 115 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/brw_program.h

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 339044c..8ca4a87 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1904,10 +1904,10 @@ brw_fs_precompile(struct gl_context *ctx, struct 
gl_shader_program *prog)
 
for (int i = 0; i  BRW_MAX_TEX_UNIT; i++) {
   if (fp-Base.ShadowSamplers  (1  i))
-key.compare_funcs[i] = GL_LESS;
+key.tex.compare_funcs[i] = GL_LESS;
 
   /* FINISHME: depth compares might use (0,0,0,W) for example */
-  key.tex_swizzles[i] = SWIZZLE_XYZW;
+  key.tex.swizzles[i] = SWIZZLE_XYZW;
}
 
if (fp-Base.InputsRead  FRAG_BIT_WPOS) {
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 1143951..9f8a44a 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -623,7 +623,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
   for (int i = 0; i  ir-coordinate-type-vector_elements; i++) {
 fs_inst *inst = emit(BRW_OPCODE_MOV,
  fs_reg(MRF, base_mrf + mlen + i), coordinate);
-if (i  3  c-key.gl_clamp_mask[i]  (1  sampler))
+if (i  3  c-key.tex.gl_clamp_mask[i]  (1  sampler))
inst-saturate = true;
 
 coordinate.reg_offset++;
@@ -655,7 +655,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
   for (int i = 0; i  ir-coordinate-type-vector_elements; i++) {
 fs_inst *inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, base_mrf + mlen + i),
  coordinate);
-if (i  3  c-key.gl_clamp_mask[i]  (1  sampler))
+if (i  3  c-key.tex.gl_clamp_mask[i]  (1  sampler))
inst-saturate = true;
 coordinate.reg_offset++;
   }
@@ -718,7 +718,7 @@ fs_visitor::emit_texture_gen4(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
 base_mrf + mlen + i * 2,
 coordinate.type),
  coordinate);
-if (i  3  c-key.gl_clamp_mask[i]  (1  sampler))
+if (i  3  c-key.tex.gl_clamp_mask[i]  (1  sampler))
inst-saturate = true;
 coordinate.reg_offset++;
   }
@@ -830,7 +830,7 @@ fs_visitor::emit_texture_gen5(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
   fs_reg(MRF, base_mrf + mlen + i * reg_width,
  coordinate.type),
   coordinate);
-  if (i  3  c-key.gl_clamp_mask[i]  (1  sampler))
+  if (i  3  c-key.tex.gl_clamp_mask[i]  (1  sampler))
 inst-saturate = true;
   coordinate.reg_offset++;
}
@@ -978,7 +978,7 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
   for (int i = 0; i  ir-coordinate-type-vector_elements; i++) {
 fs_inst *inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, base_mrf + mlen),
  coordinate);
-if (i  3  c-key.gl_clamp_mask[i]  (1  sampler))
+if (i  3  c-key.tex.gl_clamp_mask[i]  (1  sampler))
inst-saturate = true;
 coordinate.reg_offset++;
 mlen += reg_width;
@@ -1023,7 +1023,7 @@ fs_visitor::emit_texture_gen7(ir_texture *ir, fs_reg dst, 
fs_reg coordinate,
   for (int i = 0; i  ir-coordinate-type-vector_elements; i++) {
 fs_inst *inst = emit(BRW_OPCODE_MOV, fs_reg(MRF, base_mrf + mlen),
  coordinate);
-if (i  3  c-key.gl_clamp_mask[i]  (1  sampler))
+if (i  3  c-key.tex.gl_clamp_mask[i]  (1  sampler))
inst-saturate = true;
 coordinate.reg_offset++;
 mlen += reg_width;
@@ -1064,11 +1064,11 @@ fs_visitor::visit(ir_texture *ir)
 */
bool hw_compare_supported = ir-op != ir_txd;
if (ir-shadow_comparitor  !hw_compare_supported) {
-  assert(c-key.compare_funcs[sampler] != GL_NONE);
+  assert(c-key.tex.compare_funcs[sampler] != GL_NONE);
   /* No need to even sample for GL_ALWAYS or GL_NEVER...bail early */
-  if 

[Mesa-dev] [PATCH 08/10] i965/vs: Add texture related data to brw_vs_prog_key.

[Kenneth Graunke]

Now that this is all factored out, it's trivial to do.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Eric Anholt e...@anholt.net
---
 src/mesa/drivers/dri/i965/brw_vs.c |8 
 src/mesa/drivers/dri/i965/brw_vs.h |3 +++
 2 files changed, 11 insertions(+), 0 deletions(-)

Unchanged from v1.

diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index 81d5f88..6eec973 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -279,8 +279,10 @@ static void brw_upload_vs_prog(struct brw_context *brw)
struct intel_context *intel = brw-intel;
struct gl_context *ctx = intel-ctx;
struct brw_vs_prog_key key;
+   /* BRW_NEW_VERTEX_PROGRAM */
struct brw_vertex_program *vp = 
   (struct brw_vertex_program *)brw-vertex_program;
+   struct gl_program *prog = (struct gl_program *) brw-vertex_program;
int i;
 
memset(key, 0, sizeof(key));
@@ -316,6 +318,12 @@ static void brw_upload_vs_prog(struct brw_context *brw)
   }
}
 
+   /* _NEW_TEXTURE */
+   for (i = 0; i  BRW_MAX_TEX_UNIT; i++) {
+  if (prog-TexturesUsed[i])
+brw_populate_sampler_prog_key_data(ctx, key.tex, i);
+   }
+
/* BRW_NEW_VERTICES */
for (i = 0; i  VERT_ATTRIB_MAX; i++) {
   if (vp-program.Base.InputsRead  BITFIELD64_BIT(i) 
diff --git a/src/mesa/drivers/dri/i965/brw_vs.h 
b/src/mesa/drivers/dri/i965/brw_vs.h
index 8701116..8814251 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.h
+++ b/src/mesa/drivers/dri/i965/brw_vs.h
@@ -36,6 +36,7 @@
 
 #include brw_context.h
 #include brw_eu.h
+#include brw_program.h
 #include program/program.h
 
 
@@ -76,6 +77,8 @@ struct brw_vs_prog_key {
GLuint copy_edgeflag:1;
GLuint point_coord_replace:8;
GLuint clamp_vertex_color:1;
+
+   struct brw_sampler_prog_key_data tex;
 };
 
 
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 09/10] i965/vs: Implement EXT_texture_swizzle support for VS texturing.

[Kenneth Graunke]

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_vec4.h   |2 +
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |   51 +++-
 2 files changed, 52 insertions(+), 1 deletions(-)

Unchanged from v1 (we decided it worked, but I never officially got a R-b)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 28da8c0..2555fa7 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -497,6 +497,8 @@ public:
void emit_math2_gen4(enum opcode opcode, dst_reg dst, src_reg src0, src_reg 
src1);
void emit_math(enum opcode opcode, dst_reg dst, src_reg src0, src_reg src1);
 
+   void swizzle_result(ir_texture *ir, src_reg orig_val, int sampler);
+
void emit_ndc_computation();
void emit_psiz_and_flags(struct brw_reg reg);
void emit_clip_distances(struct brw_reg reg, int offset);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index b424a0f..74e486c 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1878,7 +1878,56 @@ vec4_visitor::visit(ir_texture *ir)
 
emit(inst);
 
-   this-result = src_reg(inst-dst);
+   swizzle_result(ir, src_reg(inst-dst), sampler);
+}
+
+void
+vec4_visitor::swizzle_result(ir_texture *ir, src_reg orig_val, int sampler)
+{
+   this-result = orig_val;
+
+   int s = c-key.tex.swizzles[sampler];
+
+   if (ir-op == ir_txs || ir-type == glsl_type::float_type
+   || s == SWIZZLE_NOOP)
+  return;
+
+   int zero_mask = 0, one_mask = 0, copy_mask = 0;
+   int swizzle[4];
+
+   for (int i = 0; i  4; i++) {
+  switch (GET_SWZ(s, i)) {
+  case SWIZZLE_ZERO:
+zero_mask |= (1  i);
+break;
+  case SWIZZLE_ONE:
+one_mask |= (1  i);
+break;
+  default:
+copy_mask |= (1  i);
+swizzle[i] = GET_SWZ(s, i);
+break;
+  }
+   }
+
+   this-result = src_reg(this, ir-type);
+   dst_reg swizzled_result(this-result);
+
+   if (copy_mask) {
+  orig_val.swizzle = BRW_SWIZZLE4(swizzle[0], swizzle[1], swizzle[2], 
swizzle[3]);
+  swizzled_result.writemask = copy_mask;
+  emit(MOV(swizzled_result, orig_val));
+   }
+
+   if (zero_mask) {
+  swizzled_result.writemask = zero_mask;
+  emit(MOV(swizzled_result, src_reg(0.0f)));
+   }
+
+   if (one_mask) {
+  swizzled_result.writemask = one_mask;
+  emit(MOV(swizzled_result, src_reg(1.0f)));
+   }
 }
 
 void
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 10/10] i965: Advertise our vertex shader texture units.

[Kenneth Graunke]

Previously, we advertised 0 VS texture units.  Now that we have proper
support for using the sampling engine in the VS, we can advertise 16,
which is conveniently the number required for OpenGL 3.0.

v2: Enable on Gen4.  I hacked up my tests to not use flat ivec varyings
and they pass.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Eric Anholt e...@anholt.net
---
 src/mesa/drivers/dri/i965/brw_context.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index faa02bf..5e9cb1f 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -159,7 +159,7 @@ brwCreateContext(int api,
ctx-Const.MaxTextureCoordUnits = 8; /* Mesa limit */
ctx-Const.MaxTextureUnits = MIN2(ctx-Const.MaxTextureCoordUnits,
  ctx-Const.MaxTextureImageUnits);
-   ctx-Const.MaxVertexTextureImageUnits = 0; /* no vertex shader textures */
+   ctx-Const.MaxVertexTextureImageUnits = BRW_MAX_TEX_UNIT;
ctx-Const.MaxCombinedTextureImageUnits =
   ctx-Const.MaxVertexTextureImageUnits +
   ctx-Const.MaxTextureImageUnits;
-- 
1.7.7.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] egl: move unofficial extensions to eglmesaext.h

[Kenneth Graunke]

On 12/19/2011 02:05 AM, Chia-I Wu wrote:
 From: Chia-I Wu o...@lunarg.com
 
 As suggested by Ian in
 
   http://lists.freedesktop.org/archives/mesa-dev/2011-December/016035.html
 
 Note that eglext.h has to include eglmesaext.h at the end instead of the
 beginning because some extensions in eglmesaext.h depend on the official
 extensions.

Looks good to me (or at least much better!)  For both patches:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/8] i965 gen6: Initial implementation of transform feedback.

[Paul Berry]

On 16 December 2011 19:50, Kenneth Graunke kenn...@whitecape.org wrote:

 On 12/13/2011 03:35 PM, Paul Berry wrote:
 [snip]
  +static void
  +brw_update_sol_surface(struct brw_context *brw, drm_intel_bo *bo,
  +   uint32_t *out_offset, unsigned
 num_vector_components,
  +   unsigned stride_dwords, unsigned offset_dwords,
  +   uint32_t buffer_size_minus_1)
  +{
  +   uint32_t *surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 6 *
 4, 32,
  +out_offset);
  +   uint32_t width = buffer_size_minus_1  0x7f;
  +   uint32_t height = (buffer_size_minus_1  0xfff80)  7;
  +   uint32_t depth = (buffer_size_minus_1  0x7f0)  20;
  +   uint32_t pitch_minus_1 = 4*stride_dwords - 1;
  +   uint32_t surface_format;
  +   uint32_t offset_bytes = 4 * offset_dwords;
  +   switch (num_vector_components) {
  +   case 1:
  +  surface_format = BRW_SURFACEFORMAT_R32_FLOAT;
  +  break;
  +   case 2:
  +  surface_format = BRW_SURFACEFORMAT_R32G32_FLOAT;
  +  break;
  +   case 3:
  +  surface_format = BRW_SURFACEFORMAT_R32G32B32_FLOAT;
  +  break;
  +   case 4:
  +  surface_format = BRW_SURFACEFORMAT_R32G32B32A32_FLOAT;
  +  break;
  +   default:
  +  assert (!Invalid vector size for transform feedback output);
  +  surface_format = BRW_SURFACEFORMAT_R32_FLOAT;
  +  break;
  +   }

 Is it possible to have integer transform feedback outputs?  If so, we'd
 need to adjust this.  But we can do that later (if at all).


Yes, integer transform feedback outputs are possible, but I believe that it
won't be necessary to adjust this because the data port doesn't do any
format conversions on streamed vertex buffer write messages.  But I'll
make sure we have the necessary piglit tests to verify this, and if I'm
wrong I'll do a follow-up patch.



 Looks good, Paul.

 Reviewed-by: Kenneth Graunke kenn...@whitecape.org

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] vertex array regression

[Mathias Fröhlich]

Brian,

On Monday, December 19, 2011 17:01:07 you wrote:
 I still don't get what the purpose of the special mapping of the last
 four/five elements is all about.  Can you explain that?

As far as I can see the last ones should not map to anything.
The map is used only in fixed function mode. And there these arrays should not 
show up as inputs to any fixed function shader. I think that the purpose of the 
previous mapping was just to fill in anything. The changes I did serve exactly 
this purpose.

But I agree that here should not be any mapping of these attributes in this 
mode. Attached is a small change that is probably a more clean solution to 
this mapping problem.

The change passes a quick r600g piglit test.

 Yeah, I see how the incorrect varying_inputs values was causing
 _NEW_ARRAY to get set, thus hiding the problem.  The solution looks
 correct, but I'm a little worried about performance, as is mentioned
 in the comment.
 
 Marek, made that change back in March.  Maybe he can take a look at
 this too.
I cannot comment on this, since I do not see a performance regression on my 
use cases.
Marek?

Greetings

Mathias
From 67f3e817dfd6cc0e937e95c9fc8b671da9bf406c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?= mathias.froehl...@web.de
Date: Mon, 19 Dec 2011 20:53:51 +0100
Subject: [PATCH] vbo: Set unused arrays in fixed function mode to invalid.

The vbo module uses index maps to map VBO arrays into VERT_ATTRIB*
arrays. The fixed function map contains some entries that are
basically unused and are curretly mapped to any array.
This change will explicitly map these unused arrays to an
invalid array index which is then filtered out.

Signed-off-by: Mathias Froehlich mathias.froehl...@web.de
---
 src/mesa/vbo/vbo_context.c   |2 +-
 src/mesa/vbo/vbo_exec_draw.c |2 ++
 src/mesa/vbo/vbo_save_draw.c |2 ++
 3 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/src/mesa/vbo/vbo_context.c b/src/mesa/vbo/vbo_context.c
index b2e6bbc..2542c5d 100644
--- a/src/mesa/vbo/vbo_context.c
+++ b/src/mesa/vbo/vbo_context.c
@@ -185,7 +185,7 @@ GLboolean _vbo_CreateContext( struct gl_context *ctx )
 	 vbo-map_vp_none[VERT_ATTRIB_GENERIC(i)]
 = VBO_ATTRIB_MAT_FRONT_AMBIENT + i;
   for (i = NR_MAT_ATTRIBS; i  VERT_ATTRIB_GENERIC_MAX; i++)
-	 vbo-map_vp_none[VERT_ATTRIB_GENERIC(i)] = i;
+	 vbo-map_vp_none[VERT_ATTRIB_GENERIC(i)] = ~((GLuint)0);
   
   for (i = 0; i  Elements(vbo-map_vp_arb); i++)
 	 vbo-map_vp_arb[i] = i;
diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
index dd5363b..ac3ada3 100644
--- a/src/mesa/vbo/vbo_exec_draw.c
+++ b/src/mesa/vbo/vbo_exec_draw.c
@@ -218,6 +218,8 @@ vbo_exec_bind_arrays( struct gl_context *ctx )
 */
for (attr = 0; attr  VERT_ATTRIB_MAX ; attr++) {
   const GLuint src = map[attr];
+  if (VBO_ATTRIB_MAX = src)
+ continue;
 
   if (exec-vtx.attrsz[src]) {
 	 GLsizeiptr offset = (GLbyte *)exec-vtx.attrptr[src] -
diff --git a/src/mesa/vbo/vbo_save_draw.c b/src/mesa/vbo/vbo_save_draw.c
index fa93ca4..8e84c2e 100644
--- a/src/mesa/vbo/vbo_save_draw.c
+++ b/src/mesa/vbo/vbo_save_draw.c
@@ -185,6 +185,8 @@ static void vbo_bind_vertex_list(struct gl_context *ctx,
 
for (attr = 0; attr  VERT_ATTRIB_MAX; attr++) {
   const GLuint src = map[attr];
+  if (VBO_ATTRIB_MAX = src)
+ continue;
 
   if (node_attrsz[src]) {
  /* override the default array set above */
-- 
1.7.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] softpipe: try and use back color for a slot if color fails.

[Dave Airlie]

On Mon, Dec 19, 2011 at 5:49 PM, Dave Airlie airl...@gmail.com wrote:
 On Mon, Dec 19, 2011 at 5:39 PM, Brian Paul bri...@vmware.com wrote:
 On 12/19/2011 09:29 AM, Dave Airlie wrote:

 From: Dave Airlieairl...@redhat.com

 In the case where a front and back output are specified, the draw code
 will
 copy the back output into the front color slot and everything is happy.

 However if no front is specified then the draw code will do a bad copy
 (separate patch), but also the frag shader won't pick up the color as there
 there is
 no write to COLOR from the vertex shader just BCOLOR.

 This patch fixes that problem so if it can't find a vertex shader output
 for the front color slot, it will go and lookup and use one for the back
 color
 slot.

 Signed-off-by: Dave Airlieairl...@redhat.com
 ---
  src/gallium/drivers/softpipe/sp_state_derived.c |    5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

 diff --git a/src/gallium/drivers/softpipe/sp_state_derived.c
 b/src/gallium/drivers/softpipe/sp_state_derived.c
 index f89d23c..5685997 100644
 --- a/src/gallium/drivers/softpipe/sp_state_derived.c
 +++ b/src/gallium/drivers/softpipe/sp_state_derived.c
 @@ -121,6 +121,11 @@ softpipe_get_vertex_info(struct softpipe_context
 *softpipe)
           src = draw_find_shader_output(softpipe-draw,
                                         fsInfo-input_semantic_name[i],
                                         fsInfo-input_semantic_index[i]);
 +        if (fsInfo-input_semantic_name[i] == TGSI_SEMANTIC_COLOR  src
 == 0)

 +          /* try and find a bcolor */
 +          src = draw_find_shader_output(softpipe-draw,
 +                                        TGSI_SEMANTIC_BCOLOR,
 fsInfo-input_semantic_index[i]);
 +
           draw_emit_vertex_attr(vinfo, EMIT_4F, interp, src);
        }


 And if the VS emits neither a front color or back color, what happens?

 Well the same as happens now, which from what I can see is undefined.
 Since if the
 VS emits no colors and the FS expects a color, you have a problem, I'm
 not sure if the
 linker deals with this.

 It seems to me that if the VS doesn't emit a front color and the polygon
 ends up being front-facing, the polygon color is undefined.

 Yes the test seems to not care about the value in the front in this case at 
 all,
 but maybe Ian or someone with more spec can say what the chapter/verse is.


GLSL 1.30 7.6 says

The following built-in vertex output variables are available. A
particular one should be written to if any
functionality in a corresponding fragment shader or fixed pipeline
uses it or state derived from it.
Otherwise, behavior is undefined.

where it defines the front/back builtins.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: remove stray GL_TEXTURE_1D_ARRAY code in _mesa_store_teximage3d()

[Brian Paul]

GL_TEXTURE_1D_ARRAY is never a legal target for glTexImage3D.  This was
probably copypaste code from the _mesa_store_teximage2d() function above.
---
 src/mesa/main/texstore.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index a57a38e..cfe1c24 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -4775,11 +4775,6 @@ _mesa_store_teximage3d(struct gl_context *ctx, GLenum 
target, GLint level,
   return;
}
 
-   if (target == GL_TEXTURE_1D_ARRAY) {
-  depth = height;
-  height = 1;
-   }
-
sliceMaps = (GLubyte **) calloc(depth, sizeof(GLubyte *));
 
/* Map dest texture buffer slices */
-- 
1.7.3.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder

[Andy Furniss]

Maarten Lankhorst wrote:

Hey Andy,

On 12/19/2011 01:50 PM, Andy Furniss wrote:

Maarten Lankhorst wrote:


Looks like I made the checking a bit too paranoid, causing it to not always 
decode last few macroblocks because of fear of reaching end of stream..
Does this work? I removed a few paranoid asserts, and if performance is still 
bad, I'll alter the patch to swap between multiple decode buffers to fix it. 
That should bring performance back to old level.


This version does fix the macroblocks issue.

Perf is still poor.

The dvd assert is also still present. It doesn't happen with all dvds - and is 
not a regression caused by this patch.

When playing with -cache and skipping around I get a different assert - 
attached are backtraces from both types.

Yeah that version didn't fix performance yet, this one should have the same 
performance as before. However those backtraces miss the interesting parts, 
could you build with -O0 instead of -O2 for a complete backtrace?


Perf is back to how it was - just good enough (vdpau is not exactly fast 
compared to anything else), xvmc is better, but has an issue (not new) 
where sometimes it looks jittery like the frame order is wrong (only 
seen on HD with my card on low).


I compiled with -O0 but the backtraces are different - maybe there is 
some randomness.


When getting the skip one I managed to get a couple of hangs rather than 
crashes. One of which I could see was trying some strange resize, eg.

instead of

VO: [vdpau] 720x576 = 1024x576 MPEG2 VDPAU acceleration

I could see something like (from memory)

VO: [vdpau] 19x1893 = 2032x2125 MPEG2 VDPAU acceleration

and it hung in the process of enlarging the window.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder

[Andy Furniss]

Andy Furniss wrote:


I compiled with -O0 but the backtraces are different - maybe there is
some randomness.


Remembered to attach them this time :-)

mplayer: vl/vl_vlc.h:172: vl_vlc_get_vlclbf: Assertion `tbl-length' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6c03a10 (LWP 26420)]
0xe424 in __kernel_vsyscall ()
(gdb) bt full
#0  0xe424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb6dc115a in raise () from /lib/libc.so.6
No symbol table info available.
#2  0xb6dc2787 in abort () from /lib/libc.so.6
No symbol table info available.
#3  0xb6dba69e in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#4  0xb5eafd61 in vl_vlc_get_vlclbf (vlc=0x9e921c8, tbl=0xb5f3d720, 
num_bits=11) at vl/vl_vlc.h:172
__PRETTY_FUNCTION__ = vl_vlc_get_vlclbf
#5  0xb5eaf79d in decode_slice (bs=0x9e9216c, code=2) at 
vl/vl_mpeg12_bitstream.c:829
inc = 0
mb = {base = {codec = PIPE_VIDEO_CODEC_MPEG12}, x = 92, y = 1, 
macroblock_type = 10 '\n', macroblock_modes = {bits = {frame_motion_type = 2, 
field_motion_type = 0, dct_type = 0}, value = 2}, motion_vertical_field_select 
= 0 '\0', PMV = {{{0, 17}, {0, 0}}, {{0, 17}, {0, 0}}}, coded_block_pattern = 
40, 
  blocks = 0xbfb0b624, num_skipped_macroblocks = 0}
dct_blocks = {0, 0, 0, 5, 0, 5, -5, 0 repeats 57 times, 5, 0 repeats 
319 times}
dct_scale = 5
x = 92
__PRETTY_FUNCTION__ = decode_slice
#6  0xb5eaf1bc in vl_mpg12_bs_decode (bs=0x9e9216c, n=1, len=92477, 
lens=0xbfb0ba00, buffer=0xbfb0ba20) at vl/vl_mpeg12_bitstream.c:982
code = 2
__PRETTY_FUNCTION__ = vl_mpg12_bs_decode
#7  0xb5eace48 in vl_mpeg12_decode_bitstream (decoder=0x9e91420, 
target=0x9faa850, picture=0xbfb0ba68, n=1, total_len=92477, lens=0xbfb0ba00, 
data=0xbfb0ba20) at vl/vl_mpeg12_decoder.c:702
dec = (struct vl_mpeg12_decoder *) 0x9e91420
buf = (struct vl_mpeg12_buffer *) 0x9e92114
i = 3
__PRETTY_FUNCTION__ = vl_mpeg12_decode_bitstream
#8  0xb5e40658 in vlVdpDecoderRender (decoder=9, target=17, 
picture_info=0x8ae32f4, bitstream_buffer_count=1, bitstream_buffers=0x9fada58) 
at decode.c:382
data = 0xbfb0ba20
sizes = 0xbfb0ba00
total_size = 92477
vldecoder = (vlVdpDecoder *) 0x9e621a8
vlsurf = (vlVdpSurface *) 0x9f53888
ret = VDP_STATUS_OK
dec = (struct pipe_video_decoder *) 0x9e91420
i = 1
desc = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, mpeg12 = 
{base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0x9ef4fa0, 
ref_backward = 0x0, picture_coding_type = 2, picture_structure = 3, 
frame_pred_frame_dct = 1, q_scale_type = 1, alternate_scan = 0, 
intra_vlc_format = 1, 
concealment_motion_vectors = 0, intra_dc_precision = 2, f_code = {{5, 5}, 
{4, 3}}, top_field_first = 1, full_pel_forward_vector = 0, 
full_pel_backward_vector = 0, num_slices = 35, 
intra_matrix = 0x8ae330f 
\b\b\n\v\r\016\017\021\b\b\v\f\016\017\021\023\n\v\r\016\017\021\021\023\v\v\r\016\017\021\023\024\v\r\016\017\020\022\024\030\r\016\017\020\022\024\030\035\r\016\017\021\023\027\034#\016\017\022\023\027\034#*\b\t\t\n\n\v\v\f\t\t\n\n\v\v\f\f\t\n\n\v\v\f\f\r\n\n\v\v\f\f\r\016\n\v\v\f\r\r\016\016\v\v\f\f\r\016\016\017\v\f\f\r\016\016\017\020\f\f\r\016\016\017\020\021,
 non_intra_matrix = 0x8ae334f 
\b\t\t\n\n\v\v\f\t\t\n\n\v\v\f\f\t\n\n\v\v\f\f\r\n\n\v\v\f\f\r\016\n\v\v\f\r\r\016\016\v\v\f\f\r\016\016\017\v\f\f\r\016\016\017\020\f\f\r\016\016\017\020\021},
 mpeg4 = {base = {
  profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, ref_forward = 0x9ef4fa0, 
ref_backward = 0x0, trd = {2, 3}, trb = {1, 1}, vop_time_increment_resolution = 
0, vop_coding_type = 0 '\0', vop_fcode_forward = 0 '\0', vop_fcode_backward = 1 
'\001', resync_marker_disable = 0 '\0', interlaced = 0 '\0', quant_type = 0 
'\0', 
quarter_sample = 0 '\0', short_video_header = 0 '\0', rounding_control = 0 
'\0', alternate_vertical_scan_flag = 0 '\0', top_field_first = 2 '\002', 
intra_matrix = 0x5 Address 0x5 out of bounds, non_intra_matrix = 0x5 Address 
0x5 out of bounds}, vc1 = {base = {profile = PIPE_VIDEO_PROFILE_MPEG2_MAIN}, 
ref_forward = 0x9ef4fa0, ref_backward = 0x0, slice_count = 2, picture_type 
= 3 '\003', frame_coding_mode = 0 '\0', postprocflag = 0 '\0', pulldown = 0 
'\0', interlace = 1 '\001', tfcntrflag = 0 '\0', finterpflag = 0 '\0', psf = 0 
'\0', dquant = 1 '\001', panscan_flag = 0 '\0', refdist_flag = 0 '\0', 
quantizer = 0 '\0', extended_mv = 0 '\0', extended_dmv = 0 '\0', overlap = 
0 '\0', vstransform = 0 '\0', loopfilter = 1 '\001', fastuvmc = 0 '\0', 
range_mapy_flag = 0 '\0', range_mapy = 0 '\0', range_mapuv_flag = 0 '\0', 
range_mapuv = 0 '\0', multires = 0 '\0', syncmarker = 0 '\0', rangered = 2 
'\002', 
maxbframes = 0 '\0', deblockEnable = 0 '\0', pquant = 0 '\0'}}
#9  0x080f9855 in draw_slice (image=0xbfb0bb5c, stride=0xbfb0bb4c, w=720, 
h=576, x=0, y=0) at 

Re: [Mesa-dev] [PATCH 1/2] linker: fix strdup memory leak

[Ian Romanick]

On 12/19/2011 05:23 AM, Pekka Paalanen wrote:

On Fri, 16 Dec 2011 10:46:11 -0800
Ian Romanicki...@freedesktop.org  wrote:


On 12/14/2011 11:26 PM, Pekka Paalanen wrote:

string_to_uint_map::put() already does a strdup() for the key
argument, so we leak the memory allocated by strdup() in
link_uniforms.cpp.

Remove the extra strdup(), fixes a few Valgrind detected leaks.


Have you run piglit on this?  I seem to recall adding the extra
strdup for a reason.  The hash table keeps a copy of the key pointer
passed to it, and the underlying object may be deleted before the
hash table is deleted.  This can happen if the back-end optimizes
some uniforms away after the linker has generated the list of
active uniforms.  I'm pretty sure there were one or two test cases
that hit this on i965.


Sorry, I didn't. Finally got piglit running, though readPixSanity
failed on stencil values. Anyway it's running all.tests now for the
upstream Mesa master, and then I'll run it with my patches.

Oh, this is Sandybridge, btw.


--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -174,8 +174,7 @@ private:
 if (this-map-get(id, name))
 return;

-  char *key = strdup(name);
-  this-map-put(this-num_active_uniforms, key);
+  this-map-put(this-num_active_uniforms, name);

 /* Each leaf uniform occupies one entry in the list of
active
  * uniforms.


The whole visit_field() function is this:

virtual void visit_field(const glsl_type *type, const char *name)
{
   assert(!type-is_record());
   assert(!(type-is_array()  type-fields.array-is_record()));

   /* Count the number of samplers regardless of whether the uniform is
* already in the hash table.  The hash table prevents adding the same
* uniform for multiple shader targets, but in this case we want to
* count it for each shader target.
*/
   const unsigned values = values_for_type(type);
   if (type-contains_sampler()) {
 this-num_shader_samplers +=
type-is_array() ? type-array_size() : 1;
   } else {
 /* Accumulate the total number of uniform slots used by this shader.
  * Note that samplers do not count against this limit because they
  * don't use any storage on current hardware.
  */
 this-num_shader_uniform_components += values;
   }

   /* If the uniform is already in the map, there's nothing more to do.
*/
   unsigned id;
   if (this-map-get(id, name))
 return;

   char *key = strdup(name);
   this-map-put(this-num_active_uniforms, key);

   /* Each leaf uniform occupies one entry in the list of active
* uniforms.
*/
   this-num_active_uniforms++;
   this-num_values += values;
}

The variable 'key' is not used anywhere else but passed to
string_to_uint_map::put(). That function in its whole is:

void put(unsigned value, const char *key)
{
   /* The low-level hash table structure returns NULL if key is not in the
* hash table.  However, users of this map might want to store zero as a
* valid value in the table.  Bias the value by +1 so that a
* user-specified zero is stored as 1.  This enables ::get to tell the
* difference between a user-specified zero (returned as 1 by
* hash_table_find) and the key not in the table (returned as 0 by
* hash_table_find).
*
* The net effect is that we can't store UINT_MAX in the table.  This is
* because UINT_MAX+1 = 0.
*/
   assert(value != UINT_MAX);
   hash_table_replace(this-ht,
 (void *) (intptr_t) (value + 1),
 strdup(key));
}

Therefore, as far as I see, 'key' is not used for anything else than
passed again through strdup(), which would effectively be:


Ah yes, I forgot that I added that in string_to_uint_map::put.  You are 
quite correct.


Okay, the original patch is:

Reviewed-by: Ian Romanick ian.d.roman...@intel.com


hash_table_replace(..., ..., strdup(strdup(name)));

I don't see any case where this could not be a leak, or prevent a bug.

What do I miss? Is there somewhere another put() that overwrites or
overloads this version of put()?


Thanks,
pq

ps. As for the other patch, thanks for the advice on how to fix it
properly. I don't think I can do that this year, though.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] egl: move unofficial extensions to eglmesaext.h

[Ian Romanick]

On 12/19/2011 02:05 AM, Chia-I Wu wrote:

From: Chia-I Wuo...@lunarg.com

As suggested by Ian in

   http://lists.freedesktop.org/archives/mesa-dev/2011-December/016035.html

Note that eglext.h has to include eglmesaext.h at the end instead of the
beginning because some extensions in eglmesaext.h depend on the official
extensions.


Reviewed-by: Ian Romanick ian.d.roman...@intel.com


---
  include/EGL/eglext.h |  137 +---
  include/EGL/eglmesaext.h |  175 ++
  2 files changed, 176 insertions(+), 136 deletions(-)
  create mode 100644 include/EGL/eglmesaext.h

diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index 9484b83..800a23d 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -120,43 +120,6 @@ typedef EGLBoolean (EGLAPIENTRYP 
PFNEGLDESTROYIMAGEKHRPROC) (EGLDisplay dpy, EGL
  #define EGL_GL_RENDERBUFFER_KHR   0x30B9  /* 
eglCreateImageKHR target */
  #endif

-#ifndef EGL_MESA_drm_image
-#define EGL_MESA_drm_image 1
-#define EGL_DRM_BUFFER_FORMAT_MESA 0x31D0  /* eglCreateImageKHR 
attribute */
-#define EGL_DRM_BUFFER_USE_MESA0x31D1
-
-/* EGL_DRM_BUFFER_FORMAT_MESA tokens */
-#define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA  0x31D2
-
-/* EGL_DRM_BUFFER_USE_MESA bits */
-#define EGL_DRM_BUFFER_USE_SCANOUT_MESA0x0001
-#define EGL_DRM_BUFFER_USE_SHARE_MESA  0x0002
-#define EGL_DRM_BUFFER_USE_CURSOR_MESA 0x0004
-
-#define EGL_DRM_BUFFER_MESA0x31D3  /* eglCreateImageKHR 
target */
-#define EGL_DRM_BUFFER_STRIDE_MESA 0x31D4  /* eglCreateImageKHR 
attribute */
-
-#ifdef EGL_EGLEXT_PROTOTYPES
-EGLAPI EGLImageKHR EGLAPIENTRY eglCreateDRMImageMESA(EGLDisplay dpy, const 
EGLint *attrib_list);
-EGLAPI EGLBoolean EGLAPIENTRY eglExportDRMImageMESA(EGLDisplay dpy, 
EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride);
-#endif
-typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESA) (EGLDisplay dpy, 
const EGLint *attrib_list);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESA) (EGLDisplay dpy, 
EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride);
-#endif
-
-#ifndef EGL_WL_bind_wayland_display
-#define EGL_WL_bind_wayland_display 1
-
-#define EGL_WAYLAND_BUFFER_WL  0x31D5 /* eglCreateImageKHR 
target */
-struct wl_display;
-#ifdef EGL_EGLEXT_PROTOTYPES
-EGLAPI EGLBoolean EGLAPIENTRY eglBindWaylandDisplayWL(EGLDisplay dpy, struct 
wl_display *display);
-EGLAPI EGLBoolean EGLAPIENTRY eglUnbindWaylandDisplayWL(EGLDisplay dpy, struct 
wl_display *display);
-#endif
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLBINDWAYLANDDISPLAYWL) (EGLDisplay dpy, 
struct wl_display *display);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLUNBINDWAYLANDDISPLAYWL) (EGLDisplay 
dpy, struct wl_display *display);
-#endif
-
  #if KHRONOS_SUPPORT_INT64   /* EGLTimeKHR requires 64-bit uint support */
  #ifndef EGL_KHR_reusable_sync
  #define EGL_KHR_reusable_sync 1
@@ -189,75 +152,6 @@ typedef EGLBoolean (EGLAPIENTRYP 
PFNEGLGETSYNCATTRIBKHRPROC) (EGLDisplay dpy, EG
  #endif
  #endif

-/* EGL_MESA_screen extension  PRELIMINARY  */
-#ifndef EGL_MESA_screen_surface
-#define EGL_MESA_screen_surface 1
-
-#define EGL_BAD_SCREEN_MESA0x4000
-#define EGL_BAD_MODE_MESA  0x4001
-#define EGL_SCREEN_COUNT_MESA  0x4002
-#define EGL_SCREEN_POSITION_MESA   0x4003
-#define EGL_SCREEN_POSITION_GRANULARITY_MESA   0x4004
-#define EGL_MODE_ID_MESA   0x4005
-#define EGL_REFRESH_RATE_MESA  0x4006
-#define EGL_OPTIMAL_MESA   0x4007
-#define EGL_INTERLACED_MESA0x4008
-#define EGL_SCREEN_BIT_MESA0x08
-
-typedef khronos_uint32_t EGLScreenMESA;
-typedef khronos_uint32_t EGLModeMESA;
-
-#ifdef EGL_EGLEXT_PROTOTYPES
-EGLAPI EGLBoolean EGLAPIENTRY eglChooseModeMESA(EGLDisplay dpy, EGLScreenMESA 
screen, const EGLint *attrib_list, EGLModeMESA *modes, EGLint modes_size, 
EGLint *num_modes);
-EGLAPI EGLBoolean EGLAPIENTRY eglGetModesMESA(EGLDisplay dpy, EGLScreenMESA 
screen, EGLModeMESA *modes, EGLint modes_size, EGLint *num_modes);
-EGLAPI EGLBoolean EGLAPIENTRY eglGetModeAttribMESA(EGLDisplay dpy, EGLModeMESA 
mode, EGLint attribute, EGLint *value);
-EGLAPI EGLBoolean EGLAPIENTRY eglGetScreensMESA(EGLDisplay dpy, EGLScreenMESA 
*screens, EGLint max_screens, EGLint *num_screens);
-EGLAPI EGLSurface EGLAPIENTRY eglCreateScreenSurfaceMESA(EGLDisplay dpy, 
EGLConfig config, const EGLint *attrib_list);
-EGLAPI EGLBoolean EGLAPIENTRY eglShowScreenSurfaceMESA(EGLDisplay dpy, EGLint 
screen, EGLSurface surface, EGLModeMESA mode);
-EGLAPI EGLBoolean EGLAPIENTRY eglScreenPositionMESA(EGLDisplay dpy, 
EGLScreenMESA screen, EGLint x, EGLint y);
-EGLAPI EGLBoolean EGLAPIENTRY eglQueryScreenMESA(EGLDisplay dpy, EGLScreenMESA 
screen, EGLint attribute, EGLint *value);

Re: [Mesa-dev] [PATCH 2/2] egl: update headers

[Ian Romanick]

On 12/19/2011 02:05 AM, Chia-I Wu wrote:

From: Chia-I Wuo...@lunarg.com

Update to revision 15052.

EGL_MESA_drm_image is now official.  But apparently we have our own extension
to it and we need this in eglmesaext.h:

   #ifdef EGL_MESA_drm_image
   /* Mesa's extension to EGL_MESA_drm_image... */
   #ifndef EGL_DRM_BUFFER_USE_CURSOR_MESA
   #define EGL_DRM_BUFFER_USE_CURSOR_MESA   0x0004
   #endif
   #endif


Where is this actually from?  Is it in the extension?  A layered 
extension?  Outer space? :)  It sounds like we need to propagate and 
update back to the Khronos registry.



---
  include/EGL/eglext.h  |   65 +++-
  include/EGL/eglmesaext.h  |   23 ++--
  include/EGL/eglplatform.h |9 +-
  3 files changed, 73 insertions(+), 24 deletions(-)

diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index 800a23d..a7ea2ea 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -34,8 +34,8 @@ extern C {

  /* Header file version number */
  /* Current version at http://www.khronos.org/registry/egl/ */
-/* $Revision: 12124 $ on $Date: 2010-07-27 20:12:35 -0700 (Tue, 27 Jul 2010) $ 
*/
-#define EGL_EGLEXT_VERSION 7
+/* $Revision: 15052 $ on $Date: 2011-07-06 17:43:46 -0700 (Wed, 06 Jul 2011) $ 
*/
+#define EGL_EGLEXT_VERSION 10

  #ifndef EGL_KHR_config_attribs
  #define EGL_KHR_config_attribs 1
@@ -267,6 +267,67 @@ typedef EGLSurface (EGLAPIENTRYP 
PFNEGLCREATEPIXMAPSURFACEHIPROC) (EGLDisplay dp
  #define EGL_COLOR_ARGB_HI 0x8F73
  #endif /* EGL_HI_colorformats */

+#ifndef EGL_MESA_drm_image
+#define EGL_MESA_drm_image 1
+#define EGL_DRM_BUFFER_FORMAT_MESA 0x31D0  /* 
CreateDRMImageMESA attribute */
+#define EGL_DRM_BUFFER_USE_MESA0x31D1  /* 
CreateDRMImageMESA attribute */
+#define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA  0x31D2  /* 
EGL_IMAGE_FORMAT_MESA attribute value */
+#define EGL_DRM_BUFFER_MESA0x31D3  /* 
eglCreateImageKHR target */
+#define EGL_DRM_BUFFER_STRIDE_MESA 0x31D4
+#define EGL_DRM_BUFFER_USE_SCANOUT_MESA0x0001  /* 
EGL_DRM_BUFFER_USE_MESA bits */
+#define EGL_DRM_BUFFER_USE_SHARE_MESA  0x0002  /* 
EGL_DRM_BUFFER_USE_MESA bits */
+#ifdef EGL_EGLEXT_PROTOTYPES
+EGLAPI EGLImageKHR EGLAPIENTRY eglCreateDRMImageMESA (EGLDisplay dpy, const 
EGLint *attrib_list);
+EGLAPI EGLBoolean EGLAPIENTRY eglExportDRMImageMESA (EGLDisplay dpy, 
EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride);
+#endif /* EGL_EGLEXT_PROTOTYPES */
+typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESAPROC) (EGLDisplay 
dpy, const EGLint *attrib_list);
+typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESAPROC) (EGLDisplay 
dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride);
+#endif
+
+#ifndef EGL_NV_post_sub_buffer
+#define EGL_NV_post_sub_buffer 1
+#define EGL_POST_SUB_BUFFER_SUPPORTED_NV   0x30BE
+#ifdef EGL_EGLEXT_PROTOTYPES
+EGLAPI EGLBoolean EGLAPIENTRY eglPostSubBufferNV (EGLDisplay dpy, EGLSurface 
surface, EGLint x, EGLint y, EGLint width, EGLint height);
+#endif /* EGL_EGLEXT_PROTOTYPES */
+typedef EGLBoolean (EGLAPIENTRYP PFNEGLPOSTSUBBUFFERNVPROC) (EGLDisplay dpy, 
EGLSurface surface, EGLint x, EGLint y, EGLint width, EGLint height);
+#endif
+
+#ifndef EGL_ANGLE_query_surface_pointer
+#define EGL_ANGLE_query_surface_pointer 1
+#ifdef EGL_EGLEXT_PROTOTYPES
+EGLAPI EGLBoolean eglQuerySurfacePointerANGLE(EGLDisplay dpy, EGLSurface 
surface, EGLint attribute, void **value);
+#endif
+typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYSURFACEPOINTERANGLEPROC) 
(EGLDisplay dpy, EGLSurface surface, EGLint attribute, void **value);
+#endif
+
+#ifndef EGL_ANGLE_surface_d3d_texture_2d_share_handle
+#define EGL_ANGLE_surface_d3d_texture_2d_share_handle 1
+#define EGL_D3D_TEXTURE_2D_SHARE_HANDLE_ANGLE  0x3200
+#endif
+
+#ifndef EGL_NV_coverage_sample_resolve
+#define EGL_NV_coverage_sample_resolve 1
+#define EGL_COVERAGE_SAMPLE_RESOLVE_NV 0x3131
+#define EGL_COVERAGE_SAMPLE_RESOLVE_DEFAULT_NV 0x3132
+#define EGL_COVERAGE_SAMPLE_RESOLVE_NONE_NV0x3133
+#endif
+
+#if KHRONOS_SUPPORT_INT64   /* EGLTimeKHR requires 64-bit uint support */
+#ifndef EGL_NV_system_time
+#define EGL_NV_system_time 1
+
+typedef khronos_utime_nanoseconds_t EGLuint64NV;
+
+#ifdef EGL_EGLEXT_PROTOTYPES
+EGLAPI EGLuint64NV EGLAPIENTRY eglGetSystemTimeFrequencyNV(void);
+EGLAPI EGLuint64NV EGLAPIENTRY eglGetSystemTimeNV(void);
+#endif /* EGL_EGLEXT_PROTOTYPES */
+typedef EGLuint64NV (EGLAPIENTRYP PFNEGLGETSYSTEMTIMEFREQUENCYNVPROC) (void);
+typedef EGLuint64NV (EGLAPIENTRYP PFNEGLGETSYSTEMTIMENVPROC) (void);
+#endif
+#endif
+
  #includeEGL/eglmesaext.h

  #ifdef __cplusplus
diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
index 1b83778..53576ba 100644
--- a/include/EGL/eglmesaext.h
+++ b/include/EGL/eglmesaext.h
@@ -102,28 +102,11 @@ typedef EGLDisplay (EGLAPIENTRYP 

Re: [Mesa-dev] [PATCH] i965: Don't minify depth when setting up cube map miptrees on Gen4.

[Eric Anholt]

On Mon, 19 Dec 2011 10:38:38 -0800, Kenneth Graunke kenn...@whitecape.org 
wrote:
 Prior to Ironlake, cube maps were stored as 3D textures.  In recent
 refactoring, we removed a separate layers parameter in favor of using
 depth.  Unfortunately, depth was getting minified, which is only correct
 for actual 3D textures.
 
 Fixes piglit tests:
 - bugs/crash-cubemap-order
 - fbo/fbo-cubemap
 - texturing/cubemap
 
 Also changes texturing/cubemap npot from abort to fail.
 
 This hasn't seen a full test run since Piglit on Mesa master hangs
 GM45 a lot.
 
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org

Reviewed-by: Eric Anholt e...@anholt.net


pgpEvXwcYxrz8.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 5/6] vl: Remove most members of pipe_video_decoder

[Maarten Lankhorst]

Hey Andy,

On 12/19/2011 10:17 PM, Andy Furniss wrote:
 Andy Furniss wrote:

 I compiled with -O0 but the backtraces are different - maybe there is
 some randomness.

 Remembered to attach them this time :-)
Thanks, but nothing seems to be obviously wrong there. I don't suppose you 
could find a small sample file that would trigger the problem?

~Maarten
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: remove stray GL_TEXTURE_1D_ARRAY code in _mesa_store_teximage3d()

[Eric Anholt]

On Mon, 19 Dec 2011 13:47:42 -0700, Brian Paul bri...@vmware.com wrote:
 GL_TEXTURE_1D_ARRAY is never a legal target for glTexImage3D.  This was
 probably copypaste code from the _mesa_store_teximage2d() function above.

Radeon and intel use texstore3d for all our TexImage* storage.  Though
it does look like we could dump our 1D and 3D overrides of 1D and 3D,
and then use texstore2d.


pgpcSPyYdBnOL.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] mesa: remove stray GL_TEXTURE_1D_ARRAY code in _mesa_store_teximage3d()

[Brian Paul]

On 12/19/2011 02:56 PM, Eric Anholt wrote:

On Mon, 19 Dec 2011 13:47:42 -0700, Brian Paulbri...@vmware.com  wrote:

GL_TEXTURE_1D_ARRAY is never a legal target for glTexImage3D.  This was
probably copypaste code from the _mesa_store_teximage2d() function above.


Radeon and intel use texstore3d for all our TexImage* storage.  Though
it does look like we could dump our 1D and 3D overrides of 1D and 3D,
and then use texstore2d.


OK, I'll leave that as-is for now.  There should probably be a comment 
explaining what's going on there.


I found this when I was looking at consolidating the texstore code.  I 
think that all six variations of 1D/2D/3D whole/sub-image could be 
consolidated into one function.  I'll see if I can finish that up tonight.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Fix build with LLVM = r145623.

[Johannes Obermayr]

This is a workaround for https://bugs.freedesktop.org/show_bug.cgi?id=43861.

Actually the issue which makes -pedantic failing should be solved.
---
 configure.ac |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index a4943e1..8e809b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1753,7 +1753,7 @@ if test x$enable_gallium_llvm = xyes; then
 
 if test x$LLVM_CONFIG != xno; then
LLVM_VERSION=`$LLVM_CONFIG --version`
-   LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed 's/-DNDEBUG\//g'`
+   LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed -e 's/-DNDEBUG\//g' -e 
's/-pedantic//g'`
LLVM_LIBS=`$LLVM_CONFIG --libs`
 
LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
-- 
1.7.7

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Fix build with LLVM = r145623.

[Vinson Lee]

 -Original Message-
 
 This is a workaround for
 https://bugs.freedesktop.org/show_bug.cgi?id=43861.
 
 Actually the issue which makes -pedantic failing should be solved.
 ---
  configure.ac |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index a4943e1..8e809b9 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1753,7 +1753,7 @@ if test x$enable_gallium_llvm = xyes; then
 
  if test x$LLVM_CONFIG != xno; then
   LLVM_VERSION=`$LLVM_CONFIG --version`
 - LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed 's/-DNDEBUG\//g'`
 + LLVM_CFLAGS=`$LLVM_CONFIG --cppflags|sed -e 's/-DNDEBUG\//g' -e
 's/-pedantic//g'`
   LLVM_LIBS=`$LLVM_CONFIG --libs`
 
   LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
 --
 1.7.7
 

I don't see this issue with llvm-3.1svn.

$ svnversion .
146915

$ llvm-config --version
3.1svn

$ llvm-config --cppflags
-I/usr/local/include -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder

[Andy Furniss]

Maarten Lankhorst wrote:

Hey Andy,

On 12/19/2011 10:17 PM, Andy Furniss wrote:

Andy Furniss wrote:


I compiled with -O0 but the backtraces are different - maybe there is
some randomness.


Remembered to attach them this time :-)

Thanks, but nothing seems to be obviously wrong there. I don't suppose you 
could find a small sample file that would trigger the problem?


I'll try, but I don't think I'll have much luck.

I think this one may need a disk involved - maybe also libdvdcss (I can 
reproduce with different versions of mplayer and softpipe).

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/10] i965: Add missing SIMD4x2 sample_l_c message #defines.

[Ian Romanick]

On 12/19/2011 11:09 AM, Kenneth Graunke wrote:

Signed-off-by: Kenneth Graunkekenn...@whitecape.org


All but patch 03/10 are:

Reviewed-by: Ian Romanick ian.d.roman...@intel.com

I don't know the code well enough to give a credible R-b for 3.


---
  src/mesa/drivers/dri/i965/brw_defines.h |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 0eb7512..1854602 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -799,6 +799,7 @@ enum brw_message_target {
  #define BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_COMPARE0
  #define BRW_SAMPLER_MESSAGE_SIMD16_SAMPLE_COMPARE 2
  #define BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_BIAS_COMPARE 0
+#define BRW_SAMPLER_MESSAGE_SIMD4X2_SAMPLE_LOD_COMPARE 1
  #define BRW_SAMPLER_MESSAGE_SIMD8_SAMPLE_LOD_COMPARE  1
  #define BRW_SAMPLER_MESSAGE_SIMD4X2_RESINFO   2
  #define BRW_SAMPLER_MESSAGE_SIMD16_RESINFO2


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] glx: Deliver an xlib style error to the application from an XCB error

[Ian Romanick]

From: Ian Romanick ian.d.roman...@intel.com

Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
 src/glx/glx_error.c |   19 +++
 src/glx/glx_error.h |4 
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/src/glx/glx_error.c b/src/glx/glx_error.c
index 0855c35..b3860db 100644
--- a/src/glx/glx_error.c
+++ b/src/glx/glx_error.c
@@ -65,3 +65,22 @@ __glXSendError(Display * dpy, int_fast8_t errorCode, 
uint_fast32_t resourceID,
 
UnlockDisplay(dpy);
 }
+
+void
+__glXSendErrorForXcb(Display * dpy, const xcb_generic_error_t *err)
+{
+   xError error;
+
+   LockDisplay(dpy);
+
+   error.type = X_Error;
+   error.errorCode = err-error_code;
+   error.sequenceNumber = err-sequence;
+   error.resourceID = err-resource_id;
+   error.minorCode = err-minor_code;
+   error.majorCode = err-major_code;
+
+   _XError(dpy, error);
+
+   UnlockDisplay(dpy);
+}
diff --git a/src/glx/glx_error.h b/src/glx/glx_error.h
index 19be38b..eaf6b81 100644
--- a/src/glx/glx_error.h
+++ b/src/glx/glx_error.h
@@ -29,7 +29,11 @@
 #include stdbool.h
 #include stdint.h
 #include X11/Xlib.h
+#include xcb/xcb.h
 
 void __glXSendError(Display * dpy, int_fast8_t errorCode,
uint_fast32_t resourceID, uint_fast16_t minorCode,
bool coreX11error);
+
+_X_HIDDEN void __glXSendErrorForXcb(Display * dpy,
+   const xcb_generic_error_t *err);
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] glx: Propagate the glXIsDirect protocol error back to the application

[Ian Romanick]

From: Ian Romanick ian.d.roman...@intel.com

If the server returned BadContext, the error would just get droped on
the floor.

Fixes the piglit test glx-import-context-single-process

NOTE: This is a candidate for the 7.11 branch, but it also requires
the previous patch.

Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
 src/glx/glxcmds.c |   29 ++---
 1 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 0c77817..d3f5bf0 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -37,12 +37,12 @@
 #include glapi.h
 #include glxextensions.h
 #include indirect.h
+#include glx_error.h
 
 #ifdef GLX_DIRECT_RENDERING
 #ifdef GLX_USE_APPLEGL
 #include apple_glx_context.h
 #include apple_glx.h
-#include glx_error.h
 #else
 #include sys/time.h
 #ifdef XF86VIDMODE
@@ -589,12 +589,19 @@ __glXIsDirect(Display * dpy, GLXContextID contextID)
 
 #ifdef USE_XCB
xcb_connection_t *c = XGetXCBConnection(dpy);
+   xcb_generic_error_t *err;
xcb_glx_is_direct_reply_t *reply = xcb_glx_is_direct_reply(c,
   xcb_glx_is_direct
   (c, contextID),
-  NULL);
+  err);
 
const Bool is_direct = (reply != NULL  reply-is_direct) ? True : False;
+
+   if (err != NULL) {
+  __glXSendErrorForXcb(dpy, err);
+  free(err);
+   }
+
free(reply);
 
return is_direct;
@@ -1429,7 +1436,23 @@ glXImportContextEXT(Display *dpy, GLXContextID contextID)
uint32_t screen;
Bool got_screen = False;
 
-   if (contextID == None || __glXIsDirect(dpy, contextID))
+   /* The GLX_EXT_import_context spec says:
+*
+* If contextID does not refer to a valid context, then a BadContext
+* error is generated; if contextID refers to direct rendering
+* context then no error is generated but glXImportContextEXT returns
+* NULL.
+*
+* If contextID is None, generate BadContext on the client-side.  Other
+* sorts of invalid contexts will be detected by the server in the
+* __glXIsDirect call.
+*/
+   if (contextID == None) {
+  __glXSendError(dpy, GLXBadContext, contextID, X_GLXIsDirect, false);
+  return NULL;
+   }
+
+   if (__glXIsDirect(dpy, contextID))
   return NULL;
 
opcode = __glXSetupForCommand(dpy);
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/6] i965 gen6: Transform feedback queries

[Paul Berry]

This patch series adds support for the transform feedback queries
(PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN) for
i965 Gen6.  For now, the queries are implemented using software
counters, since we don't yet have the necessary kernel support to use
the hardware counters.  (The kernel support that would be required is
the ability to save and restore GPU registers on a context switch, so
that primitives rendered by other processes would not be accidentally
counted).  We'll need to change these to hardware counters before
implementing geometry shaders or primitive restart.

In addition, patch 3/6 adds logic to re-program the SVBI registers at
the start of each new batch.  This is necessary to work around the
same kernel issue: since the kernel does not save and restore GPU
registers, we have to reprogram the SVBI registers at any time when a
context switch might have occurred; this means at the start of each
batch.

At this point transform feedback support for i965 is complete, with
the exception of fixing a few of the Piglit
EXT_transform_feedback/tessellation tests.  I think that it's
reasonable to postpone that work until a later bugfix patch, for the
following reasons:

(a) The tessellation tests that are failing are subtle edge cases
(e.g. tessellation of triangle strips flips the orientation of some
triangles, and tessellation of quads and polygons fails to preserve
the provoking vertex, causing flatshading errors).

(b) Transform feedback operates in a completely different way on Gen7,
and it's likely that some of these tessellation failures will be
unfixable on Gen7.  It seems silly to fix subtle edge cases on Gen6
that will be unfixable on Gen7, so I'd rather wait until we have
implemented transform feedback on Gen7, and then do whatever is
necessary to make Gen6 behave just as well as Gen7.

(c) Enabling transform feedback now will allow us to get valuable
feedback from the field and from Intel QA.

Accordingly, patch 6/6 unconditionally switches on the
EXT_transform_feedback extension for i965 gen6.

Note: this patch series depends on several previous patches that are
still under review on the mailing list:

- [PATCH 0/8] i965 gen6: Initial implementation of transform feedback.
- [PATCH] i965: Implement bounds checking for transform feedback output.
- [PATCH 2/2] i965 gen6: Implement rasterizer discard.

If you want to see this patch series in its proper context, you can
pull from branch xf-queries on
git://github.com/stereotype441/mesa.git.

[PATCH 1/6] mesa: Add count_tessellated_primitives() function.
[PATCH 2/6] mesa: Add a function to query whether a meta-op is in progress.
[PATCH 3/6] i965 gen6: Ensure correct transform feedback indices on new batch.
[PATCH 4/6] i965: Convert if/else to switch statements in brw_queryobj.c
[PATCH 5/6] i965 gen6: Implement transform feedback queries.
[PATCH 6/6] i965 gen6: Turn on transform feedback extension unconditionally.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/6] mesa: Add count_tessellated_primitives() function.

[Paul Berry]

This function computes the number of primitives that will be generated
when the given drawing operation is performed.  It accounts for the
tessellation that is performed on line strips, line loops, triangle
strips, triangle fans, quads, quad strips, and polygons, so it is
suitable for implementing the primitive counters needed by transform
feedback.
---
 src/mesa/vbo/vbo.h  |3 ++
 src/mesa/vbo/vbo_exec.c |   48 +++
 2 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/src/mesa/vbo/vbo.h b/src/mesa/vbo/vbo.h
index f357657..7384790 100644
--- a/src/mesa/vbo/vbo.h
+++ b/src/mesa/vbo/vbo.h
@@ -137,6 +137,9 @@ void vbo_check_buffers_are_unmapped(struct gl_context *ctx);
 
 void vbo_bind_arrays(struct gl_context *ctx);
 
+size_t
+count_tessellated_primitives(const struct _mesa_prim *prim);
+
 void GLAPIENTRY
 _es_Color4f(GLfloat r, GLfloat g, GLfloat b, GLfloat a);
 
diff --git a/src/mesa/vbo/vbo_exec.c b/src/mesa/vbo/vbo_exec.c
index e8d5b39..f1b9dd2 100644
--- a/src/mesa/vbo/vbo_exec.c
+++ b/src/mesa/vbo/vbo_exec.c
@@ -90,3 +90,51 @@ void vbo_exec_invalidate_state( struct gl_context *ctx, 
GLuint new_state )
 
_ae_invalidate_state(ctx, new_state);
 }
+
+
+/**
+ * Figure out the number of transform feedback primitives that will be output
+ * by the given _mesa_prim command, assuming that no geometry shading is done
+ * and primitive restart is not used.
+ *
+ * This is intended for use by driver back-ends in implementing the
+ * PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries.
+ */
+size_t
+count_tessellated_primitives(const struct _mesa_prim *prim)
+{
+   size_t num_primitives;
+   switch (prim-mode) {
+   case GL_POINTS:
+  num_primitives = prim-count;
+  break;
+   case GL_LINE_STRIP:
+  num_primitives = prim-count = 2 ? prim-count - 1 : 0;
+  break;
+   case GL_LINE_LOOP:
+  num_primitives = prim-count = 2 ? prim-count : 0;
+  break;
+   case GL_LINES:
+  num_primitives = prim-count / 2;
+  break;
+   case GL_TRIANGLE_STRIP:
+   case GL_TRIANGLE_FAN:
+   case GL_POLYGON:
+  num_primitives = prim-count = 3 ? prim-count - 2 : 0;
+  break;
+   case GL_TRIANGLES:
+  num_primitives = prim-count / 3;
+  break;
+   case GL_QUAD_STRIP:
+  num_primitives = prim-count = 4 ? ((prim-count / 2) - 1) * 2 : 0;
+  break;
+   case GL_QUADS:
+  num_primitives = (prim-count / 4) * 2;
+  break;
+   default:
+  assert (!Unexpected primitive type in count_tessellated_primitives);
+  num_primitives = 0;
+  break;
+   }
+   return num_primitives * prim-num_instances;
+}
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/6] mesa: Add a function to query whether a meta-op is in progress.

[Paul Berry]

This is needed by i965 to ensure that transform feedback counters are
not incremented during meta-ops.
---
 src/mesa/drivers/common/meta.c |   10 ++
 src/mesa/drivers/common/meta.h |3 +++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 1683c85..c5c59eb 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -985,6 +985,16 @@ _mesa_meta_end(struct gl_context *ctx)
 
 
 /**
+ * Determine whether Mesa is currently in a meta state.
+ */
+GLboolean
+_mesa_meta_in_progress(struct gl_context *ctx)
+{
+   return ctx-Meta-SaveStackDepth != 0;
+}
+
+
+/**
  * Convert Z from a normalized value in the range [0, 1] to an object-space
  * Z coordinate in [-1, +1] so that drawing at the new Z position with the
  * default/identity ortho projection results in the original Z value.
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 7198139..d13796e 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -69,6 +69,9 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state);
 extern void
 _mesa_meta_end(struct gl_context *ctx);
 
+extern GLboolean
+_mesa_meta_in_progress(struct gl_context *ctx);
+
 extern void
 _mesa_meta_BlitFramebuffer(struct gl_context *ctx,
GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1,
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/6] i965 gen6: Ensure correct transform feedback indices on new batch.

[Paul Berry]

We don't currently have kernel support for saving GPU registers on a
context switch, so if multiple processes are performing transform
feedback at the same time, their SVBI registers will interfere with
each other.  To avoid this situation, we keep a software shadow of the
state of the SVBI 0 register (which is the only register we use), and
re-upload it on every new batch.

The function that updates the shadow state of SVBI 0 is called
brw_update_primitive_count, since it will also be used to update the
counters for the PRIMITIVES_GENERATED and
TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries.
---
 src/mesa/drivers/dri/i965/brw_context.h  |7 +
 src/mesa/drivers/dri/i965/brw_draw.c |   33 ++
 src/mesa/drivers/dri/i965/brw_state.h|1 +
 src/mesa/drivers/dri/i965/brw_state_upload.c |1 +
 src/mesa/drivers/dri/i965/gen6_sol.c |   38 -
 5 files changed, 72 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index e8ebea8..8840a83 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -145,6 +145,7 @@ enum brw_state_id {
BRW_STATE_PROGRAM_CACHE,
BRW_STATE_STATE_BASE_ADDRESS,
BRW_STATE_HIZ,
+   BRW_STATE_SOL_INDICES,
 };
 
 #define BRW_NEW_URB_FENCE   (1  BRW_STATE_URB_FENCE)
@@ -174,6 +175,7 @@ enum brw_state_id {
 #define BRW_NEW_PROGRAM_CACHE  (1  BRW_STATE_PROGRAM_CACHE)
 #define BRW_NEW_STATE_BASE_ADDRESS (1  BRW_STATE_STATE_BASE_ADDRESS)
 #define BRW_NEW_HIZ(1  BRW_STATE_HIZ)
+#define BRW_NEW_SOL_INDICES(1  BRW_STATE_SOL_INDICES)
 
 struct brw_state_flags {
/** State update flags signalled by mesa internals */
@@ -983,6 +985,11 @@ struct brw_context
   struct gl_renderbuffer *depth_rb;
} hiz;
 
+   struct brw_sol_state {
+  uint32_t svbi_0_starting_index;
+  uint32_t svbi_0_max_index;
+   } sol;
+
uint32_t render_target_format[MESA_FORMAT_COUNT];
bool format_supported_as_render_target[MESA_FORMAT_COUNT];
 };
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 6627a48..774a5ca 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -33,10 +33,12 @@
 #include main/samplerobj.h
 #include main/state.h
 #include main/enums.h
+#include main/macros.h
 #include tnl/tnl.h
 #include vbo/vbo_context.h
 #include swrast/swrast.h
 #include swrast_setup/swrast_setup.h
+#include drivers/common/meta.h
 
 #include brw_draw.h
 #include brw_defines.h
@@ -377,6 +379,34 @@ static void brw_postdraw_set_buffers_need_resolve(struct 
brw_context *brw)
}
 }
 
+/**
+ * Update internal counters based on the the drawing operation described in
+ * prim.
+ */
+static void
+brw_update_primitive_count(struct brw_context *brw,
+   const struct _mesa_prim *prim)
+{
+   uint32_t count = count_tessellated_primitives(prim);
+   if (brw-intel.ctx.TransformFeedback.CurrentObject-Active) {
+  /* Update brw-sol.svbi_0_max_index to reflect the amount by which the
+   * hardware is going to increment SVBI 0 when this drawing operation
+   * occurs.  This is necessary because the kernel does not (yet) save and
+   * restore GPU registers when context switching, so we'll need to be
+   * able to reload SVBI 0 with the correct value in case we have to start
+   * a new batch buffer.
+   */
+  unsigned svbi_postincrement_value =
+ brw-gs.prog_data-svbi_postincrement_value;
+  uint32_t space_avail =
+ (brw-sol.svbi_0_max_index - brw-sol.svbi_0_starting_index)
+ / svbi_postincrement_value;
+  uint32_t primitives_written = MIN2 (space_avail, count);
+  brw-sol.svbi_0_starting_index +=
+ svbi_postincrement_value * primitives_written;
+   }
+}
+
 /* May fail if out of video memory for texture or vbo upload, or on
  * fallback conditions.
  */
@@ -498,6 +528,9 @@ retry:
}
 }
   }
+
+  if (!_mesa_meta_in_progress(ctx))
+ brw_update_primitive_count(brw, prim[i]);
}
 
if (intel-always_flush_batch)
diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
b/src/mesa/drivers/dri/i965/brw_state.h
index a3a470f..d271569 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -92,6 +92,7 @@ extern const struct brw_tracked_state gen6_gs_state;
 extern const struct brw_tracked_state gen6_renderbuffer_surfaces;
 extern const struct brw_tracked_state gen6_sampler_state;
 extern const struct brw_tracked_state gen6_scissor_state;
+extern const struct brw_tracked_state gen6_sol_indices;
 extern const struct brw_tracked_state gen6_sol_surface;
 extern const struct brw_tracked_state gen6_sf_state;
 extern const struct brw_tracked_state gen6_sf_vp;
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 

[Mesa-dev] [PATCH 4/6] i965: Convert if/else to switch statements in brw_queryobj.c

[Paul Berry]

Previously, i965 only supported two query types: GL_TIME_ELAPSED_EXT
and GL_SAMPLES_PASSED_ARB, and it distinguished between the two using
if/else statements that compared query-Base.Target to
GL_TIME_ELAPSED_EXT.

This patch changes the if/else statements to switch statements so that
we can add more query types without having to have a chain of
else-ifs.
---
 src/mesa/drivers/dri/i965/brw_queryobj.c |   36 +-
 1 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index 8875541..3cbd3a6 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -60,16 +60,24 @@ brw_queryobj_get_results(struct gl_context *ctx,
 
drm_intel_bo_map(query-bo, false);
results = query-bo-virtual;
-   if (query-Base.Target == GL_TIME_ELAPSED_EXT) {
+   switch (query-Base.Target) {
+   case GL_TIME_ELAPSED_EXT:
   if (intel-gen = 6)
 query-Base.Result += 80 * (results[1] - results[0]);
   else
 query-Base.Result += 1000 * ((results[1]  32) - (results[0]  32));
-   } else {
+  break;
+
+   case GL_SAMPLES_PASSED_ARB:
   /* Map and count the pixels from the current query BO */
   for (i = query-first_index; i = query-last_index; i++) {
 query-Base.Result += results[i * 2 + 1] - results[i * 2];
   }
+  break;
+
+   default:
+  assert (!Unrecognized query target in brw_queryobj_get_results());
+  break;
}
drm_intel_bo_unmap(query-bo);
 
@@ -108,7 +116,8 @@ brw_begin_query(struct gl_context *ctx, struct 
gl_query_object *q)
struct intel_context *intel = intel_context(ctx);
struct brw_query_object *query = (struct brw_query_object *)q;
 
-   if (query-Base.Target == GL_TIME_ELAPSED_EXT) {
+   switch (query-Base.Target) {
+   case GL_TIME_ELAPSED_EXT:
   drm_intel_bo_unreference(query-bo);
   query-bo = drm_intel_bo_alloc(intel-bufmgr, timer query,
 4096, 4096);
@@ -136,7 +145,9 @@ brw_begin_query(struct gl_context *ctx, struct 
gl_query_object *q)
  OUT_BATCH(0);
  ADVANCE_BATCH();
   }
-   } else {
+  break;
+
+   case GL_SAMPLES_PASSED_ARB:
   /* Reset our driver's tracking of query state. */
   drm_intel_bo_unreference(query-bo);
   query-bo = NULL;
@@ -145,6 +156,11 @@ brw_begin_query(struct gl_context *ctx, struct 
gl_query_object *q)
 
   brw-query.obj = query;
   intel-stats_wm++;
+  break;
+
+   default:
+  assert (!Unrecognized query target in brw_begin_query());
+  break;
}
 }
 
@@ -158,7 +174,8 @@ brw_end_query(struct gl_context *ctx, struct 
gl_query_object *q)
struct intel_context *intel = intel_context(ctx);
struct brw_query_object *query = (struct brw_query_object *)q;
 
-   if (query-Base.Target == GL_TIME_ELAPSED_EXT) {
+   switch (query-Base.Target) {
+   case GL_TIME_ELAPSED_EXT:
   if (intel-gen = 6) {
  BEGIN_BATCH(4);
  OUT_BATCH(_3DSTATE_PIPE_CONTROL);
@@ -184,7 +201,9 @@ brw_end_query(struct gl_context *ctx, struct 
gl_query_object *q)
   }
 
   intel_batchbuffer_flush(intel);
-   } else {
+  break;
+
+   case GL_SAMPLES_PASSED_ARB:
   /* Flush the batchbuffer in case it has writes to our query BO.
* Have later queries write to a new query BO so that further rendering
* doesn't delay the collection of our results.
@@ -200,6 +219,11 @@ brw_end_query(struct gl_context *ctx, struct 
gl_query_object *q)
   brw-query.obj = NULL;
 
   intel-stats_wm--;
+  break;
+
+   default:
+  assert (!Unrecognized query target in brw_end_query());
+  break;
}
 }
 
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/6] i965 gen6: Implement transform feedback queries.

[Paul Berry]

This patch adds software-based PRIMITIVES_GENERATED and
TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries that work by keeping
track of the number of primitives that are sent down the pipeline, and
adjusting as necessary to account for the way each primitive type is
tessellated.

In the long run we'll want to replace this with a hardware-based
implementation, because the software approach won't work with geometry
shaders or primitive restart.  However, at the moment, we don't have
the necessary kernel support to implement a hardware-based query (we
would need the kernel to save GPU registers when context switching, so
that drawing performed by another process doesn't get counted).

Fixes Piglit tests EXT_transform_feedback/query-primitives_generated-*
and EXT_transform_feedback/query-primitives-written-*.
---
 src/mesa/drivers/dri/i965/brw_context.h  |2 +
 src/mesa/drivers/dri/i965/brw_draw.c |4 ++
 src/mesa/drivers/dri/i965/brw_queryobj.c |   48 ++
 3 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 8840a83..15a781b 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -988,6 +988,8 @@ struct brw_context
struct brw_sol_state {
   uint32_t svbi_0_starting_index;
   uint32_t svbi_0_max_index;
+  uint32_t primitives_generated;
+  uint32_t primitives_written;
} sol;
 
uint32_t render_target_format[MESA_FORMAT_COUNT];
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 774a5ca..082bb9a 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -388,6 +388,7 @@ brw_update_primitive_count(struct brw_context *brw,
const struct _mesa_prim *prim)
 {
uint32_t count = count_tessellated_primitives(prim);
+   brw-sol.primitives_generated += count;
if (brw-intel.ctx.TransformFeedback.CurrentObject-Active) {
   /* Update brw-sol.svbi_0_max_index to reflect the amount by which the
* hardware is going to increment SVBI 0 when this drawing operation
@@ -404,6 +405,9 @@ brw_update_primitive_count(struct brw_context *brw,
   uint32_t primitives_written = MIN2 (space_avail, count);
   brw-sol.svbi_0_starting_index +=
  svbi_postincrement_value * primitives_written;
+
+  /* And update the TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN query. */
+  brw-sol.primitives_written += primitives_written;
}
 }
 
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c 
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index 3cbd3a6..fac7070 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -75,6 +75,14 @@ brw_queryobj_get_results(struct gl_context *ctx,
   }
   break;
 
+   case GL_PRIMITIVES_GENERATED:
+   case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
+  /* We don't actually query the hardware for this value, so query-bo
+   * should always be NULL and execution should never reach here.
+   */
+  assert (!Unreachable);
+  break;
+
default:
   assert (!Unrecognized query target in brw_queryobj_get_results());
   break;
@@ -158,6 +166,20 @@ brw_begin_query(struct gl_context *ctx, struct 
gl_query_object *q)
   intel-stats_wm++;
   break;
 
+   case GL_PRIMITIVES_GENERATED:
+  /* We don't actually query the hardware for this value; we keep track of
+   * it a software counter.  So just reset the counter.
+   */
+  brw-sol.primitives_generated = 0;
+  break;
+
+   case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
+  /* We don't actually query the hardware for this value; we keep track of
+   * it a software counter.  So just reset the counter.
+   */
+  brw-sol.primitives_written = 0;
+  break;
+
default:
   assert (!Unrecognized query target in brw_begin_query());
   break;
@@ -221,6 +243,32 @@ brw_end_query(struct gl_context *ctx, struct 
gl_query_object *q)
   intel-stats_wm--;
   break;
 
+   case GL_PRIMITIVES_GENERATED:
+  /* We don't actually query the hardware for this value; we keep track of
+   * it in a software counter.  So just read the counter and store it in
+   * the query object.
+   */
+  query-Base.Result = brw-sol.primitives_generated;
+
+  /* And set brw-query.obj to NULL so that this query won't try to wait
+   * for any rendering to complete.
+   */
+  query-bo = NULL;
+  break;
+
+   case GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN:
+  /* We don't actually query the hardware for this value; we keep track of
+   * it in a software counter.  So just read the counter and store it in
+   * the query object.
+   */
+  query-Base.Result = brw-sol.primitives_written;
+
+  /* And set brw-query.obj to NULL so that this query won't try to wait
+   * for any 

[Mesa-dev] [PATCH 6/6] i965 gen6: Turn on transform feedback extension unconditionally.

[Paul Berry]

Previously, we only enabled transform feedback when
MESA_GL_VERSION_OVERRIDE was 3.0 or greater, since transform feedback
support was not completely finished, so it didn't make sense to
advertise support for it unless absolutely necessary.

Now that transform feedback is fully implemented on gen6, we can
enable this extension unconditionally.
---
 src/mesa/drivers/dri/intel/intel_extensions.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c 
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 2daa2c8..0f2f956 100644
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -104,7 +104,7 @@ intelInitExtensions(struct gl_context *ctx)
   ctx-Const.GLSLVersion = 120;
_mesa_override_glsl_version(ctx);
 
-   if (intel-gen == 6  override_version = 30)
+   if (intel-gen == 6)
   ctx-Extensions.EXT_transform_feedback = true;
 
if (intel-gen = 5)
-- 
1.7.6.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] vertex array regression

[Marek Olšák]

2011/12/19 Mathias Fröhlich mathias.froehl...@gmx.net:

 Brian,

 On Monday, December 19, 2011 17:01:07 you wrote:
 I still don't get what the purpose of the special mapping of the last
 four/five elements is all about.  Can you explain that?

 As far as I can see the last ones should not map to anything.
 The map is used only in fixed function mode. And there these arrays should not
 show up as inputs to any fixed function shader. I think that the purpose of 
 the
 previous mapping was just to fill in anything. The changes I did serve exactly
 this purpose.

 But I agree that here should not be any mapping of these attributes in this
 mode. Attached is a small change that is probably a more clean solution to
 this mapping problem.

 The change passes a quick r600g piglit test.

 Yeah, I see how the incorrect varying_inputs values was causing
 _NEW_ARRAY to get set, thus hiding the problem.  The solution looks
 correct, but I'm a little worried about performance, as is mentioned
 in the comment.

 Marek, made that change back in March.  Maybe he can take a look at
 this too.
 I cannot comment on this, since I do not see a performance regression on my
 use cases.
 Marek?

The problem back in March and earlier was that the vertex array state
was completely recomputed for each draw call even if the user did not
change any state at all! There was the validation in the vbo module
and then in st/mesa, which were basically needless. It turned out to
be the major bottleneck in the game Torcs (in the track called Forza).
I checked the source code of Torcs and it confirmed my findings. There
was a loop that looked like this:

for (i = 0; i  very large number; i++) glDrawElements(...);

From that point, it became clear that Mesa is underperforming and that
it's fixable. Then I came up with a set of patches which did not
address the issue completely, but some cases (like with Torcs) were
optimized (well maybe not cleanly as it caused a few regressions too).
There still is a lot of cases where the vertex array state is
recomputed needlessly, so it still is an open issue. I did not fully
understand how the entire vbo module works and why so much state
validation was being done there. Even today, drivers have almost no
way to know in draw_prims whether the vertex array state is _really_
changed, because core Mesa almost always says yes, it changed of
course! why wouldn't it? Sadly, performance is usually being put
aside and energy is put into more important stuff like new features. I
was profiling Mesa quite extensively because there was simply nothing
better to do for r300g. I don't expect that's the case with the other
drivers.

Back on topic. The reason why you don't see a performance regression may be:
1) The vertex array state management is not the bottleneck.
2) You already hit the slowest path, that is recomputing the state
completely in every draw call.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] i965 gen6: Transform feedback queries

[Kenneth Graunke]

On 12/19/2011 04:18 PM, Paul Berry wrote:
[snip]
 - [PATCH 0/8] i965 gen6: Initial implementation of transform feedback.
 - [PATCH] i965: Implement bounds checking for transform feedback output.
 - [PATCH 2/2] i965 gen6: Implement rasterizer discard.
 
 If you want to see this patch series in its proper context, you can
 pull from branch xf-queries on
 git://github.com/stereotype441/mesa.git.
 
 [PATCH 1/6] mesa: Add count_tessellated_primitives() function.
 [PATCH 2/6] mesa: Add a function to query whether a meta-op is in progress.
 [PATCH 3/6] i965 gen6: Ensure correct transform feedback indices on new batch.
 [PATCH 4/6] i965: Convert if/else to switch statements in brw_queryobj.c
 [PATCH 5/6] i965 gen6: Implement transform feedback queries.
 [PATCH 6/6] i965 gen6: Turn on transform feedback extension unconditionally.

For the series:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] mesa: Set the correct ctx-NewState bitfield for rasterizer discard.

[Marek Olšák]

On Thu, Dec 15, 2011 at 7:21 PM, Paul Berry stereotype...@gmail.com wrote:
 On 15 December 2011 08:02, Eric Anholt e...@anholt.net wrote:

 On Thu, 15 Dec 2011 00:00:49 +0100, Marek Olšák mar...@gmail.com wrote:
  On Wed, Dec 14, 2011 at 11:25 PM, Paul Berry stereotype...@gmail.com
  wrote:
   (c) Do nothing, and rely on programmers to remember that RasterDiscard
   is an
   exception to the usual correspondence between dirty bits and
   substructures
   of gl_context.
  
   I'm really not comfortable with (c) because of the risk of future
   bugs.  I
   suppose I could be talked into (b) if there's popular support for it,
   but
   it's not my favourite, because as I said earlier, I think there are
   actually
   a lot of good reasons to think of rasterizer discard as related to
   transform
   feedback.  My preference is to do (a).
 
  (d) Rework the _NEW_* flags such that they roughly match hardware
  state groups, not OpenGL state groups. Direct3D 11 and Gallium are two
  examples of how it could be done.

 The problem is that everyone disagrees on what hardware state group a
 piece of state is in.  On i965, rasterizer discard is really in the
 transform feedback state -- the SOL (transform feedback) unit on gen7,
 and the GS on gen6.


 I have been thinking about this more this morning, and I have an idea for
 how to accomplish (d) that I think would address this problem.  It's not a
 trivial change, but it's something we could implement incrementally, so we
 apply it to rasterizer discard now, and over time extend it to cover other
 pieces of state.  Here's the idea:

 The key problem is that there are so many distinct pieces of state that we
 could never possibly assign a separate bit to each one--we would run out of
 space in the bitfield.  So instead of having core Mesa decide how they are
 grouped (and, inevitably, wind up grouping them in a way that doesn't work
 well for some drivers), let each driver decide how they are grouped.  The
 drivers communicate this grouping to core Mesa by populating a new data
 structure (at initialization time) called ctx-StateFlags.  ctx-StateFlags
 has an entry for each distinct piece of state, which tells which bits in
 ctx-NewState should be set when that state changes.

 So, for example, in BeginTransformFeedback() and EndTransformFeedback(),
 instead of doing this:

 FLUSH_VERTICES(ctx, _NEW_TRANSFORM_FEEDBACK);

 We would do this:

 FLUSH_VERTICES(ctx, ctx-StateFlags-TransformFeedback_Active);

 In PauseTransformFeedback() and ResumeTransformFeedback() we would do:

 FLUSH_VERTICES(ctx, ctx-StateFlags-TransformFeedback_Paused);

 And in enable.c, when rasterizer discard is turned on or off, we would do:

 FLUSH_VERTICES(ctx, ctx-StateFlags-RasterizerDiscard);

 In the i965 driver, where all of these features map to the GS stage of the
 pipeline, we would initialize TransformFeedback_Active,
 TransformFeedback_Paused, and RasterizerDiscard all to the same value.  In
 the r600 driver, where rasterizer discard is implemented using face culling,
 StateFlags-RasterizerDiscard would indicate a totally different bit than
 those used for transform feedback.

 In the short term, we could implement this technique just for rasterizer
 discard, to address the differences between r600 and i965 that we're
 discussing in this email thread.  In the long term, our goal would be to
 replace all of the _NEW_* constants with a fine-grained set of values in
 StateFlags.  Once we've done that, each driver can set up StateFlags in a
 way that precisely matches how state is grouped for that particular piece of
 hardware.

 What do y'all think?  If there's support for this idea I'd be glad to make
 an RFC patch.

I like this idea very much. However, there is a catch that some _NEW
flags are used for core Mesa, others are used for the vbo module,
others are used for generating fixed function programs, others just
notify about a change in constant buffers (e.g. the gl_* variables in
GLSL) and so on, and finally, most are consumed by drivers to generate
states. I am sure we can do this incrementally though and doing the
easy stuff first.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: consolidate texstore functions

[Brian Paul]

From: Brian Paul bri...@vmware.com

The code for storing 1D, 2D and 3D tex images (whole or sub-images) was
all pretty similar.  This consolidates those six paths.
---
 src/mesa/main/texstore.c |  475 ++
 1 files changed, 144 insertions(+), 331 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index fb1ad04..10cd751 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -4565,9 +4565,128 @@ get_read_write_mode(GLenum userFormat, gl_format 
texFormat)
   return GL_MAP_WRITE_BIT;
 }
 
+
+/**
+ * Helper function for storing 1D, 2D, 3D whole and subimages into texture
+ * memory.
+ * The source of the image data may be user memory or a PBO.  In the later
+ * case, we'll map the PBO, copy from it, then unmap it.
+ */
+static void
+store_texsubimage(struct gl_context *ctx,
+  struct gl_texture_image *texImage,
+  GLint xoffset, GLint yoffset, GLint zoffset,
+  GLint width, GLint height, GLint depth,
+  GLenum format, GLenum type, const GLvoid *pixels,
+  const struct gl_pixelstore_attrib *packing,
+  const char *caller)
+
+{
+   const GLbitfield mapMode = get_read_write_mode(format, texImage-TexFormat);
+   const GLenum target = texImage-TexObject-Target;
+   GLboolean success = GL_FALSE;
+   GLuint dims, slice, numSlices = 1, sliceOffset = 0;
+   GLint srcImageStride = 0;
+   const GLubyte *src;
+
+   assert(xoffset + width = texImage-Width);
+   assert(yoffset + height = texImage-Height);
+   assert(zoffset + depth = texImage-Depth);
+
+   switch (target) {
+   case GL_TEXTURE_1D:
+  dims = 1;
+  break;
+   case GL_TEXTURE_2D_ARRAY:
+   case GL_TEXTURE_3D:
+  dims = 3;
+  break;
+   default:
+  dims = 2;
+   }
+
+   /* get pointer to src pixels (may be in a pbo which we'll map here) */
+   src = (const GLubyte *)
+  _mesa_validate_pbo_teximage(ctx, dims, width, height, depth,
+  format, type, pixels, packing, caller);
+   if (!pixels)
+  return;
+
+   /* compute slice info (and do some sanity checks) */
+   switch (target) {
+   case GL_TEXTURE_1D:
+  assert(height == 1);
+  assert(depth == 1);
+  assert(yoffset == 0);
+  assert(zoffset == 0);
+  break;
+   case GL_TEXTURE_1D_ARRAY:
+  assert(depth == 1);
+  assert(zoffset == 0);
+  numSlices = height;
+  sliceOffset = yoffset;
+  height = 1;
+  yoffset = 0;
+  srcImageStride = _mesa_image_row_stride(packing, width, format, type);
+  break;
+   case GL_TEXTURE_2D_ARRAY:
+  numSlices = depth;
+  sliceOffset = zoffset;
+  depth = 1;
+  zoffset = 0;
+  srcImageStride = _mesa_image_image_stride(packing, width, height,
+format, type);
+  break;
+   case GL_TEXTURE_3D:
+  /* we'll store 3D images as a series of slices */
+  numSlices = depth;
+  sliceOffset = zoffset;
+  srcImageStride = _mesa_image_image_stride(packing, width, height,
+format, type);
+  break;
+   default:
+  /* GL_TEXTURE_2D, cube face, etc */
+  ;
+   }
+
+   assert(numSlices == 1 || srcImageStride != 0);
+
+   for (slice = 0; slice  numSlices; slice++) {
+  GLubyte *dstMap;
+  GLint dstRowStride;
+
+  ctx-Driver.MapTextureImage(ctx, texImage,
+  slice + sliceOffset,
+  xoffset, yoffset, width, height,
+  mapMode, dstMap, dstRowStride);
+  if (dstMap) {
+ success = _mesa_texstore(ctx, 2, texImage-_BaseFormat,
+  texImage-TexFormat,
+  0, 0, 0,  /* dstX/Y/Zoffset */
+  dstRowStride,
+  dstMap,
+  width, height, 1,  /* w, h, d */
+  format, type, src, packing);
+
+ ctx-Driver.UnmapTextureImage(ctx, texImage, slice + sliceOffset);
+  }
+
+  src += srcImageStride;
+
+  if (!success)
+ break;
+   }
+
+   if (!success)
+  _mesa_error(ctx, GL_OUT_OF_MEMORY, %s, caller);
+
+   _mesa_unmap_teximage_pbo(ctx, packing);
+}
+
+
+
 /**
- * This is the software fallback for Driver.TexImage1D().
- * \sa _mesa_store_teximage2d()
+ * This is the fallback for Driver.TexImage1D().
  */
 void
 _mesa_store_teximage1d(struct gl_context *ctx, GLenum target, GLint level,
@@ -4578,13 +4697,6 @@ _mesa_store_teximage1d(struct gl_context *ctx, GLenum 
target, GLint level,
struct gl_texture_object *texObj,
struct gl_texture_image *texImage)
 {
-   const GLbitfield rwMode = get_read_write_mode(format, texImage-TexFormat);
-   GLubyte *dstMap;
-   GLint dstRowStride;
-   GLboolean success;
-
-   

Re: [Mesa-dev] vertex array regression

[Mathias Fröhlich]

Marek,

On Tuesday, December 20, 2011 01:40:46 Marek Olšák wrote:
 The problem back in March and earlier was that the vertex array state
 was completely recomputed for each draw call even if the user did not
 change any state at all! There was the validation in the vbo module
 and then in st/mesa, which were basically needless. It turned out to
 be the major bottleneck in the game Torcs (in the track called Forza).
 I checked the source code of Torcs and it confirmed my findings. There
 was a loop that looked like this:
 
 for (i = 0; i  very large number; i++) glDrawElements(...);
 
 From that point, it became clear that Mesa is underperforming and that
 it's fixable. Then I came up with a set of patches which did not
 address the issue completely, but some cases (like with Torcs) were
 optimized (well maybe not cleanly as it caused a few regressions too).
 There still is a lot of cases where the vertex array state is
 recomputed needlessly, so it still is an open issue. I did not fully
 understand how the entire vbo module works and why so much state
 validation was being done there. Even today, drivers have almost no
 way to know in draw_prims whether the vertex array state is _really_
 changed, because core Mesa almost always says yes, it changed of
 course! why wouldn't it? Sadly, performance is usually being put
 aside and energy is put into more important stuff like new features. I
 was profiling Mesa quite extensively because there was simply nothing
 better to do for r300g. I don't expect that's the case with the other
 drivers.
 
 Back on topic. The reason why you don't see a performance regression may
 be: 1) The vertex array state management is not the bottleneck.
 2) You already hit the slowest path, that is recomputing the state
 completely in every draw call.

Well, in general, to me performance *is* a feature. At least for this kind of 
software like an OpenGL stack.
But correctness is not just a feature, correctness is a hard requirement.
So I believe I am all with you...

Let me explain, the reason why I am starting work on the vertex arrays is that 
I think this is one of the major bottlenecks in the draw path that we have 
today.
I think that the array object should behave more like a state that could be 
used to do just the required things to be ready for the draw code path.
The first step towards this was to make the array object an array of client 
arrays. Then start exploiting more of bitmask/ffs driven loops to reduce the 
overhead of iterating over all client arrays on almost every draw. Being able 
to accumulate changed arrays in this kind of flag values is something that 
could be done now. I have a proof of concept implementation sitting around 
here that updates the traditional client array pointers used in vbo_draw in a 
lazy way based on an enabled bitmasks and iterating only on the changed values 
instead of all. Also we could really derive from the generic array object 
implementation for the old style vbo_draw and an other implementation for a 
gallium driver path where we are really able to track changes in the array cso 
thats currently unconditional application to the gallium state could then 
probably be pulled out of the draw path for the gallium drivers, which I 
expect a major win for plenty of use cases...

So far to what could be done. But at least to me, experience shows that I 
better do this kind of stuff, which is on the first front to the OpenGL api 
specs and also used in so different drivers in so different ways, with very 
small increments. So this current increment is trying to get back to a stable 
state past the array change.

Ok, back to topic, so have I understood right? You have fixed torcs not to use 
the slow path anymore? Which old version is the one still having this issue?
Do you have any test program that could be used to see the impact of this kind 
of change?

Also your comment mentions that the _Tnl program already cares for 
invalidating the required state. Do you remember where this happend? May be we 
could utilize this place to trigger state invalidation then?

Thanks

Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/13] glx: Make __glXSendError available in non-Apple builds

[Jeremy Huddleston]

6, 7, and 13 look good to me, but I haven't tested them yet.

Reviewed-by: Jeremy Huddleston jerem...@apple.com

On Dec 16, 2011, at 11:55 AM, Ian Romanick wrote:

 From: Ian Romanick ian.d.roman...@intel.com
 
 Signed-off-by: Ian Romanick ian.d.roman...@intel.com
 Cc: Jeremy Huddleston jerem...@apple.com
 ---
 src/glx/Makefile  |1 +
 src/glx/apple/Makefile|2 +-
 src/glx/apple/glx_error.c |   67 -
 src/glx/apple/glx_error.h |   33 --
 src/glx/glx_error.c   |   67 +
 src/glx/glx_error.h   |   33 ++
 6 files changed, 102 insertions(+), 101 deletions(-)
 delete mode 100644 src/glx/apple/glx_error.c
 delete mode 100644 src/glx/apple/glx_error.h
 create mode 100644 src/glx/glx_error.c
 create mode 100644 src/glx/glx_error.h
 
 diff --git a/src/glx/Makefile b/src/glx/Makefile
 index dd96973..183ffb1 100644
 --- a/src/glx/Makefile
 +++ b/src/glx/Makefile
 @@ -15,6 +15,7 @@ SOURCES = \
 glxconfig.c \
 glxcmds.c \
 glxcurrent.c \
 +   glx_error.c \
 glxext.c \
 glxextensions.c \
 indirect_glx.c \
 diff --git a/src/glx/apple/Makefile b/src/glx/apple/Makefile
 index 6868d28..66e6658 100644
 --- a/src/glx/apple/Makefile
 +++ b/src/glx/apple/Makefile
 @@ -39,7 +39,7 @@ SOURCES = \
   ../compsize.c \
   ../glxconfig.c \
   glx_empty.c \
 - glx_error.c \
 + ../glx_error.c \
   ../glx_pbuffer.c \
   ../glx_query.c \
   ../glxcmds.c \
 diff --git a/src/glx/apple/glx_error.c b/src/glx/apple/glx_error.c
 deleted file mode 100644
 index d44a80c..000
 --- a/src/glx/apple/glx_error.c
 +++ /dev/null
 @@ -1,67 +0,0 @@
 -/*
 - Copyright (c) 2009 Apple Inc.
 - 
 - Permission is hereby granted, free of charge, to any person
 - obtaining a copy of this software and associated documentation files
 - (the Software), to deal in the Software without restriction,
 - including without limitation the rights to use, copy, modify, merge,
 - publish, distribute, sublicense, and/or sell copies of the Software,
 - and to permit persons to whom the Software is furnished to do so,
 - subject to the following conditions:
 - 
 - The above copyright notice and this permission notice shall be
 - included in all copies or substantial portions of the Software.
 - 
 - THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 - NONINFRINGEMENT.  IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT
 - HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 - WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 - OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 - DEALINGS IN THE SOFTWARE.
 - 
 - Except as contained in this notice, the name(s) of the above
 - copyright holders shall not be used in advertising or otherwise to
 - promote the sale, use or other dealings in this Software without
 - prior written authorization.
 -*/
 -#include stdbool.h
 -#include assert.h
 -#include X11/Xlibint.h
 -#include X11/extensions/extutil.h
 -#include X11/extensions/Xext.h
 -#include glxclient.h
 -#include glx_error.h
 -
 -void
 -__glXSendError(Display * dpy, int errorCode, unsigned long resourceID,
 -   unsigned long minorCode, bool coreX11error)
 -{
 -   struct glx_display *glx_dpy = __glXInitialize(dpy);
 -   struct glx_context *gc = __glXGetCurrentContext();
 -   xError error;
 -
 -   assert(glx_dpy);
 -   assert(gc);
 -
 -   LockDisplay(dpy);
 -
 -   error.type = X_Error;
 -
 -   if (coreX11error) {
 -  error.errorCode = errorCode;
 -   }
 -   else {
 -  error.errorCode = glx_dpy-codes-first_error + errorCode;
 -   }
 -
 -   error.sequenceNumber = dpy-request;
 -   error.resourceID = resourceID;
 -   error.minorCode = minorCode;
 -   error.majorCode = gc ? gc-majorOpcode : 0;
 -
 -   _XError(dpy, error);
 -
 -   UnlockDisplay(dpy);
 -}
 diff --git a/src/glx/apple/glx_error.h b/src/glx/apple/glx_error.h
 deleted file mode 100644
 index 6ba2f85..000
 --- a/src/glx/apple/glx_error.h
 +++ /dev/null
 @@ -1,33 +0,0 @@
 -/*
 - Copyright (c) 2009 Apple Inc.
 - 
 - Permission is hereby granted, free of charge, to any person
 - obtaining a copy of this software and associated documentation files
 - (the Software), to deal in the Software without restriction,
 - including without limitation the rights to use, copy, modify, merge,
 - publish, distribute, sublicense, and/or sell copies of the Software,
 - and to permit persons to whom the Software is furnished to do so,
 - subject to the following conditions:
 - 
 - The above copyright notice and this permission notice shall be
 - included in all copies or substantial portions of the Software.
 - 
 - THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 - EXPRESS OR IMPLIED, INCLUDING BUT NOT 

Re: [Mesa-dev] [PATCH 5/6] vl: Remove most members of pipe_video_decoder

[Maarten Lankhorst]

On 12/19/2011 11:46 PM, Andy Furniss wrote:
 Maarten Lankhorst wrote:
 Hey Andy,

 On 12/19/2011 10:17 PM, Andy Furniss wrote:
 Andy Furniss wrote:

 I compiled with -O0 but the backtraces are different - maybe there is
 some randomness.

 Remembered to attach them this time :-)
 Thanks, but nothing seems to be obviously wrong there. I don't suppose you 
 could find a small sample file that would trigger the problem?

 I'll try, but I don't think I'll have much luck.

 I think this one may need a disk involved - maybe also libdvdcss (I can 
 reproduce with different versions of mplayer and softpipe).
Well, I found a video that appears to fail in a similar way to one of your 
failure modes, they could both be the same but showing in different ways.

~Maarten
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] linker: fix strdup memory leak

[Pekka Paalanen]

On Mon, 19 Dec 2011 11:02:31 -0800
Kenneth Graunke kenn...@whitecape.org wrote:

 On 12/19/2011 05:23 AM, Pekka Paalanen wrote:
  On Fri, 16 Dec 2011 10:46:11 -0800
  Ian Romanick i...@freedesktop.org wrote:
  
  On 12/14/2011 11:26 PM, Pekka Paalanen wrote:
  string_to_uint_map::put() already does a strdup() for the key
  argument, so we leak the memory allocated by strdup() in
  link_uniforms.cpp.
 
  Remove the extra strdup(), fixes a few Valgrind detected leaks.
 
  Have you run piglit on this?  I seem to recall adding the extra
  strdup for a reason.  The hash table keeps a copy of the key
  pointer passed to it, and the underlying object may be deleted
  before the hash table is deleted.  This can happen if the back-end
  optimizes some uniforms away after the linker has generated the
  list of active uniforms.  I'm pretty sure there were one or two
  test cases that hit this on i965.
  
  Sorry, I didn't. Finally got piglit running, though readPixSanity
  failed on stencil values. Anyway it's running all.tests now for the
  upstream Mesa master, and then I'll run it with my patches.
 
 For future reference, you probably want to use quick.tests.  It skips
 valgrind and doesn't iterate over every single visual, so it takes a
 fraction of the time but still runs basically all the tests.

Thanks, I killed the first run after 17 hours. From the README I
gathered that quick.tests was somehow lacking and all.tests would be
preferable. Also, I had no idea of possible running times or what
significantly there meant.

- pq
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev