[Mesa-dev] Question regarding cs_gem_write_reloc in radeon_cs_gem.c

2012-06-15 Thread Miguel Lopes Santos Ramos
Hi all,

I'm trying to learn to program radeons in assembly in Linux and
already got help once in this mailing list.

I'm programming in C++ using the kernel DRM ioctls directly because
libdrm appears to be a thin wrapper around these (for my purpose,
which is using the GPU for computing), but in doing so, I need to
understand what libdrm is doing.

Now, the cs_gem_write_reloc function, emits two dwords which encode a
relocation and adds information on that relocation to an array which
is passed to the kernel.
The function goes to some length to make sure a single
drm_radeon_cs_reloc structure is passed to the kernel for each buffer
object.

Now, I'm trying to understand what are the constraints, I don't know
what is the desired behaviour.

This function begins with:

 if ((read_domain && write_domain) || (!read_domain && !write_domain)) {
/* in one CS a bo can only be in read or write domain but not
 * in read & write domain at the same sime
 */

Now, the comment seems to say one thing whereas the if-condition seems
to say the opposite. Am I mistaken? Which is the desired behaviour,
that of the comment or that of the code?

Then, the code block within if (reloc->handle == bo->handle) { ... }
is even more confusing to me.
For instance, the following line:

reloc->flags |= (flags & reloc->flags);

This seems to be a no-op. Anyway, I'm not so worried about these flags
which appear never to be used...
But what are really the constraints for this read_domains and write_domain?


Thank you very much,

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


Re: [Mesa-dev] Question regarding cs_gem_write_reloc in radeon_cs_gem.c

2012-06-15 Thread Marek Olšák
On Fri, Jun 15, 2012 at 3:15 PM, Miguel Lopes Santos Ramos
 wrote:
> Hi all,
>
> I'm trying to learn to program radeons in assembly in Linux and
> already got help once in this mailing list.
>
> I'm programming in C++ using the kernel DRM ioctls directly because
> libdrm appears to be a thin wrapper around these (for my purpose,
> which is using the GPU for computing), but in doing so, I need to
> understand what libdrm is doing.
>
> Now, the cs_gem_write_reloc function, emits two dwords which encode a
> relocation and adds information on that relocation to an array which
> is passed to the kernel.
> The function goes to some length to make sure a single
> drm_radeon_cs_reloc structure is passed to the kernel for each buffer
> object.
>
> Now, I'm trying to understand what are the constraints, I don't know
> what is the desired behaviour.
>
> This function begins with:
>
>  if ((read_domain && write_domain) || (!read_domain && !write_domain)) {
>        /* in one CS a bo can only be in read or write domain but not
>         * in read & write domain at the same sime
>         */
>
> Now, the comment seems to say one thing whereas the if-condition seems
> to say the opposite. Am I mistaken? Which is the desired behaviour,
> that of the comment or that of the code?
>
> Then, the code block within if (reloc->handle == bo->handle) { ... }
> is even more confusing to me.
> For instance, the following line:
>
> reloc->flags |= (flags & reloc->flags);
>
> This seems to be a no-op. Anyway, I'm not so worried about these flags
> which appear never to be used...
> But what are really the constraints for this read_domains and write_domain?

I no longer remember how exactly the libdrm CS code works. Radeon
gallium drivers don't use it, because it's inefficient and awful.

To answer your question: the kernel uses write_domain if it's
non-zero, otherwise it uses read_domains. That's it.

The Mesa code that replaces libdrm resides in the Mesa repository in:
src/gallium/winsys/radeon/drm/

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


Re: [Mesa-dev] [PATCH] st/mesa: don't do linear->srgb conversion in decompress_with_blit

2012-06-15 Thread Brian Paul
On Thu, Jun 14, 2012 at 9:16 PM, Marek Olšák  wrote:
> This fixes piglit/getteximage-formats on r600g.
>
> NOTE: This is a candidate for stable branches.
> ---
>  src/mesa/state_tracker/st_cb_texture.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c 
> b/src/mesa/state_tracker/st_cb_texture.c
> index 9d1b7f6..67c3f95 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -600,6 +600,7 @@ decompress_with_blit(struct gl_context * ctx,
>
>       u_sampler_view_default_template(&sv_temp, stObj->pt, stObj->pt->format);
>
> +      sv_temp.format = util_format_linear(sv_temp.format);
>       sv_temp.u.tex.first_level =
>       sv_temp.u.tex.last_level = texImage->Level;
>

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


Re: [Mesa-dev] [PATCH] st/mesa: make unsupported renderbuffer formats always fail as FBO incomplete

2012-06-15 Thread Brian Paul
On Thu, Jun 14, 2012 at 7:11 PM, Marek Olšák  wrote:
> instead of failing to allocate a renderbuffer. This also improves allocation
> of MSAA renderbuffers (untested).
>
> This also fixes piglit/get-renderbuffer-internalformat with non-renderable
> formats.
> ---
>  src/mesa/state_tracker/st_cb_fbo.c |   63 
> +++-
>  1 file changed, 55 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
> b/src/mesa/state_tracker/st_cb_fbo.c
> index 953295c..5a21c8e 100644
> --- a/src/mesa/state_tracker/st_cb_fbo.c
> +++ b/src/mesa/state_tracker/st_cb_fbo.c
> @@ -72,8 +72,9 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
>    struct pipe_context *pipe = st->pipe;
>    struct pipe_screen *screen = st->pipe->screen;
>    struct st_renderbuffer *strb = st_renderbuffer(rb);
> -   enum pipe_format format;
> +   enum pipe_format format = PIPE_FORMAT_NONE;
>    struct pipe_surface surf_tmpl;
> +   unsigned nr_samples = 0;
>
>    if (internalFormat == GL_RGBA16_SNORM && strb->software) {
>       /* Special case for software accum buffers.  Otherwise, if the
> @@ -84,12 +85,55 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
>       format = PIPE_FORMAT_R16G16B16A16_SNORM;
>    }
>    else {
> -      format = st_choose_renderbuffer_format(screen, internalFormat,
> -                                             rb->NumSamples);
> -   }
> +      /* Handle multisample renderbuffers first.
> +       *
> +       * From ARB_framebuffer_object:
> +       *   If  is zero, then RENDERBUFFER_SAMPLES is set to zero.
> +       *   Otherwise  represents a request for a desired minimum
> +       *   number of samples. Since different implementations may support
> +       *   different sample counts for multisampled rendering, the actual
> +       *   number of samples allocated for the renderbuffer image is
> +       *   implementation dependent.  However, the resulting value for
> +       *   RENDERBUFFER_SAMPLES is guaranteed to be greater than or equal
> +       *   to  and no more than the next larger sample count 
> supported
> +       *   by the implementation.
> +       *
> +       * So let's find the supported number of samples closest to NumSamples.
> +       * (NumSamples == 1) is treated the same as (NumSamples == 0).
> +       */
> +      if (rb->NumSamples > 1) {
> +         unsigned i;
>
> -   if (format == PIPE_FORMAT_NONE) {
> -      return FALSE;
> +         for (i = rb->NumSamples; i < ctx->Const.MaxSamples; i++) {
> +            format = st_choose_renderbuffer_format(screen, internalFormat, 
> i);
> +
> +            if (format != PIPE_FORMAT_NONE) {
> +               rb->NumSamples = i;
> +               nr_samples = i;
> +               break;
> +            }
> +         }
> +      } else {
> +         format = st_choose_renderbuffer_format(screen, internalFormat, 0);
> +      }
> +
> +      /* There is no supported renderable pipe format for internalformat.
> +       * AllocStorage shouldn't fail because of an unsupported format,
> +       * instead, unsupported formats should cause FBO incompleteness
> +       * later, so let's set the closest sampler format we can get.
> +       * This will also cause FBO incompleteness for unsupported sample
> +       * counts, because the validation uses rb->NumSamples.
> +       */
> +      if (format == PIPE_FORMAT_NONE) {
> +         format = st_choose_format(screen, internalFormat, GL_NONE, GL_NONE,
> +                                   PIPE_TEXTURE_2D, 0,
> +                                   PIPE_BIND_SAMPLER_VIEW);
> +      }
> +
> +      assert(format != PIPE_FORMAT_NONE);
> +      if (format == PIPE_FORMAT_NONE) {
> +         return FALSE; /* shouldn't happen unless there's a bug somewhere */
> +      }
>    }
>
>    /* init renderbuffer fields */
> @@ -134,7 +178,7 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
>       template.depth0 = 1;
>       template.array_size = 1;
>       template.last_level = 0;
> -      template.nr_samples = rb->NumSamples;
> +      template.nr_samples = nr_samples;
>       if (util_format_is_depth_or_stencil(format)) {
>          template.bind = PIPE_BIND_DEPTH_STENCIL;
>       }
> @@ -455,9 +499,12 @@ st_validate_attachment(struct gl_context *ctx,
>       format = st_mesa_format_to_pipe_format(linearFormat);
>    }
>
> +   /* Check Renderbuffer->NumSamples (which is what the user expects) and
> +    * not pipe_resource::nr_samples (which might be zero if NumSamples is
> +    * unsupported). */
>    return screen->is_format_supported(screen, format,
>                                       PIPE_TEXTURE_2D,
> -                                      stObj->pt->nr_samples, bindings);
> +                                      att->Renderbuffer->NumSamples, 
> bindings);
>  }

I don't think this last bit of code will be reached for non-texture
attachments (which are allocated with RenderbufferStorage()).  At the
beginning of st_validate_attachment() we check if the 

Re: [Mesa-dev] [PATCH] st/mesa: make unsupported renderbuffer formats always fail as FBO incomplete

2012-06-15 Thread Marek Olšák
On Fri, Jun 15, 2012 at 4:07 PM, Brian Paul  wrote:
>
> I don't think this last bit of code will be reached for non-texture
> attachments (which are allocated with RenderbufferStorage()).  At the
> beginning of st_validate_attachment() we check if the attachment type
> is not a texture and return.  I guess we could remove that check, but
> then we need to get rid of stObj and get the attachment's format from
> st_renderbuffer::texture->format, etc.

I see. I've got a better idea how to deal with this. I'll send a new
patch later.

>
> Just curious: have you tried NVIDIA's or AMD's driver to see what
> happens when you try to allocate an unsupported renderbuffer format?

Yes, and you too. :)

NVIDIA and multiple formats:
http://lists.freedesktop.org/archives/mesa-dev/2012-May/021994.html

AMD and RGB9_E5:
http://lists.freedesktop.org/archives/mesa-dev/2012-May/021918.html

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


Re: [Mesa-dev] [PATCH] st/mesa: make unsupported renderbuffer formats always fail as FBO incomplete

2012-06-15 Thread Brian Paul
On Fri, Jun 15, 2012 at 8:23 AM, Marek Olšák  wrote:
> On Fri, Jun 15, 2012 at 4:07 PM, Brian Paul  wrote:
>>
>> I don't think this last bit of code will be reached for non-texture
>> attachments (which are allocated with RenderbufferStorage()).  At the
>> beginning of st_validate_attachment() we check if the attachment type
>> is not a texture and return.  I guess we could remove that check, but
>> then we need to get rid of stObj and get the attachment's format from
>> st_renderbuffer::texture->format, etc.
>
> I see. I've got a better idea how to deal with this. I'll send a new
> patch later.
>
>>
>> Just curious: have you tried NVIDIA's or AMD's driver to see what
>> happens when you try to allocate an unsupported renderbuffer format?
>
> Yes, and you too. :)
>
> NVIDIA and multiple formats:
> http://lists.freedesktop.org/archives/mesa-dev/2012-May/021994.html
>
> AMD and RGB9_E5:
> http://lists.freedesktop.org/archives/mesa-dev/2012-May/021918.html

Right.  I guess I was thinking of the multisample case.  I'm thinking
there's some pixel formats that don't work with multisampling and
wondering if things behave any differently.

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


Re: [Mesa-dev] Question regarding cs_gem_write_reloc in radeon_cs_gem.c

2012-06-15 Thread Tom Stellard
On Fri, Jun 15, 2012 at 02:15:34PM +0100, Miguel Lopes Santos Ramos wrote:
> Hi all,
> 
> I'm trying to learn to program radeons in assembly in Linux and
> already got help once in this mailing list.
> 
> I'm programming in C++ using the kernel DRM ioctls directly because
> libdrm appears to be a thin wrapper around these (for my purpose,
> which is using the GPU for computing), but in doing so, I need to
> understand what libdrm is doing.
>

r600g has preliminary support for OpenCL programs using the clover state
tracker [1].  If you are interested in using the GPU for computing I
would recommend using clover or writing your own state tracker to take
advantage of the compute code that already exists in r600g.

-Tom

[1] http://dri.freedesktop.org/wiki/GalliumCompute

> Now, the cs_gem_write_reloc function, emits two dwords which encode a
> relocation and adds information on that relocation to an array which
> is passed to the kernel.
> The function goes to some length to make sure a single
> drm_radeon_cs_reloc structure is passed to the kernel for each buffer
> object.
> 
> Now, I'm trying to understand what are the constraints, I don't know
> what is the desired behaviour.
> 
> This function begins with:
> 
>  if ((read_domain && write_domain) || (!read_domain && !write_domain)) {
> /* in one CS a bo can only be in read or write domain but not
>  * in read & write domain at the same sime
>  */
> 
> Now, the comment seems to say one thing whereas the if-condition seems
> to say the opposite. Am I mistaken? Which is the desired behaviour,
> that of the comment or that of the code?
> 
> Then, the code block within if (reloc->handle == bo->handle) { ... }
> is even more confusing to me.
> For instance, the following line:
> 
> reloc->flags |= (flags & reloc->flags);
> 
> This seems to be a no-op. Anyway, I'm not so worried about these flags
> which appear never to be used...
> But what are really the constraints for this read_domains and write_domain?
> 
> 
> Thank you very much,
> 
> --
> Miguel Ramos
> ___
> 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


[Mesa-dev] [PATCH] r600g: fix z/stencil texture creation

2012-06-15 Thread j . glisse
From: Jerome Glisse 

z or stencil texture should not be created with the z/stencil
flags for surface creation as they are intended to be bound
as texture.

Signed-off-by: Jerome Glisse 
---
 src/gallium/drivers/r600/r600_texture.c |   34 +-
 1 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_texture.c 
b/src/gallium/drivers/r600/r600_texture.c
index 5b15990..517f273 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -237,7 +237,8 @@ static void r600_texture_set_array_mode(struct pipe_screen 
*screen,
 
 static int r600_init_surface(struct radeon_surface *surface,
 const struct pipe_resource *ptex,
-unsigned array_mode)
+unsigned array_mode, unsigned is_transfer,
+unsigned is_texture)
 {
surface->npix_x = ptex->width0;
surface->npix_y = ptex->height0;
@@ -298,7 +299,7 @@ static int r600_init_surface(struct radeon_surface *surface,
if (ptex->bind & PIPE_BIND_SCANOUT) {
surface->flags |= RADEON_SURF_SCANOUT;
}
-   if (util_format_is_depth_and_stencil(ptex->format)) {
+   if (util_format_is_depth_and_stencil(ptex->format) && !is_transfer && 
!is_texture) {
surface->flags |= RADEON_SURF_ZBUFFER;
surface->flags |= RADEON_SURF_SBUFFER;
}
@@ -316,11 +317,6 @@ static int r600_setup_surface(struct pipe_screen *screen,
unsigned i;
int r;
 
-   if (util_format_is_depth_or_stencil(rtex->real_format)) {
-   rtex->surface.flags |= RADEON_SURF_ZBUFFER;
-   rtex->surface.flags |= RADEON_SURF_SBUFFER;
-   }
-
r = rscreen->ws->surface_init(rscreen->ws, &rtex->surface);
if (r) {
return r;
@@ -572,7 +568,8 @@ r600_texture_create_object(struct pipe_screen *screen,
r600_setup_miptree(screen, rtex, array_mode);
if (rscreen->use_surface_alloc) {
rtex->surface = *surface;
-   r = r600_setup_surface(screen, rtex, array_mode, 
pitch_in_bytes_override);
+   r = r600_setup_surface(screen, rtex, array_mode,
+  pitch_in_bytes_override);
if (r) {
FREE(rtex);
return NULL;
@@ -642,7 +639,9 @@ struct pipe_resource *r600_texture_create(struct 
pipe_screen *screen,
}
}
 
-   r = r600_init_surface(&surface, templ, array_mode);
+   r = r600_init_surface(&surface, templ, array_mode,
+ templ->flags & R600_RESOURCE_FLAG_TRANSFER,
+ templ->usage & PIPE_BIND_SAMPLER_VIEW);
if (r) {
return NULL;
}
@@ -723,7 +722,7 @@ struct pipe_resource *r600_texture_from_handle(struct 
pipe_screen *screen,
else
array_mode = 0;
 
-   r = r600_init_surface(&surface, templ, array_mode);
+   r = r600_init_surface(&surface, templ, array_mode, 0, 0);
if (r) {
return NULL;
}
@@ -796,8 +795,9 @@ struct pipe_transfer* r600_texture_get_transfer(struct 
pipe_context *ctx,
 * the CPU is much happier reading out of cached system memory
 * than uncached VRAM.
 */
-   if (R600_TEX_IS_TILED(rtex, level))
+   if (R600_TEX_IS_TILED(rtex, level)) {
use_staging_texture = TRUE;
+   }
 
if ((usage & PIPE_TRANSFER_READ) && u_box_volume(box) > 1024)
use_staging_texture = TRUE;
@@ -805,15 +805,18 @@ struct pipe_transfer* r600_texture_get_transfer(struct 
pipe_context *ctx,
/* Use a staging texture for uploads if the underlying BO is busy. */
if (!(usage & PIPE_TRANSFER_READ) &&
(rctx->ws->cs_is_buffer_referenced(rctx->cs, rtex->resource.cs_buf, 
RADEON_USAGE_READWRITE) ||
-rctx->ws->buffer_is_busy(rtex->resource.buf, 
RADEON_USAGE_READWRITE)))
+rctx->ws->buffer_is_busy(rtex->resource.buf, 
RADEON_USAGE_READWRITE))) {
use_staging_texture = TRUE;
+   }
 
if (!permit_hardware_blit(ctx->screen, texture) ||
-   (texture->flags & R600_RESOURCE_FLAG_TRANSFER))
+   (texture->flags & R600_RESOURCE_FLAG_TRANSFER)) {
use_staging_texture = FALSE;
+   }
 
-   if (use_staging_texture && (usage & PIPE_TRANSFER_MAP_DIRECTLY))
+   if (use_staging_texture && (usage & PIPE_TRANSFER_MAP_DIRECTLY)) {
return NULL;
+   }
 
trans = CALLOC_STRUCT(r600_transfer);
if (trans == NULL)
@@ -898,8 +901,9 @@ void r600_texture_transfer_destroy(struct pipe_context *ctx,
}
 
if (rtex->is_depth && !rtex->is_flushing_texture) {
-   if ((transfer->usage & PIPE_TRANSFER_WRITE) && 
rtex->flushed_depth_texture)
+   

[Mesa-dev] [PATCH 1/4] mesa: if AllocStorage doesn't choose a format, report FRAMEBUFFER_UNSUPPORTED

2012-06-15 Thread Marek Olšák
This allows drivers not to do any allocation in AllocStorage if the storage
cannot be allocated because of an unsupported internalformat + samples combo.

The little ugliness is that AllocStorage is expected to return TRUE in this
case.
---
 src/mesa/main/fbobject.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 83e..cfaea62 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -805,6 +805,15 @@ _mesa_test_framebuffer_completeness(struct gl_context *ctx,
 return;
  }
   }
+
+  /* Check that the format is valid. (MESA_FORMAT_NONE means unsupported)
+   */
+  if (att->Type == GL_RENDERBUFFER &&
+  att->Renderbuffer->Format == MESA_FORMAT_NONE) {
+ fb->_Status = GL_FRAMEBUFFER_UNSUPPORTED;
+ fbo_incomplete("unsupported renderbuffer format", i);
+ return;
+  }
}
 
 #if FEATURE_GL
@@ -1394,7 +1403,7 @@ renderbuffer_storage(GLenum target, GLenum internalFormat,
ASSERT(rb->AllocStorage);
if (rb->AllocStorage(ctx, rb, internalFormat, width, height)) {
   /* No error - check/set fields now */
-  assert(rb->Format != MESA_FORMAT_NONE);
+  /* If rb->Format == MESA_FORMAT_NONE, the format is unsupported. */
   assert(rb->Width == (GLuint) width);
   assert(rb->Height == (GLuint) height);
   rb->InternalFormat = internalFormat;
-- 
1.7.9.5

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


[Mesa-dev] [PATCH 3/4] st/mesa: make unsupported renderbuffer formats always fail as FBO incomplete

2012-06-15 Thread Marek Olšák
instead of failing to allocate a renderbuffer.

This also fixes piglit/get-renderbuffer-internalformat with non-renderable
formats.
---
 src/mesa/state_tracker/st_cb_fbo.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index 0126999..88c6fa2 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -81,10 +81,13 @@ st_renderbuffer_alloc_sw_storage(struct gl_context * ctx,
}
else {
   format = st_choose_renderbuffer_format(screen, internalFormat, 0);
-   }
 
-   if (format == PIPE_FORMAT_NONE) {
-  return FALSE;
+  /* Not setting gl_renderbuffer::Format here will cause
+   * FRAMEBUFFER_UNSUPPORTED and ValidateFramebuffer will not be called.
+   */
+  if (format == PIPE_FORMAT_NONE) {
+ return GL_TRUE;
+  }
}
 
strb->Base.Format = st_pipe_format_to_mesa_format(format);
@@ -133,8 +136,11 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
format = st_choose_renderbuffer_format(screen, internalFormat,
   rb->NumSamples);
 
+   /* Not setting gl_renderbuffer::Format here will cause
+* FRAMEBUFFER_UNSUPPORTED and ValidateFramebuffer will not be called.
+*/
if (format == PIPE_FORMAT_NONE) {
-  return FALSE;
+  return GL_TRUE;
}
 
strb->Base.Format = st_pipe_format_to_mesa_format(format);
-- 
1.7.9.5

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


[Mesa-dev] [PATCH 4/4] st/mesa: properly allocate MSAA renderbuffers

2012-06-15 Thread Marek Olšák
---
 src/mesa/state_tracker/st_cb_fbo.c |   34 +++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index 88c6fa2..3d77718 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -113,7 +113,7 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
struct pipe_context *pipe = st->pipe;
struct pipe_screen *screen = st->pipe->screen;
struct st_renderbuffer *strb = st_renderbuffer(rb);
-   enum pipe_format format;
+   enum pipe_format format = PIPE_FORMAT_NONE;
struct pipe_surface surf_tmpl;
struct pipe_resource templ;
 
@@ -133,8 +133,36 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
pipe_surface_reference( &strb->surface, NULL );
pipe_resource_reference( &strb->texture, NULL );
 
-   format = st_choose_renderbuffer_format(screen, internalFormat,
-  rb->NumSamples);
+   /* Handle multisample renderbuffers first.
+*
+* From ARB_framebuffer_object:
+*   If  is zero, then RENDERBUFFER_SAMPLES is set to zero.
+*   Otherwise  represents a request for a desired minimum
+*   number of samples. Since different implementations may support
+*   different sample counts for multisampled rendering, the actual
+*   number of samples allocated for the renderbuffer image is
+*   implementation dependent.  However, the resulting value for
+*   RENDERBUFFER_SAMPLES is guaranteed to be greater than or equal
+*   to  and no more than the next larger sample count supported
+*   by the implementation.
+*
+* So let's find the supported number of samples closest to NumSamples.
+* (NumSamples == 1) is treated the same as (NumSamples == 0).
+*/
+   if (rb->NumSamples > 1) {
+  unsigned i;
+
+  for (i = rb->NumSamples; i < ctx->Const.MaxSamples; i++) {
+ format = st_choose_renderbuffer_format(screen, internalFormat, i);
+
+ if (format != PIPE_FORMAT_NONE) {
+rb->NumSamples = i;
+break;
+ }
+  }
+   } else {
+  format = st_choose_renderbuffer_format(screen, internalFormat, 0);
+   }
 
/* Not setting gl_renderbuffer::Format here will cause
 * FRAMEBUFFER_UNSUPPORTED and ValidateFramebuffer will not be called.
-- 
1.7.9.5

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


[Mesa-dev] [PATCH 2/4] st/mesa: separate sw renderbuffer allocation from hw one

2012-06-15 Thread Marek Olšák
---
 src/mesa/state_tracker/st_cb_fbo.c |  168 
 1 file changed, 93 insertions(+), 75 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index 953295c..0126999 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -57,25 +57,21 @@
 #include "util/u_surface.h"
 
 
-/**
- * gl_renderbuffer::AllocStorage()
- * This is called to allocate the original drawing surface, and
- * during window resize.
- */
 static GLboolean
-st_renderbuffer_alloc_storage(struct gl_context * ctx,
-  struct gl_renderbuffer *rb,
-  GLenum internalFormat,
-  GLuint width, GLuint height)
+st_renderbuffer_alloc_sw_storage(struct gl_context * ctx,
+ struct gl_renderbuffer *rb,
+ GLenum internalFormat,
+ GLuint width, GLuint height)
 {
-   struct st_context *st = st_context(ctx);
-   struct pipe_context *pipe = st->pipe;
-   struct pipe_screen *screen = st->pipe->screen;
+   struct pipe_screen *screen = st_context(ctx)->pipe->screen;
struct st_renderbuffer *strb = st_renderbuffer(rb);
enum pipe_format format;
-   struct pipe_surface surf_tmpl;
+   size_t size;
 
-   if (internalFormat == GL_RGBA16_SNORM && strb->software) {
+   free(strb->data);
+   strb->data = NULL;
+
+   if (internalFormat == GL_RGBA16_SNORM) {
   /* Special case for software accum buffers.  Otherwise, if the
* call to st_choose_renderbuffer_format() fails (because the
* driver doesn't support signed 16-bit/channel colors) we'd
@@ -84,88 +80,110 @@ st_renderbuffer_alloc_storage(struct gl_context * ctx,
   format = PIPE_FORMAT_R16G16B16A16_SNORM;
}
else {
-  format = st_choose_renderbuffer_format(screen, internalFormat,
- rb->NumSamples);
+  format = st_choose_renderbuffer_format(screen, internalFormat, 0);
}
 
if (format == PIPE_FORMAT_NONE) {
   return FALSE;
}
 
+   strb->Base.Format = st_pipe_format_to_mesa_format(format);
+
+   size = _mesa_format_image_size(strb->Base.Format, width, height, 1);
+   strb->data = malloc(size);
+   return strb->data != NULL;
+}
+
+
+/**
+ * gl_renderbuffer::AllocStorage()
+ * This is called to allocate the original drawing surface, and
+ * during window resize.
+ */
+static GLboolean
+st_renderbuffer_alloc_storage(struct gl_context * ctx,
+  struct gl_renderbuffer *rb,
+  GLenum internalFormat,
+  GLuint width, GLuint height)
+{
+   struct st_context *st = st_context(ctx);
+   struct pipe_context *pipe = st->pipe;
+   struct pipe_screen *screen = st->pipe->screen;
+   struct st_renderbuffer *strb = st_renderbuffer(rb);
+   enum pipe_format format;
+   struct pipe_surface surf_tmpl;
+   struct pipe_resource templ;
+
/* init renderbuffer fields */
strb->Base.Width  = width;
strb->Base.Height = height;
-   strb->Base.Format = st_pipe_format_to_mesa_format(format);
strb->Base._BaseFormat = _mesa_base_fbo_format(ctx, internalFormat);
-
strb->defined = GL_FALSE;  /* undefined contents now */
 
if (strb->software) {
-  size_t size;
-  
-  free(strb->data);
-
-  size = _mesa_format_image_size(strb->Base.Format, width, height, 1);
-  
-  strb->data = malloc(size);
-  
-  return strb->data != NULL;
+  return st_renderbuffer_alloc_sw_storage(ctx, rb, internalFormat,
+  width, height);
}
-   else {
-  struct pipe_resource template;
-
-  /* Free the old surface and texture
-   */
-  pipe_surface_reference( &strb->surface, NULL );
-  pipe_resource_reference( &strb->texture, NULL );
 
-  if (width == 0 || height == 0) {
- /* if size is zero, nothing to allocate */
- return GL_TRUE;
-  }
+   /* Free the old surface and texture
+*/
+   pipe_surface_reference( &strb->surface, NULL );
+   pipe_resource_reference( &strb->texture, NULL );
 
-  /* Setup new texture template.
-   */
-  memset(&template, 0, sizeof(template));
-  template.target = st->internal_target;
-  template.format = format;
-  template.width0 = width;
-  template.height0 = height;
-  template.depth0 = 1;
-  template.array_size = 1;
-  template.last_level = 0;
-  template.nr_samples = rb->NumSamples;
-  if (util_format_is_depth_or_stencil(format)) {
- template.bind = PIPE_BIND_DEPTH_STENCIL;
-  }
-  else if (strb->Base.Name != 0) {
- /* this is a user-created renderbuffer */
- template.bind = PIPE_BIND_RENDER_TARGET;
-  }
-  else {
- /* this is a window-system buffer */
- template.bind = (PIPE_BIND_DISPLAY_TARGET |
-  P

[Mesa-dev] [Bug 50604] [compile error] ../../../../../src/mesa/libdricore/../main/api_arrayelt.c:45:27: fatal error: main/dispatch.h: No such file or directory

2012-06-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=50604

--- Comment #5 from nobled  2012-06-15 10:25:12 PDT ---
(In reply to comment #4)
> Sadly, the naive solution of changing those references to be relative to
> $(top_builddir) rather than $(srcdir) runs into problems in src/mesa/Makefile;
> possibly the best way to fix this is to continue the automakification to
> src/mesa.
Is having both a problem? Or just using $(builddir) [not top]?

-- 
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] [PATCH] i965/fs: Fix conversions float->bool, int->bool

2012-06-15 Thread Chad Versace
Fixes gles2conform GL.equal.equal_bvec2_frag.

This fixes brw_fs_visitor's translation of ir_unop_f2b.  It used CMP to
convert the float to one of 0 or ~0. However, the convention in the
compiler is that true is represented by 1, not ~0. This patch adds an AND
to convert ~0 to 1.

By inspection, a similar problem existed with ir_unop_i2b, with a similar
fix.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49621
Signed-off-by: Chad Versace 
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |   19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 4b9330b..a153224 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -475,20 +475,19 @@ fs_visitor::visit(ir_expression *ir)
   emit(BRW_OPCODE_AND, temp, op[0], fs_reg(1));
   emit(BRW_OPCODE_MOV, this->result, temp);
   break;
-
case ir_unop_f2b:
+  temp = fs_reg(this, glsl_type::int_type);
+  inst = emit(BRW_OPCODE_CMP, temp, op[0], fs_reg(0.0f));
+  inst->conditional_mod = BRW_CONDITIONAL_NEQ;
+  emit(BRW_OPCODE_AND, this->result, temp, fs_reg(1));
+  break;
case ir_unop_i2b:
-  temp = this->result;
-  /* original gen4 does implicit conversion before comparison. */
-  if (intel->gen < 5)
-temp.type = op[0].type;
-
   resolve_ud_negate(&op[0]);
-
-  inst = emit(BRW_OPCODE_CMP, temp, op[0], fs_reg(0.0f));
-  inst->conditional_mod = BRW_CONDITIONAL_NZ;
+  temp = fs_reg(this, glsl_type::int_type);
+  inst = emit(BRW_OPCODE_CMP, temp, op[0], fs_reg(0));
+  inst->conditional_mod = BRW_CONDITIONAL_NEQ;
+  emit(BRW_OPCODE_AND, this->result, temp, fs_reg(1));
   break;
-
case ir_unop_trunc:
   emit(BRW_OPCODE_RNDZ, this->result, op[0]);
   break;
-- 
1.7.10.4

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


[Mesa-dev] [RFC PATCH] i965/msaa: Disable unsupported formats.

2012-06-15 Thread Paul Berry
Due to hardware limitations, MSAA is unsupported on Gen6 for formats
containing >64 bits of data per pixel.  From the Sandy Bridge PRM,
vol4 part1, p72 ("Surface Format"):

If Number of Multisamples is set to a value other than
MULTISAMPLECOUNT_1, this field cannot be set to the following
formats:
- any format with greater than 64 bits per element
- any compressed texture format (BC*)
- any YCRCB* format

Gen7 has a similar, but less stringent limitation: formats with >64
bits of data per pixel only support 4x MSAA.

This patch causes the unsupported formats to report
GL_FRAMEBUFFER_UNSUPPORTED.

Fixes piglit "multisample-formats" tests on Gen6.
---

It is not 100% clear to me whether this approach is compliant with the
spec.  On the one hand, the spec requires formats RGBA32F, RGBA32I,
and RGBA32UI to be color-renderable.  On the other hand, the spec
allows for the implementation to report GL_FRAMEBUFFER_UNSUPPORTED if
the set of attached images violates "an implementation-dependent set
of restrictions", which seems to leave a lot of leeway.

If we decide that it's not ok to report GL_FRAMEBUFFER_UNSUPPORTED for
MSAA buffers using these formats, then we'll have to figure out some
other way to work around the hardware's lack of support for MSAA on
these formats, and I haven't thought of a good way to do that.  The
alternatives I've considered (substitute another buffer format, or
substitute a non-multisampled renderbuffer) are definitely
non-spec-compliant, and also fraught with implementation difficulties.

So for the moment my inclination is to go through with this patch as
is, and if we later discover that it causes trouble for a client
application, we can consider other options.  I'm curious to hear what
others think.

 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 4718337..d09fe6d 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -576,6 +576,19 @@ brw_render_target_supported(struct intel_context *intel,
rb->_BaseFormat != GL_RED) && _mesa_is_format_integer_color(format))
   return false;
 
+   /* Under some conditions, MSAA is not supported for formats whose width is
+* more than 64 bits.
+*/
+   if (rb->NumSamples > 0 && _mesa_get_format_bytes(format) > 8) {
+  /* Gen6: MSAA on >64 bit formats is unsupported. */
+  if (intel->gen <= 6)
+ return false;
+
+  /* Gen7: 8x MSAA on >64 bit formats is unsupported. */
+  if (rb->NumSamples >= 8)
+ return false;
+   }
+
return brw->format_supported_as_render_target[format];
 }
 
-- 
1.7.7.6

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


Re: [Mesa-dev] [PATCH] r600g: fix z/stencil texture creation

2012-06-15 Thread Marek Olšák
Hi Jerome,

Your patch somehow fixes all regressions, but it's not correct. Please
see below.

On Fri, Jun 15, 2012 at 5:25 PM,   wrote:
> From: Jerome Glisse 
>
> z or stencil texture should not be created with the z/stencil
> flags for surface creation as they are intended to be bound
> as texture.
>
> Signed-off-by: Jerome Glisse 
> ---
>  src/gallium/drivers/r600/r600_texture.c |   34 +-
>  1 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_texture.c 
> b/src/gallium/drivers/r600/r600_texture.c
> index 5b15990..517f273 100644
> --- a/src/gallium/drivers/r600/r600_texture.c
> +++ b/src/gallium/drivers/r600/r600_texture.c
> @@ -237,7 +237,8 @@ static void r600_texture_set_array_mode(struct 
> pipe_screen *screen,
>
>  static int r600_init_surface(struct radeon_surface *surface,
> const struct pipe_resource *ptex,
> -unsigned array_mode)
> +unsigned array_mode, unsigned is_transfer,
> +unsigned is_texture)

We use the "boolean" type in gallium for bools. You also seem to need
only one flag, not two, because you don't make any distinction between
is_transfer and is_texture further in the code. The "is_texture" flag
is not very useful anyway, see below.

>  {
>surface->npix_x = ptex->width0;
>surface->npix_y = ptex->height0;
> @@ -298,7 +299,7 @@ static int r600_init_surface(struct radeon_surface 
> *surface,
>if (ptex->bind & PIPE_BIND_SCANOUT) {
>surface->flags |= RADEON_SURF_SCANOUT;
>}
> -   if (util_format_is_depth_and_stencil(ptex->format)) {
> +   if (util_format_is_depth_and_stencil(ptex->format) && !is_transfer && 
> !is_texture) {
>surface->flags |= RADEON_SURF_ZBUFFER;
>surface->flags |= RADEON_SURF_SBUFFER;
>}
> @@ -316,11 +317,6 @@ static int r600_setup_surface(struct pipe_screen *screen,
>unsigned i;
>int r;
>
> -   if (util_format_is_depth_or_stencil(rtex->real_format)) {
> -   rtex->surface.flags |= RADEON_SURF_ZBUFFER;
> -   rtex->surface.flags |= RADEON_SURF_SBUFFER;
> -   }
> -
>r = rscreen->ws->surface_init(rscreen->ws, &rtex->surface);
>if (r) {
>return r;
> @@ -572,7 +568,8 @@ r600_texture_create_object(struct pipe_screen *screen,
>r600_setup_miptree(screen, rtex, array_mode);
>if (rscreen->use_surface_alloc) {
>rtex->surface = *surface;
> -   r = r600_setup_surface(screen, rtex, array_mode, 
> pitch_in_bytes_override);
> +   r = r600_setup_surface(screen, rtex, array_mode,
> +  pitch_in_bytes_override);
>if (r) {
>FREE(rtex);
>return NULL;
> @@ -642,7 +639,9 @@ struct pipe_resource *r600_texture_create(struct 
> pipe_screen *screen,
>}
>}
>
> -   r = r600_init_surface(&surface, templ, array_mode);
> +   r = r600_init_surface(&surface, templ, array_mode,
> + templ->flags & R600_RESOURCE_FLAG_TRANSFER,
> + templ->usage & PIPE_BIND_SAMPLER_VIEW);

There are two reasons why this is wrong.

1) templ->usage may only contain one PIPE_USAGE_* flag.

2) Even if you had used (templ->bind & PIPE_BIND_SAMPLER_VIEW), it
wouldn't be any useful for OpenGL, because all textures and renderbuffers in
OpenGL can be used as samplers. Yeah, that's right, everything. The
typical use cases are glBlitFramebuffer and glCopyTex(Sub)Image.

Also it would be safer not to trust the state tracker that it set the
bind flags correctly, and behave as if PIPE_BIND_SAMPLER_VIEW were set
always.

>if (r) {
>return NULL;
>}
> @@ -723,7 +722,7 @@ struct pipe_resource *r600_texture_from_handle(struct 
> pipe_screen *screen,
>else
>array_mode = 0;
>
> -   r = r600_init_surface(&surface, templ, array_mode);
> +   r = r600_init_surface(&surface, templ, array_mode, 0, 0);

This is wrong for the same reason as above. The window framebuffer
allocated by the DDX can be used as a sampler in OpenGL.

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


Re: [Mesa-dev] [PATCH] r600g: fix z/stencil texture creation

2012-06-15 Thread Brian Paul
On Fri, Jun 15, 2012 at 12:29 PM, Marek Olšák  wrote:
> Hi Jerome,
>
> Your patch somehow fixes all regressions, but it's not correct. Please
> see below.
>
> On Fri, Jun 15, 2012 at 5:25 PM,   wrote:
>> From: Jerome Glisse 
>>
>> z or stencil texture should not be created with the z/stencil
>> flags for surface creation as they are intended to be bound
>> as texture.
>>
>> Signed-off-by: Jerome Glisse 
>> ---
>>  src/gallium/drivers/r600/r600_texture.c |   34 
>> +-
>>  1 files changed, 19 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_texture.c 
>> b/src/gallium/drivers/r600/r600_texture.c
>> index 5b15990..517f273 100644
>> --- a/src/gallium/drivers/r600/r600_texture.c
>> +++ b/src/gallium/drivers/r600/r600_texture.c
>> @@ -237,7 +237,8 @@ static void r600_texture_set_array_mode(struct 
>> pipe_screen *screen,
>>
>>  static int r600_init_surface(struct radeon_surface *surface,
>>                             const struct pipe_resource *ptex,
>> -                            unsigned array_mode)
>> +                            unsigned array_mode, unsigned is_transfer,
>> +                            unsigned is_texture)
>
> We use the "boolean" type in gallium for bools. You also seem to need
> only one flag, not two, because you don't make any distinction between
> is_transfer and is_texture further in the code. The "is_texture" flag
> is not very useful anyway, see below.
>
>>  {
>>        surface->npix_x = ptex->width0;
>>        surface->npix_y = ptex->height0;
>> @@ -298,7 +299,7 @@ static int r600_init_surface(struct radeon_surface 
>> *surface,
>>        if (ptex->bind & PIPE_BIND_SCANOUT) {
>>                surface->flags |= RADEON_SURF_SCANOUT;
>>        }
>> -       if (util_format_is_depth_and_stencil(ptex->format)) {
>> +       if (util_format_is_depth_and_stencil(ptex->format) && !is_transfer 
>> && !is_texture) {
>>                surface->flags |= RADEON_SURF_ZBUFFER;
>>                surface->flags |= RADEON_SURF_SBUFFER;
>>        }
>> @@ -316,11 +317,6 @@ static int r600_setup_surface(struct pipe_screen 
>> *screen,
>>        unsigned i;
>>        int r;
>>
>> -       if (util_format_is_depth_or_stencil(rtex->real_format)) {
>> -               rtex->surface.flags |= RADEON_SURF_ZBUFFER;
>> -               rtex->surface.flags |= RADEON_SURF_SBUFFER;
>> -       }
>> -
>>        r = rscreen->ws->surface_init(rscreen->ws, &rtex->surface);
>>        if (r) {
>>                return r;
>> @@ -572,7 +568,8 @@ r600_texture_create_object(struct pipe_screen *screen,
>>        r600_setup_miptree(screen, rtex, array_mode);
>>        if (rscreen->use_surface_alloc) {
>>                rtex->surface = *surface;
>> -               r = r600_setup_surface(screen, rtex, array_mode, 
>> pitch_in_bytes_override);
>> +               r = r600_setup_surface(screen, rtex, array_mode,
>> +                                      pitch_in_bytes_override);
>>                if (r) {
>>                        FREE(rtex);
>>                        return NULL;
>> @@ -642,7 +639,9 @@ struct pipe_resource *r600_texture_create(struct 
>> pipe_screen *screen,
>>                }
>>        }
>>
>> -       r = r600_init_surface(&surface, templ, array_mode);
>> +       r = r600_init_surface(&surface, templ, array_mode,
>> +                             templ->flags & R600_RESOURCE_FLAG_TRANSFER,
>> +                             templ->usage & PIPE_BIND_SAMPLER_VIEW);
>
> There are two reasons why this is wrong.
>
> 1) templ->usage may only contain one PIPE_USAGE_* flag.
>
> 2) Even if you had used (templ->bind & PIPE_BIND_SAMPLER_VIEW), it
> wouldn't be any useful for OpenGL, because all textures and renderbuffers in
> OpenGL can be used as samplers. Yeah, that's right, everything. The
> typical use cases are glBlitFramebuffer and glCopyTex(Sub)Image.
>
> Also it would be safer not to trust the state tracker that it set the
> bind flags correctly, and behave as if PIPE_BIND_SAMPLER_VIEW were set
> always.
>
>>        if (r) {
>>                return NULL;
>>        }
>> @@ -723,7 +722,7 @@ struct pipe_resource *r600_texture_from_handle(struct 
>> pipe_screen *screen,
>>        else
>>                array_mode = 0;
>>
>> -       r = r600_init_surface(&surface, templ, array_mode);
>> +       r = r600_init_surface(&surface, templ, array_mode, 0, 0);
>
> This is wrong for the same reason as above. The window framebuffer
> allocated by the DDX can be used as a sampler in OpenGL.

Just to be clear, you don't mean that at the GL API level, do you?
OpenGL doesn't support using the window's color buffer (nor plain
renderbuffers) to be used as a texture.  A compositor might use the
window image as a texture though.

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


Re: [Mesa-dev] Upcoming Mesa releases

2012-06-15 Thread Jakob Bornecrantz
On Thu, May 3, 2012 at 11:38 PM, Ian Romanick  wrote:
> To keep in the habit of doing regular releases, I'd like to propose the
> following set of release dates.  We had previously discussed doing stable
> releases monthly and feature releases every six months.  This set of dates
> basically reflects that.
>
> I should be able to package up most of these, but I will be on vacation in
> June.  Perhaps Jakob can handle that one. :)
>
> I've listed the February 2013 release as 8.2.  I think there's a good chance
> we'll have OpenGL 3.1 by then, so it may end up being 9.0.
>
> 5/18:  Mesa 8.0.3
> 6/15:  Mesa 8.0.4

Hello people, so I was going to do a release today. but currently
there are just three fixes on the 8.0 branch not already in th 8.0.3
release. I would like to see a bit more there before doing a release
especially since I know there are patches that should be cherry picked
over.

So it would be good if people could pick patches over for their area.
People without commit access but who want to nominate fixes please do
so here and I will cherry pick them over. I will take a look on Monday
and see where we are then.

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


Re: [Mesa-dev] [PATCH] r600g: fix z/stencil texture creation

2012-06-15 Thread Marek Olšák
On Fri, Jun 15, 2012 at 8:40 PM, Brian Paul  wrote:
> On Fri, Jun 15, 2012 at 12:29 PM, Marek Olšák  wrote:
>> Hi Jerome,
>>
>> Your patch somehow fixes all regressions, but it's not correct. Please
>> see below.
>>
>> On Fri, Jun 15, 2012 at 5:25 PM,   wrote:
>>> From: Jerome Glisse 
>>>
>>> z or stencil texture should not be created with the z/stencil
>>> flags for surface creation as they are intended to be bound
>>> as texture.
>>>
>>> Signed-off-by: Jerome Glisse 
>>> ---
>>>  src/gallium/drivers/r600/r600_texture.c |   34 
>>> +-
>>>  1 files changed, 19 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/r600/r600_texture.c 
>>> b/src/gallium/drivers/r600/r600_texture.c
>>> index 5b15990..517f273 100644
>>> --- a/src/gallium/drivers/r600/r600_texture.c
>>> +++ b/src/gallium/drivers/r600/r600_texture.c
>>> @@ -237,7 +237,8 @@ static void r600_texture_set_array_mode(struct 
>>> pipe_screen *screen,
>>>
>>>  static int r600_init_surface(struct radeon_surface *surface,
>>>                             const struct pipe_resource *ptex,
>>> -                            unsigned array_mode)
>>> +                            unsigned array_mode, unsigned is_transfer,
>>> +                            unsigned is_texture)
>>
>> We use the "boolean" type in gallium for bools. You also seem to need
>> only one flag, not two, because you don't make any distinction between
>> is_transfer and is_texture further in the code. The "is_texture" flag
>> is not very useful anyway, see below.
>>
>>>  {
>>>        surface->npix_x = ptex->width0;
>>>        surface->npix_y = ptex->height0;
>>> @@ -298,7 +299,7 @@ static int r600_init_surface(struct radeon_surface 
>>> *surface,
>>>        if (ptex->bind & PIPE_BIND_SCANOUT) {
>>>                surface->flags |= RADEON_SURF_SCANOUT;
>>>        }
>>> -       if (util_format_is_depth_and_stencil(ptex->format)) {
>>> +       if (util_format_is_depth_and_stencil(ptex->format) && !is_transfer 
>>> && !is_texture) {
>>>                surface->flags |= RADEON_SURF_ZBUFFER;
>>>                surface->flags |= RADEON_SURF_SBUFFER;
>>>        }
>>> @@ -316,11 +317,6 @@ static int r600_setup_surface(struct pipe_screen 
>>> *screen,
>>>        unsigned i;
>>>        int r;
>>>
>>> -       if (util_format_is_depth_or_stencil(rtex->real_format)) {
>>> -               rtex->surface.flags |= RADEON_SURF_ZBUFFER;
>>> -               rtex->surface.flags |= RADEON_SURF_SBUFFER;
>>> -       }
>>> -
>>>        r = rscreen->ws->surface_init(rscreen->ws, &rtex->surface);
>>>        if (r) {
>>>                return r;
>>> @@ -572,7 +568,8 @@ r600_texture_create_object(struct pipe_screen *screen,
>>>        r600_setup_miptree(screen, rtex, array_mode);
>>>        if (rscreen->use_surface_alloc) {
>>>                rtex->surface = *surface;
>>> -               r = r600_setup_surface(screen, rtex, array_mode, 
>>> pitch_in_bytes_override);
>>> +               r = r600_setup_surface(screen, rtex, array_mode,
>>> +                                      pitch_in_bytes_override);
>>>                if (r) {
>>>                        FREE(rtex);
>>>                        return NULL;
>>> @@ -642,7 +639,9 @@ struct pipe_resource *r600_texture_create(struct 
>>> pipe_screen *screen,
>>>                }
>>>        }
>>>
>>> -       r = r600_init_surface(&surface, templ, array_mode);
>>> +       r = r600_init_surface(&surface, templ, array_mode,
>>> +                             templ->flags & R600_RESOURCE_FLAG_TRANSFER,
>>> +                             templ->usage & PIPE_BIND_SAMPLER_VIEW);
>>
>> There are two reasons why this is wrong.
>>
>> 1) templ->usage may only contain one PIPE_USAGE_* flag.
>>
>> 2) Even if you had used (templ->bind & PIPE_BIND_SAMPLER_VIEW), it
>> wouldn't be any useful for OpenGL, because all textures and renderbuffers in
>> OpenGL can be used as samplers. Yeah, that's right, everything. The
>> typical use cases are glBlitFramebuffer and glCopyTex(Sub)Image.
>>
>> Also it would be safer not to trust the state tracker that it set the
>> bind flags correctly, and behave as if PIPE_BIND_SAMPLER_VIEW were set
>> always.
>>
>>>        if (r) {
>>>                return NULL;
>>>        }
>>> @@ -723,7 +722,7 @@ struct pipe_resource *r600_texture_from_handle(struct 
>>> pipe_screen *screen,
>>>        else
>>>                array_mode = 0;
>>>
>>> -       r = r600_init_surface(&surface, templ, array_mode);
>>> +       r = r600_init_surface(&surface, templ, array_mode, 0, 0);
>>
>> This is wrong for the same reason as above. The window framebuffer
>> allocated by the DDX can be used as a sampler in OpenGL.
>
> Just to be clear, you don't mean that at the GL API level, do you?

That's correct.

> OpenGL doesn't support using the window's color buffer (nor plain
> renderbuffers) to be used as a texture.  A compositor might use the
> window image as a texture though.

I mean it from the perspective of an OpenGL driver which implements

[Mesa-dev] [PATCH 1/2] get.c: Rename EXTRA_VERSION_ES2 to EXTRA_API_ES2

2012-06-15 Thread Kristian Høgsberg
This extra condition checks the API not the version of the API, so rename
to reflect that.
---
 src/mesa/main/get.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 55dc205..a8e1d86 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -131,7 +131,7 @@ enum value_extra {
EXTRA_VERSION_30,
EXTRA_VERSION_31,
EXTRA_VERSION_32,
-   EXTRA_VERSION_ES2,
+   EXTRA_API_ES2,
EXTRA_NEW_BUFFERS, 
EXTRA_NEW_FRAG_CLAMP,
EXTRA_VALID_DRAW_BUFFER,
@@ -363,9 +363,9 @@ static const int extra_version_31[] = { EXTRA_VERSION_31, 
EXTRA_END };
 static const int extra_version_32[] = { EXTRA_VERSION_32, EXTRA_END };
 
 static const int
-extra_ARB_vertex_program_version_es2[] = {
+extra_ARB_vertex_program_api_es2[] = {
EXT(ARB_vertex_program),
-   EXTRA_VERSION_ES2,
+   EXTRA_API_ES2,
EXTRA_END
 };
 
@@ -740,7 +740,7 @@ static const struct value_desc values[] = {
 
{ GL_MAX_VERTEX_ATTRIBS_ARB,
  CONTEXT_INT(Const.VertexProgram.MaxAttribs),
- extra_ARB_vertex_program_version_es2 },
+ extra_ARB_vertex_program_api_es2 },
 
/* OES_texture_3D */
{ GL_TEXTURE_BINDING_3D, LOC_CUSTOM, TYPE_INT, TEXTURE_3D_INDEX, NO_EXTRA },
@@ -1808,7 +1808,7 @@ check_extra(struct gl_context *ctx, const char *func, 
const struct value_desc *d
  if (ctx->NewState & (_NEW_BUFFERS | _NEW_FRAG_CLAMP))
 _mesa_update_state(ctx);
  break;
-  case EXTRA_VERSION_ES2:
+  case EXTRA_API_ES2:
 if (ctx->API == API_OPENGLES2) {
total++;
enabled++;
-- 
1.7.10.2

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


[Mesa-dev] [PATCH 2/2] gles2: Add GL_NV_read_buffer extension

2012-06-15 Thread Kristian Høgsberg
This lets us select the front buffer for reading under GLES2.
---
 src/mapi/glapi/gen/es_EXT.xml  |7 +++
 src/mapi/glapi/gen/gles_api.py |2 ++
 src/mesa/main/APIspec.xml  |   13 +
 src/mesa/main/extensions.c |1 +
 src/mesa/main/get.c|   20 +++-
 src/mesa/main/mtypes.h |1 +
 6 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index c7e7d07..b26cac5 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -627,4 +627,11 @@
 
 
 
+
+
+
+
+
+
+
 
diff --git a/src/mapi/glapi/gen/gles_api.py b/src/mapi/glapi/gen/gles_api.py
index 0116ba4..70ae2e3 100644
--- a/src/mapi/glapi/gen/gles_api.py
+++ b/src/mapi/glapi/gen/gles_api.py
@@ -451,4 +451,6 @@ es2_api = es2_core + (
 'ProgramBinaryOES',
 # GL_NV_draw_buffers
 'DrawBuffersNV',
+# GL_NV_read_buffer
+'ReadBufferNV',
 )
diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
index f23857a..64e666e 100644
--- a/src/mesa/main/APIspec.xml
+++ b/src/mesa/main/APIspec.xml
@@ -3534,6 +3534,13 @@

 
 
+
+   
+   
+   
+   
+
+
 

 
@@ -3810,6 +3817,9 @@
 
 

+
+   
+
 
 
 
@@ -4150,7 +4160,10 @@
 
 

+   
+

+
 

 
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 2688f7a..0e81783 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -300,6 +300,7 @@ static const struct extension extension_table[] = {
{ "GL_NV_packed_depth_stencil", 
o(EXT_packed_depth_stencil),GL, 2000 },
{ "GL_NV_point_sprite", o(NV_point_sprite), 
GL, 2001 },
{ "GL_NV_primitive_restart",o(NV_primitive_restart),
GL, 2002 },
+   { "GL_NV_read_buffer",  o(dummy_true),  
ES2,2011 },
{ "GL_NV_texgen_reflection",o(NV_texgen_reflection),
GL, 1999 },
{ "GL_NV_texture_barrier",  o(NV_texture_barrier),  
GL, 2009 },
{ "GL_NV_texture_env_combine4", o(NV_texture_env_combine4), 
GL, 1999 },
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index a8e1d86..969b55b 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -131,6 +131,7 @@ enum value_extra {
EXTRA_VERSION_30,
EXTRA_VERSION_31,
EXTRA_VERSION_32,
+   EXTRA_API_GL,
EXTRA_API_ES2,
EXTRA_NEW_BUFFERS, 
EXTRA_NEW_FRAG_CLAMP,
@@ -369,6 +370,13 @@ extra_ARB_vertex_program_api_es2[] = {
EXTRA_END
 };
 
+static const int
+extra_NV_read_buffer_api_gl[] = {
+   EXT(NV_read_buffer),
+   EXTRA_API_GL,
+   EXTRA_END
+};
+
 #define API_OPENGL_BIT (1 << API_OPENGL)
 #define API_OPENGLES_BIT (1 << API_OPENGLES)
 #define API_OPENGLES2_BIT (1 << API_OPENGLES2)
@@ -750,6 +758,11 @@ static const struct value_desc values[] = {
/* GL_ARB_fragment_program/OES_standard_derivatives */
{ GL_FRAGMENT_SHADER_DERIVATIVE_HINT_ARB,
  CONTEXT_ENUM(Hint.FragmentShaderDerivative), extra_ARB_fragment_shader },
+
+   /* GL_NV_read_buffer */
+   { GL_READ_BUFFER,
+ LOC_CUSTOM, TYPE_ENUM, NO_OFFSET, extra_NV_read_buffer_api_gl },
+
 #endif /* FEATURE_GL || FEATURE_ES2 */
 
 #if FEATURE_ES2
@@ -884,7 +897,6 @@ static const struct value_desc values[] = {
{ GL_POLYGON_SMOOTH, CONTEXT_BOOL(Polygon.SmoothFlag), NO_EXTRA },
{ GL_POLYGON_SMOOTH_HINT, CONTEXT_ENUM(Hint.PolygonSmooth), NO_EXTRA },
{ GL_POLYGON_STIPPLE, CONTEXT_BOOL(Polygon.StippleFlag), NO_EXTRA },
-   { GL_READ_BUFFER, LOC_CUSTOM, TYPE_ENUM, NO_OFFSET, NO_EXTRA },
{ GL_RED_BIAS, CONTEXT_FLOAT(Pixel.RedBias), NO_EXTRA },
{ GL_RED_SCALE, CONTEXT_FLOAT(Pixel.RedScale), NO_EXTRA },
{ GL_RENDER_MODE, CONTEXT_ENUM(RenderMode), NO_EXTRA },
@@ -1814,6 +1826,12 @@ check_extra(struct gl_context *ctx, const char *func, 
const struct value_desc *d
enabled++;
 }
 break;
+  case EXTRA_API_GL:
+if (ctx->API == API_OPENGL) {
+   total++;
+   enabled++;
+}
+break;
   case EXTRA_NEW_BUFFERS:
 if (ctx->NewState & _NEW_BUFFERS)
_mesa_update_state(ctx);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index ea40ffc..3d18b7c 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2995,6 +2995,7 @@ struct gl_extensions
GLboolean NV_light_max_exponent;
GLboolean NV_point_sprite;
GLboolean NV_primitive_restart;
+   GLboolean NV_read_buffer;
GLboolean NV_texture_barrier;
GLboolean NV_texgen_reflection;
GLboolean NV_texture_env_combine4;
-- 
1.7.10.2

_

Re: [Mesa-dev] [PATCH 1/4] mesa: if AllocStorage doesn't choose a format, report FRAMEBUFFER_UNSUPPORTED

2012-06-15 Thread Brian Paul
On Fri, Jun 15, 2012 at 11:07 AM, Marek Olšák  wrote:
> This allows drivers not to do any allocation in AllocStorage if the storage
> cannot be allocated because of an unsupported internalformat + samples combo.
>
> The little ugliness is that AllocStorage is expected to return TRUE in this
> case.
> ---
>  src/mesa/main/fbobject.c |   11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index 83e..cfaea62 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -805,6 +805,15 @@ _mesa_test_framebuffer_completeness(struct gl_context 
> *ctx,
>             return;
>          }
>       }
> +
> +      /* Check that the format is valid. (MESA_FORMAT_NONE means unsupported)
> +       */
> +      if (att->Type == GL_RENDERBUFFER &&
> +          att->Renderbuffer->Format == MESA_FORMAT_NONE) {
> +         fb->_Status = GL_FRAMEBUFFER_UNSUPPORTED;
> +         fbo_incomplete("unsupported renderbuffer format", i);
> +         return;
> +      }
>    }
>
>  #if FEATURE_GL
> @@ -1394,7 +1403,7 @@ renderbuffer_storage(GLenum target, GLenum 
> internalFormat,
>    ASSERT(rb->AllocStorage);
>    if (rb->AllocStorage(ctx, rb, internalFormat, width, height)) {
>       /* No error - check/set fields now */
> -      assert(rb->Format != MESA_FORMAT_NONE);
> +      /* If rb->Format == MESA_FORMAT_NONE, the format is unsupported. */
>       assert(rb->Width == (GLuint) width);
>       assert(rb->Height == (GLuint) height);
>       rb->InternalFormat = internalFormat;
> --

The series looks good to me.

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


Re: [Mesa-dev] [PATCH 2/2] gles2: Add GL_NV_read_buffer extension

2012-06-15 Thread Brian Paul
On Fri, Jun 15, 2012 at 1:44 PM, Kristian Høgsberg  wrote:
> This lets us select the front buffer for reading under GLES2.
> ---
>  src/mapi/glapi/gen/es_EXT.xml  |    7 +++
>  src/mapi/glapi/gen/gles_api.py |    2 ++
>  src/mesa/main/APIspec.xml      |   13 +
>  src/mesa/main/extensions.c     |    1 +
>  src/mesa/main/get.c            |   20 +++-
>  src/mesa/main/mtypes.h         |    1 +
>  6 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index c7e7d07..b26cac5 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -627,4 +627,11 @@
>     
>  
>
> +
> +
> +    
> +        
> +    
> +
> +
>  
> diff --git a/src/mapi/glapi/gen/gles_api.py b/src/mapi/glapi/gen/gles_api.py
> index 0116ba4..70ae2e3 100644
> --- a/src/mapi/glapi/gen/gles_api.py
> +++ b/src/mapi/glapi/gen/gles_api.py
> @@ -451,4 +451,6 @@ es2_api = es2_core + (
>         'ProgramBinaryOES',
>         # GL_NV_draw_buffers
>         'DrawBuffersNV',
> +        # GL_NV_read_buffer
> +        'ReadBufferNV',
>  )
> diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
> index f23857a..64e666e 100644
> --- a/src/mesa/main/APIspec.xml
> +++ b/src/mesa/main/APIspec.xml
> @@ -3534,6 +3534,13 @@
>        
>  
>
> +
> +       
> +               
> +               
> +       
> +
> +
>  
>        
>
> @@ -3810,6 +3817,9 @@
>          template="EGLImageTargetRenderbufferStorage"/>
>
>        
> +
> +       
> +
>  
>
>  
> @@ -4150,7 +4160,10 @@
>         
>
>        
> +       
> +
>        
> +       
>
>        
>
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index 2688f7a..0e81783 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -300,6 +300,7 @@ static const struct extension extension_table[] = {
>    { "GL_NV_packed_depth_stencil",                 
> o(EXT_packed_depth_stencil),                GL,             2000 },
>    { "GL_NV_point_sprite",                         o(NV_point_sprite),        
>                  GL,             2001 },
>    { "GL_NV_primitive_restart",                    o(NV_primitive_restart),   
>                  GL,             2002 },
> +   { "GL_NV_read_buffer",                          o(dummy_true),            
>                   ES2,            2011 },
>    { "GL_NV_texgen_reflection",                    o(NV_texgen_reflection),   
>                  GL,             1999 },
>    { "GL_NV_texture_barrier",                      o(NV_texture_barrier),     
>                  GL,             2009 },
>    { "GL_NV_texture_env_combine4",                 
> o(NV_texture_env_combine4),                 GL,             1999 },
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index a8e1d86..969b55b 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -131,6 +131,7 @@ enum value_extra {
>    EXTRA_VERSION_30,
>    EXTRA_VERSION_31,
>    EXTRA_VERSION_32,
> +   EXTRA_API_GL,
>    EXTRA_API_ES2,
>    EXTRA_NEW_BUFFERS,
>    EXTRA_NEW_FRAG_CLAMP,
> @@ -369,6 +370,13 @@ extra_ARB_vertex_program_api_es2[] = {
>    EXTRA_END
>  };
>
> +static const int
> +extra_NV_read_buffer_api_gl[] = {
> +   EXT(NV_read_buffer),
> +   EXTRA_API_GL,

Is that right?  See below.


> +   EXTRA_END
> +};
> +
>  #define API_OPENGL_BIT (1 << API_OPENGL)
>  #define API_OPENGLES_BIT (1 << API_OPENGLES)
>  #define API_OPENGLES2_BIT (1 << API_OPENGLES2)
> @@ -750,6 +758,11 @@ static const struct value_desc values[] = {
>    /* GL_ARB_fragment_program/OES_standard_derivatives */
>    { GL_FRAGMENT_SHADER_DERIVATIVE_HINT_ARB,
>      CONTEXT_ENUM(Hint.FragmentShaderDerivative), extra_ARB_fragment_shader },
> +
> +   /* GL_NV_read_buffer */
> +   { GL_READ_BUFFER,
> +     LOC_CUSTOM, TYPE_ENUM, NO_OFFSET, extra_NV_read_buffer_api_gl },
> +
>  #endif /* FEATURE_GL || FEATURE_ES2 */
>
>  #if FEATURE_ES2
> @@ -884,7 +897,6 @@ static const struct value_desc values[] = {
>    { GL_POLYGON_SMOOTH, CONTEXT_BOOL(Polygon.SmoothFlag), NO_EXTRA },
>    { GL_POLYGON_SMOOTH_HINT, CONTEXT_ENUM(Hint.PolygonSmooth), NO_EXTRA },
>    { GL_POLYGON_STIPPLE, CONTEXT_BOOL(Polygon.StippleFlag), NO_EXTRA },
> -   { GL_READ_BUFFER, LOC_CUSTOM, TYPE_ENUM, NO_OFFSET, NO_EXTRA },
>    { GL_RED_BIAS, CONTEXT_FLOAT(Pixel.RedBias), NO_EXTRA },
>    { GL_RED_SCALE, CONTEXT_FLOAT(Pixel.RedScale), NO_EXTRA },
>    { GL_RENDER_MODE, CONTEXT_ENUM(RenderMode), NO_EXTRA },
> @@ -1814,6 +1826,12 @@ check_extra(struct gl_context *ctx, const char *func, 
> const struct value_desc *d
>            enabled++;
>         }
>         break;
> +      case EXTRA_API_GL:
> +        if (ctx->API == API_OPENGL) {
> +           total++;
> +           enabled++;
> +        }
> +        break;
>       case EXTRA_NEW_BUFFERS:
>         if (ctx->NewState & _NEW_BUFFERS)
>            _mesa_update_state(ctx);
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index ea40

Re: [Mesa-dev] [PATCH 1/2] get.c: Rename EXTRA_VERSION_ES2 to EXTRA_API_ES2

2012-06-15 Thread Brian Paul
On Fri, Jun 15, 2012 at 1:44 PM, Kristian Høgsberg  wrote:
> This extra condition checks the API not the version of the API, so rename
> to reflect that.


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


Re: [Mesa-dev] [PATCH 2/2] gles2: Add GL_NV_read_buffer extension

2012-06-15 Thread Kristian Høgsberg
On Fri, Jun 15, 2012 at 4:31 PM, Brian Paul  wrote:
> On Fri, Jun 15, 2012 at 1:44 PM, Kristian Høgsberg  wrote:
>> This lets us select the front buffer for reading under GLES2.
>> ---
>>  src/mapi/glapi/gen/es_EXT.xml  |    7 +++
>>  src/mapi/glapi/gen/gles_api.py |    2 ++
>>  src/mesa/main/APIspec.xml      |   13 +
>>  src/mesa/main/extensions.c     |    1 +
>>  src/mesa/main/get.c            |   20 +++-
>>  src/mesa/main/mtypes.h         |    1 +
>>  6 files changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
>> index c7e7d07..b26cac5 100644
>> --- a/src/mapi/glapi/gen/es_EXT.xml
>> +++ b/src/mapi/glapi/gen/es_EXT.xml
>> @@ -627,4 +627,11 @@
>>     
>>  
>>
>> +
>> +
>> +    
>> +        
>> +    
>> +
>> +
>>  
>> diff --git a/src/mapi/glapi/gen/gles_api.py b/src/mapi/glapi/gen/gles_api.py
>> index 0116ba4..70ae2e3 100644
>> --- a/src/mapi/glapi/gen/gles_api.py
>> +++ b/src/mapi/glapi/gen/gles_api.py
>> @@ -451,4 +451,6 @@ es2_api = es2_core + (
>>         'ProgramBinaryOES',
>>         # GL_NV_draw_buffers
>>         'DrawBuffersNV',
>> +        # GL_NV_read_buffer
>> +        'ReadBufferNV',
>>  )
>> diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
>> index f23857a..64e666e 100644
>> --- a/src/mesa/main/APIspec.xml
>> +++ b/src/mesa/main/APIspec.xml
>> @@ -3534,6 +3534,13 @@
>>        
>>  
>>
>> +
>> +       
>> +               
>> +               
>> +       
>> +
>> +
>>  
>>        
>>
>> @@ -3810,6 +3817,9 @@
>>         > template="EGLImageTargetRenderbufferStorage"/>
>>
>>        
>> +
>> +       
>> +
>>  
>>
>>  
>> @@ -4150,7 +4160,10 @@
>>         
>>
>>        
>> +       
>> +
>>        
>> +       
>>
>>        
>>
>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
>> index 2688f7a..0e81783 100644
>> --- a/src/mesa/main/extensions.c
>> +++ b/src/mesa/main/extensions.c
>> @@ -300,6 +300,7 @@ static const struct extension extension_table[] = {
>>    { "GL_NV_packed_depth_stencil",                 
>> o(EXT_packed_depth_stencil),                GL,             2000 },
>>    { "GL_NV_point_sprite",                         o(NV_point_sprite),       
>>                   GL,             2001 },
>>    { "GL_NV_primitive_restart",                    o(NV_primitive_restart),  
>>                   GL,             2002 },
>> +   { "GL_NV_read_buffer",                          o(dummy_true),           
>>                    ES2,            2011 },
>>    { "GL_NV_texgen_reflection",                    o(NV_texgen_reflection),  
>>                   GL,             1999 },
>>    { "GL_NV_texture_barrier",                      o(NV_texture_barrier),    
>>                   GL,             2009 },
>>    { "GL_NV_texture_env_combine4",                 
>> o(NV_texture_env_combine4),                 GL,             1999 },
>> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
>> index a8e1d86..969b55b 100644
>> --- a/src/mesa/main/get.c
>> +++ b/src/mesa/main/get.c
>> @@ -131,6 +131,7 @@ enum value_extra {
>>    EXTRA_VERSION_30,
>>    EXTRA_VERSION_31,
>>    EXTRA_VERSION_32,
>> +   EXTRA_API_GL,
>>    EXTRA_API_ES2,
>>    EXTRA_NEW_BUFFERS,
>>    EXTRA_NEW_FRAG_CLAMP,
>> @@ -369,6 +370,13 @@ extra_ARB_vertex_program_api_es2[] = {
>>    EXTRA_END
>>  };
>>
>> +static const int
>> +extra_NV_read_buffer_api_gl[] = {
>> +   EXT(NV_read_buffer),
>> +   EXTRA_API_GL,
>
> Is that right?  See below.
>
>
>> +   EXTRA_END
>> +};
>> +
>>  #define API_OPENGL_BIT (1 << API_OPENGL)
>>  #define API_OPENGLES_BIT (1 << API_OPENGLES)
>>  #define API_OPENGLES2_BIT (1 << API_OPENGLES2)
>> @@ -750,6 +758,11 @@ static const struct value_desc values[] = {
>>    /* GL_ARB_fragment_program/OES_standard_derivatives */
>>    { GL_FRAGMENT_SHADER_DERIVATIVE_HINT_ARB,
>>      CONTEXT_ENUM(Hint.FragmentShaderDerivative), extra_ARB_fragment_shader 
>> },
>> +
>> +   /* GL_NV_read_buffer */
>> +   { GL_READ_BUFFER,
>> +     LOC_CUSTOM, TYPE_ENUM, NO_OFFSET, extra_NV_read_buffer_api_gl },
>> +
>>  #endif /* FEATURE_GL || FEATURE_ES2 */
>>
>>  #if FEATURE_ES2
>> @@ -884,7 +897,6 @@ static const struct value_desc values[] = {
>>    { GL_POLYGON_SMOOTH, CONTEXT_BOOL(Polygon.SmoothFlag), NO_EXTRA },
>>    { GL_POLYGON_SMOOTH_HINT, CONTEXT_ENUM(Hint.PolygonSmooth), NO_EXTRA },
>>    { GL_POLYGON_STIPPLE, CONTEXT_BOOL(Polygon.StippleFlag), NO_EXTRA },
>> -   { GL_READ_BUFFER, LOC_CUSTOM, TYPE_ENUM, NO_OFFSET, NO_EXTRA },
>>    { GL_RED_BIAS, CONTEXT_FLOAT(Pixel.RedBias), NO_EXTRA },
>>    { GL_RED_SCALE, CONTEXT_FLOAT(Pixel.RedScale), NO_EXTRA },
>>    { GL_RENDER_MODE, CONTEXT_ENUM(RenderMode), NO_EXTRA },
>> @@ -1814,6 +1826,12 @@ check_extra(struct gl_context *ctx, const char *func, 
>> const struct value_desc *d
>>            enabled++;
>>         }
>>         break;
>> +      case EXTRA_API_GL:
>> +        if (ctx->API == API_OPENGL) {
>> +           total++;
>> +           enabled++;
>> +  

[Mesa-dev] [PATCH] clover: Add --with-clang-libdir option and verify CLANG_RESOURCE_DIR

2012-06-15 Thread Tom Stellard
$CLANG_RESOURCE_DIR is the directory that contains all resources
needed by clang to compile programs.  When clover uses clang to
compile kernels it needs to specify a resource dir, so that clang
can find its internal headers (e.g. stddef.h).

clang defines $CLANG_RESOURCE_DIR as $CLANG_LIBDIR/clang/$CLANG_VERSION

This patch adds the --with-clang-libdir option in order to accommodate
clang intalls to non-standard locations, and it also adds a check
to the configure script to verify that $CLANG_RESOURCE_DIR/include
contains the necessary header files.
---
 configure.ac  |   17 +
 src/gallium/state_trackers/clover/Makefile.am |2 +-
 2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index d5f8cd7..55ca1e4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1627,6 +1627,12 @@ AC_ARG_WITH([libclc-path],
[LIBCLC_PATH="$withval"],
[LIBCLC_PATH=""])
 
+AC_ARG_WITH([clang-libdir],
+   [AS_HELP_STRING([--with-clang-libdir],
+ [Path to Clang libraries @<:@default=llvm-config --libdir@:>@])],
+   [CLANG_LIBDIR="$withval"],
+   [CLANG_LIBDIR=""])
+
 AC_SUBST([LIBCLC_PATH])
 
 if test "x$enable_opencl" = xyes; then
@@ -1713,6 +1719,7 @@ AC_SUBST([LLVM_LIBS])
 AC_SUBST([LLVM_LDFLAGS])
 AC_SUBST([LLVM_INCLUDEDIR])
 AC_SUBST([LLVM_VERSION])
+AC_SUBST([CLANG_RESOURCE_DIR])
 
 case "x$enable_opengl$enable_gles1$enable_gles2" in
 x*yes*)
@@ -1887,6 +1894,16 @@ if test "x$enable_gallium_llvm" = xyes; then
LLVM_LIBDIR=`$LLVM_CONFIG --libdir`
DEFINES="${DEFINES} -DHAVE_LLVM=`echo $LLVM_VERSION | sed -e 
's/\([[0-9]]\)\.\([[0-9]]\)/0x0\10\2/g'`"
MESA_LLVM=1
+
+   dnl Check for Clang interanl headers
+if test "x$enable_opencl" = xyes; then
+if test "x$CLANG_LIBDIR" = x; then
+CLANG_LIBDIR=${LLVM_LIBDIR}
+fi
+CLANG_RESOURCE_DIR=$CLANG_LIBDIR/clang/${LLVM_VERSION}
+AC_CHECK_FILE("$CLANG_RESOURCE_DIR/include/stddef.h",,
+AC_MSG_ERROR([Could not find clang internal header stddef.h in 
$CLANG_RESOURCE_DIR Use --with-clang-libdir to specify the correct path to the 
clang libraries.]))
+fi
 else
MESA_LLVM=0
 fi
diff --git a/src/gallium/state_trackers/clover/Makefile.am 
b/src/gallium/state_trackers/clover/Makefile.am
index 818ced6..5241a6d 100644
--- a/src/gallium/state_trackers/clover/Makefile.am
+++ b/src/gallium/state_trackers/clover/Makefile.am
@@ -24,7 +24,7 @@ libclllvm_la_CXXFLAGS = \
$(LLVM_CPPFLAGS) \
$(DEFINES) \
-DLIBCLC_PATH=\"$(LIBCLC_PATH)/\" \
-   -DCLANG_RESOURCE_DIR=\"$(LLVM_LIBDIR)/clang/$(LLVM_VERSION)/\"
+   -DCLANG_RESOURCE_DIR=\"$(CLANG_RESOURCE_DIR)\"
 
 libclllvm_la_SOURCES = \
llvm/invocation.cpp
-- 
1.7.5.4

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


Re: [Mesa-dev] [PATCH 2/2] gles2: Add GL_NV_read_buffer extension

2012-06-15 Thread Brian Paul
On Fri, Jun 15, 2012 at 2:43 PM, Kristian Høgsberg  wrote:
> On Fri, Jun 15, 2012 at 4:31 PM, Brian Paul  wrote:
>> On Fri, Jun 15, 2012 at 1:44 PM, Kristian Høgsberg  
>> wrote:
>>> This lets us select the front buffer for reading under GLES2.
>>> ---
>>>  src/mapi/glapi/gen/es_EXT.xml  |    7 +++
>>>  src/mapi/glapi/gen/gles_api.py |    2 ++
>>>  src/mesa/main/APIspec.xml      |   13 +
>>>  src/mesa/main/extensions.c     |    1 +
>>>  src/mesa/main/get.c            |   20 +++-
>>>  src/mesa/main/mtypes.h         |    1 +
>>>  6 files changed, 43 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
>>> index c7e7d07..b26cac5 100644
>>> --- a/src/mapi/glapi/gen/es_EXT.xml
>>> +++ b/src/mapi/glapi/gen/es_EXT.xml
>>> @@ -627,4 +627,11 @@
>>>     
>>>  
>>>
>>> +
>>> +
>>> +    
>>> +        
>>> +    
>>> +
>>> +
>>>  
>>> diff --git a/src/mapi/glapi/gen/gles_api.py b/src/mapi/glapi/gen/gles_api.py
>>> index 0116ba4..70ae2e3 100644
>>> --- a/src/mapi/glapi/gen/gles_api.py
>>> +++ b/src/mapi/glapi/gen/gles_api.py
>>> @@ -451,4 +451,6 @@ es2_api = es2_core + (
>>>         'ProgramBinaryOES',
>>>         # GL_NV_draw_buffers
>>>         'DrawBuffersNV',
>>> +        # GL_NV_read_buffer
>>> +        'ReadBufferNV',
>>>  )
>>> diff --git a/src/mesa/main/APIspec.xml b/src/mesa/main/APIspec.xml
>>> index f23857a..64e666e 100644
>>> --- a/src/mesa/main/APIspec.xml
>>> +++ b/src/mesa/main/APIspec.xml
>>> @@ -3534,6 +3534,13 @@
>>>        
>>>  
>>>
>>> +
>>> +       
>>> +               
>>> +               
>>> +       
>>> +
>>> +
>>>  
>>>        
>>>
>>> @@ -3810,6 +3817,9 @@
>>>         >> template="EGLImageTargetRenderbufferStorage"/>
>>>
>>>        
>>> +
>>> +       
>>> +
>>>  
>>>
>>>  
>>> @@ -4150,7 +4160,10 @@
>>>         
>>>
>>>        
>>> +       
>>> +
>>>        
>>> +       
>>>
>>>        
>>>
>>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
>>> index 2688f7a..0e81783 100644
>>> --- a/src/mesa/main/extensions.c
>>> +++ b/src/mesa/main/extensions.c
>>> @@ -300,6 +300,7 @@ static const struct extension extension_table[] = {
>>>    { "GL_NV_packed_depth_stencil",                 
>>> o(EXT_packed_depth_stencil),                GL,             2000 },
>>>    { "GL_NV_point_sprite",                         o(NV_point_sprite),      
>>>                    GL,             2001 },
>>>    { "GL_NV_primitive_restart",                    o(NV_primitive_restart), 
>>>                    GL,             2002 },
>>> +   { "GL_NV_read_buffer",                          o(dummy_true),          
>>>                     ES2,            2011 },
>>>    { "GL_NV_texgen_reflection",                    o(NV_texgen_reflection), 
>>>                    GL,             1999 },
>>>    { "GL_NV_texture_barrier",                      o(NV_texture_barrier),   
>>>                    GL,             2009 },
>>>    { "GL_NV_texture_env_combine4",                 
>>> o(NV_texture_env_combine4),                 GL,             1999 },
>>> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
>>> index a8e1d86..969b55b 100644
>>> --- a/src/mesa/main/get.c
>>> +++ b/src/mesa/main/get.c
>>> @@ -131,6 +131,7 @@ enum value_extra {
>>>    EXTRA_VERSION_30,
>>>    EXTRA_VERSION_31,
>>>    EXTRA_VERSION_32,
>>> +   EXTRA_API_GL,
>>>    EXTRA_API_ES2,
>>>    EXTRA_NEW_BUFFERS,
>>>    EXTRA_NEW_FRAG_CLAMP,
>>> @@ -369,6 +370,13 @@ extra_ARB_vertex_program_api_es2[] = {
>>>    EXTRA_END
>>>  };
>>>
>>> +static const int
>>> +extra_NV_read_buffer_api_gl[] = {
>>> +   EXT(NV_read_buffer),
>>> +   EXTRA_API_GL,
>>
>> Is that right?  See below.
>>
>>
>>> +   EXTRA_END
>>> +};
>>> +
>>>  #define API_OPENGL_BIT (1 << API_OPENGL)
>>>  #define API_OPENGLES_BIT (1 << API_OPENGLES)
>>>  #define API_OPENGLES2_BIT (1 << API_OPENGLES2)
>>> @@ -750,6 +758,11 @@ static const struct value_desc values[] = {
>>>    /* GL_ARB_fragment_program/OES_standard_derivatives */
>>>    { GL_FRAGMENT_SHADER_DERIVATIVE_HINT_ARB,
>>>      CONTEXT_ENUM(Hint.FragmentShaderDerivative), extra_ARB_fragment_shader 
>>> },
>>> +
>>> +   /* GL_NV_read_buffer */
>>> +   { GL_READ_BUFFER,
>>> +     LOC_CUSTOM, TYPE_ENUM, NO_OFFSET, extra_NV_read_buffer_api_gl },
>>> +
>>>  #endif /* FEATURE_GL || FEATURE_ES2 */
>>>
>>>  #if FEATURE_ES2
>>> @@ -884,7 +897,6 @@ static const struct value_desc values[] = {
>>>    { GL_POLYGON_SMOOTH, CONTEXT_BOOL(Polygon.SmoothFlag), NO_EXTRA },
>>>    { GL_POLYGON_SMOOTH_HINT, CONTEXT_ENUM(Hint.PolygonSmooth), NO_EXTRA },
>>>    { GL_POLYGON_STIPPLE, CONTEXT_BOOL(Polygon.StippleFlag), NO_EXTRA },
>>> -   { GL_READ_BUFFER, LOC_CUSTOM, TYPE_ENUM, NO_OFFSET, NO_EXTRA },
>>>    { GL_RED_BIAS, CONTEXT_FLOAT(Pixel.RedBias), NO_EXTRA },
>>>    { GL_RED_SCALE, CONTEXT_FLOAT(Pixel.RedScale), NO_EXTRA },
>>>    { GL_RENDER_MODE, CONTEXT_ENUM(RenderMode), NO_EXTRA },
>>> @@ -1814,6 +1826,12 @@ check_extra(struct gl_context *ctx, const char 
>>> *f

Re: [Mesa-dev] [PATCH 2/2] gles2: Add GL_NV_read_buffer extension

2012-06-15 Thread Kenneth Graunke

On 06/15/2012 12:44 PM, Kristian Høgsberg wrote:

This lets us select the front buffer for reading under GLES2.


For the series:
Reviewed-by: Kenneth Graunke 

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


Re: [Mesa-dev] [PATCH 1/4] mesa: if AllocStorage doesn't choose a format, report FRAMEBUFFER_UNSUPPORTED

2012-06-15 Thread Kenneth Graunke

On 06/15/2012 10:07 AM, Marek Olšák wrote:

This allows drivers not to do any allocation in AllocStorage if the storage
cannot be allocated because of an unsupported internalformat + samples combo.

The little ugliness is that AllocStorage is expected to return TRUE in this
case.


Looks good to me.  For patch 1:
Reviewed-by: Kenneth Graunke 


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


[Mesa-dev] [PATCH] r600g: fix z/stencil texture creation v2

2012-06-15 Thread j . glisse
From: Jerome Glisse 

z or stencil texture should not be created with the z/stencil
flags for surface creation as they are intended to be bound
as texture.

v2: remove broken code

Signed-off-by: Jerome Glisse 
---
 src/gallium/drivers/r600/r600_texture.c |   32 --
 1 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/src/gallium/drivers/r600/r600_texture.c 
b/src/gallium/drivers/r600/r600_texture.c
index 5b15990..fe9a923 100644
--- a/src/gallium/drivers/r600/r600_texture.c
+++ b/src/gallium/drivers/r600/r600_texture.c
@@ -237,7 +237,7 @@ static void r600_texture_set_array_mode(struct pipe_screen 
*screen,
 
 static int r600_init_surface(struct radeon_surface *surface,
 const struct pipe_resource *ptex,
-unsigned array_mode)
+unsigned array_mode, bool is_transfer)
 {
surface->npix_x = ptex->width0;
surface->npix_y = ptex->height0;
@@ -298,7 +298,7 @@ static int r600_init_surface(struct radeon_surface *surface,
if (ptex->bind & PIPE_BIND_SCANOUT) {
surface->flags |= RADEON_SURF_SCANOUT;
}
-   if (util_format_is_depth_and_stencil(ptex->format)) {
+   if (util_format_is_depth_and_stencil(ptex->format) && !is_transfer) {
surface->flags |= RADEON_SURF_ZBUFFER;
surface->flags |= RADEON_SURF_SBUFFER;
}
@@ -316,11 +316,6 @@ static int r600_setup_surface(struct pipe_screen *screen,
unsigned i;
int r;
 
-   if (util_format_is_depth_or_stencil(rtex->real_format)) {
-   rtex->surface.flags |= RADEON_SURF_ZBUFFER;
-   rtex->surface.flags |= RADEON_SURF_SBUFFER;
-   }
-
r = rscreen->ws->surface_init(rscreen->ws, &rtex->surface);
if (r) {
return r;
@@ -572,7 +567,8 @@ r600_texture_create_object(struct pipe_screen *screen,
r600_setup_miptree(screen, rtex, array_mode);
if (rscreen->use_surface_alloc) {
rtex->surface = *surface;
-   r = r600_setup_surface(screen, rtex, array_mode, 
pitch_in_bytes_override);
+   r = r600_setup_surface(screen, rtex, array_mode,
+  pitch_in_bytes_override);
if (r) {
FREE(rtex);
return NULL;
@@ -642,7 +638,8 @@ struct pipe_resource *r600_texture_create(struct 
pipe_screen *screen,
}
}
 
-   r = r600_init_surface(&surface, templ, array_mode);
+   r = r600_init_surface(&surface, templ, array_mode,
+ templ->flags & R600_RESOURCE_FLAG_TRANSFER);
if (r) {
return NULL;
}
@@ -723,7 +720,7 @@ struct pipe_resource *r600_texture_from_handle(struct 
pipe_screen *screen,
else
array_mode = 0;
 
-   r = r600_init_surface(&surface, templ, array_mode);
+   r = r600_init_surface(&surface, templ, array_mode, 0);
if (r) {
return NULL;
}
@@ -796,8 +793,9 @@ struct pipe_transfer* r600_texture_get_transfer(struct 
pipe_context *ctx,
 * the CPU is much happier reading out of cached system memory
 * than uncached VRAM.
 */
-   if (R600_TEX_IS_TILED(rtex, level))
+   if (R600_TEX_IS_TILED(rtex, level)) {
use_staging_texture = TRUE;
+   }
 
if ((usage & PIPE_TRANSFER_READ) && u_box_volume(box) > 1024)
use_staging_texture = TRUE;
@@ -805,15 +803,18 @@ struct pipe_transfer* r600_texture_get_transfer(struct 
pipe_context *ctx,
/* Use a staging texture for uploads if the underlying BO is busy. */
if (!(usage & PIPE_TRANSFER_READ) &&
(rctx->ws->cs_is_buffer_referenced(rctx->cs, rtex->resource.cs_buf, 
RADEON_USAGE_READWRITE) ||
-rctx->ws->buffer_is_busy(rtex->resource.buf, 
RADEON_USAGE_READWRITE)))
+rctx->ws->buffer_is_busy(rtex->resource.buf, 
RADEON_USAGE_READWRITE))) {
use_staging_texture = TRUE;
+   }
 
if (!permit_hardware_blit(ctx->screen, texture) ||
-   (texture->flags & R600_RESOURCE_FLAG_TRANSFER))
+   (texture->flags & R600_RESOURCE_FLAG_TRANSFER)) {
use_staging_texture = FALSE;
+   }
 
-   if (use_staging_texture && (usage & PIPE_TRANSFER_MAP_DIRECTLY))
+   if (use_staging_texture && (usage & PIPE_TRANSFER_MAP_DIRECTLY)) {
return NULL;
+   }
 
trans = CALLOC_STRUCT(r600_transfer);
if (trans == NULL)
@@ -898,8 +899,9 @@ void r600_texture_transfer_destroy(struct pipe_context *ctx,
}
 
if (rtex->is_depth && !rtex->is_flushing_texture) {
-   if ((transfer->usage & PIPE_TRANSFER_WRITE) && 
rtex->flushed_depth_texture)
+   if ((transfer->usage & PIPE_TRANSFER_WRITE) && 
rtex->flushed_depth_texture) {
r600_blit_push_

Re: [Mesa-dev] [RFC PATCH] i965/msaa: Disable unsupported formats.

2012-06-15 Thread Chad Versace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/15/2012 11:12 AM, Paul Berry wrote:
> Due to hardware limitations, MSAA is unsupported on Gen6 for formats
> containing >64 bits of data per pixel.  From the Sandy Bridge PRM,
> vol4 part1, p72 ("Surface Format"):
> 
> If Number of Multisamples is set to a value other than
> MULTISAMPLECOUNT_1, this field cannot be set to the following
> formats:
> - any format with greater than 64 bits per element
> - any compressed texture format (BC*)
> - any YCRCB* format
> 
> Gen7 has a similar, but less stringent limitation: formats with >64
> bits of data per pixel only support 4x MSAA.
> 
> This patch causes the unsupported formats to report
> GL_FRAMEBUFFER_UNSUPPORTED.
> 
> Fixes piglit "multisample-formats" tests on Gen6.
> ---
> 
> It is not 100% clear to me whether this approach is compliant with the
> spec.  On the one hand, the spec requires formats RGBA32F, RGBA32I,
> and RGBA32UI to be color-renderable.  On the other hand, the spec
> allows for the implementation to report GL_FRAMEBUFFER_UNSUPPORTED if
> the set of attached images violates "an implementation-dependent set
> of restrictions", which seems to leave a lot of leeway.
> 
> If we decide that it's not ok to report GL_FRAMEBUFFER_UNSUPPORTED for
> MSAA buffers using these formats, then we'll have to figure out some
> other way to work around the hardware's lack of support for MSAA on
> these formats, and I haven't thought of a good way to do that.  The
> alternatives I've considered (substitute another buffer format, or
> substitute a non-multisampled renderbuffer) are definitely
> non-spec-compliant, and also fraught with implementation difficulties.
> 
> So for the moment my inclination is to go through with this patch as
> is, and if we later discover that it causes trouble for a client
> application, we can consider other options.  I'm curious to hear what
> others think.

After releasing GL3.0, but before implementing real MSAA, we lied to the app.
If the app requested an MSAA buffer, we said "ok" and just created a 
single-sample
buffer.

Can we do that for these formats? It may be better to do that than report
GL_FRAMEBUFFER_UNSUPPORTED. I'm unsure what's best, though.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP26yvAAoJEAIvNt057x8iJjAP/RSt81atGhBXTqBgBjmTwDrc
Y96MJxenirLr2MM8XzYUtYP+iOLvcYpYqJSpYpt6m7RCmLapnQTsYflh+QDD83Ba
ZJIxuBEM3ILflPNVp2YY+dBkVlq4TNMSONsOeOR1P/ro6EyBrnHhsKz3dODlzfZ5
vSSli6xS/blTiKFODQck5lhJi5FSwHxEfF/IbZKWkxULzFTrOOIHg7dns8YYtmI/
CeG1XdNuwc7tes9hh81uRNNR0kXXDv+0ph79w7JbQVbNdGSQYw037w+TVG7QJNMk
8ZPDqGyl7U+6jx8TyWtrZG+BMlIC13vSfSkPWmVpaGKXp/BfMwkXfuCcry4BeQfz
r1zFRSTvaZG3xQNOD8n5YKaZBOdI4AmRdJlRX8OQbpZpI+V6fZaG6qkxliTpF6yu
qc81yL96UMQoqNCkSCH4bp5r95QvxlxXv3xKrup0ORnw+ExzRd+Iq7B9sQbga1nw
tjoRdLPReWI++eWKFfsP1ew8+dMdQP+ENZkBdi/WDjnuXQFSqvqmUp1VWifVLXCv
mHXlGd62Vo9Urb6qDmKbUgbYyewaAtAV756L0ytvlv8+zdf7a4wtePsbJW4+cN0G
nzsHVryS6maT8nLizCIlkXT+y6NSzV2+Lt5Yq9pU76NCfsEpqbI+OxbMvLbPa81/
1yo9AjVqJ1SyuX+fXMyp
=/emk
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 0/4] Implement GL_ARB_base_instance

2012-06-15 Thread Fredrik Höglund
This patch series adds support for ARB_base_instance in core mesa
and the mesa state tracker.

According to the ARB_draw_instanced spec it's not legal to call
the DrawInstanced entry points during display list compilation,
but the ARB_base_instance spec doesn't say anything about this.
I made the new entry points generate the same error for now,
since I assume that this is an omission.

Also note I'm not all that familiar with the vbo module, so it's
quite possible that I've overlooked something there.

Please review and push if there are no issues.

Fredrik Höglund (4):
  mesa: Add support for GL_ARB_base_instance
  gallium: Add PIPE_CAP_START_INSTANCE
  st/mesa: Add support for GL_ARB_base_instance
  docs: update GL3.txt for ARB_base_instance

 docs/GL3.txt |2 +-
 src/gallium/docs/source/screen.rst   |3 +-
 src/gallium/drivers/i915/i915_screen.c   |1 +
 src/gallium/drivers/nv30/nv30_screen.c   |1 +
 src/gallium/drivers/nv50/nv50_screen.c   |1 +
 src/gallium/drivers/nvc0/nvc0_screen.c   |1 +
 src/gallium/drivers/r300/r300_screen.c   |1 +
 src/gallium/drivers/r600/r600_pipe.c |1 +
 src/gallium/drivers/radeonsi/radeonsi_pipe.c |1 +
 src/gallium/drivers/svga/svga_screen.c   |1 +
 src/gallium/include/pipe/p_defines.h |3 +-
 src/mapi/glapi/gen/ARB_base_instance.xml |   40 +
 src/mapi/glapi/gen/Makefile  |1 +
 src/mapi/glapi/gen/gl_API.xml|3 +-
 src/mesa/main/dd.h   |   10 ++
 src/mesa/main/dlist.c|   45 ++
 src/mesa/main/extensions.c   |1 +
 src/mesa/main/mtypes.h   |1 +
 src/mesa/main/vtxfmt.c   |3 +
 src/mesa/state_tracker/st_draw.c |1 +
 src/mesa/state_tracker/st_extensions.c   |1 +
 src/mesa/vbo/vbo.h   |1 +
 src/mesa/vbo/vbo_exec_api.c  |1 +
 src/mesa/vbo/vbo_exec_array.c|  114 --
 src/mesa/vbo/vbo_save_api.c  |2 +
 src/mesa/vbo/vbo_split_inplace.c |6 +-
 26 files changed, 231 insertions(+), 15 deletions(-)

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


[Mesa-dev] [PATCH 3/4] st/mesa: Add support for GL_ARB_base_instance

2012-06-15 Thread Fredrik Höglund
---
 src/mesa/state_tracker/st_draw.c   |1 +
 src/mesa/state_tracker/st_extensions.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index db8caa5..5084912 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -246,6 +246,7 @@ st_draw_vbo(struct gl_context *ctx,
   info.mode = translate_prim( ctx, prims[i].mode );
   info.start = prims[i].start;
   info.count = prims[i].count;
+  info.start_instance = prims[i].baseinstance;
   info.instance_count = prims[i].num_instances;
   info.index_bias = prims[i].basevertex;
   if (!ib) {
diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index a9071f5..17f271f 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -337,6 +337,7 @@ void st_init_extensions(struct st_context *st)
GLboolean *extensions = (GLboolean *) &ctx->Extensions;
 
static const struct st_extension_cap_mapping cap_mapping[] = {
+  { o(ARB_base_instance),PIPE_CAP_START_INSTANCE   
},
   { o(ARB_depth_clamp),  PIPE_CAP_DEPTH_CLIP_DISABLE   
},
   { o(ARB_depth_texture),PIPE_CAP_TEXTURE_SHADOW_MAP   
},
   { o(ARB_draw_buffers_blend),   PIPE_CAP_INDEP_BLEND_FUNC 
},
-- 
1.7.7.3

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


[Mesa-dev] [PATCH 1/4] mesa: Add support for GL_ARB_base_instance

2012-06-15 Thread Fredrik Höglund
---
 src/mapi/glapi/gen/ARB_base_instance.xml |   40 +++
 src/mapi/glapi/gen/Makefile  |1 +
 src/mapi/glapi/gen/gl_API.xml|3 +-
 src/mesa/main/dd.h   |   10 +++
 src/mesa/main/dlist.c|   45 
 src/mesa/main/extensions.c   |1 +
 src/mesa/main/mtypes.h   |1 +
 src/mesa/main/vtxfmt.c   |3 +
 src/mesa/vbo/vbo.h   |1 +
 src/mesa/vbo/vbo_exec_api.c  |1 +
 src/mesa/vbo/vbo_exec_array.c|  114 +++---
 src/mesa/vbo/vbo_save_api.c  |2 +
 src/mesa/vbo/vbo_split_inplace.c |6 +-
 13 files changed, 216 insertions(+), 12 deletions(-)
 create mode 100644 src/mapi/glapi/gen/ARB_base_instance.xml

diff --git a/src/mapi/glapi/gen/ARB_base_instance.xml 
b/src/mapi/glapi/gen/ARB_base_instance.xml
new file mode 100644
index 000..8e81553
--- /dev/null
+++ b/src/mapi/glapi/gen/ARB_base_instance.xml
@@ -0,0 +1,40 @@
+
+
+
+
+
+
+
+
+
+
+  
+
+
+
+
+
+  
+
+  
+
+
+
+
+
+
+  
+
+  
+
+
+
+
+
+
+
+  
+
+
+
+
diff --git a/src/mapi/glapi/gen/Makefile b/src/mapi/glapi/gen/Makefile
index 75dbb14..0ac7989 100644
--- a/src/mapi/glapi/gen/Makefile
+++ b/src/mapi/glapi/gen/Makefile
@@ -63,6 +63,7 @@ XORG_OUTPUTS = \
 
 API_XML = \
gl_API.xml \
+   ARB_base_instance.xml \
ARB_color_buffer_float.xml \
ARB_copy_buffer.xml \
ARB_debug_output.xml \
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index 4bd0fc6..c96b2a0 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -7995,8 +7995,9 @@
 
 
 
-http://www.w3.org/2001/XInclude"/>
+http://www.w3.org/2001/XInclude"/>
 
+http://www.w3.org/2001/XInclude"/>
 
 
 
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 1582a8c..5bcf36b 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1029,12 +1029,22 @@ typedef struct {
   const GLint *basevertex);
void (GLAPIENTRYP DrawArraysInstanced)(GLenum mode, GLint first,
   GLsizei count, GLsizei primcount);
+   void (GLAPIENTRYP DrawArraysInstancedBaseInstance)(GLenum mode, GLint first,
+  GLsizei count, GLsizei 
primcount,
+  GLuint baseinstance);
void (GLAPIENTRYP DrawElementsInstanced)(GLenum mode, GLsizei count,
 GLenum type, const GLvoid *indices,
 GLsizei primcount);
+   void (GLAPIENTRYP DrawElementsInstancedBaseInstance)(GLenum mode, GLsizei 
count,
+GLenum type, const 
GLvoid *indices,
+GLsizei primcount, 
GLuint baseinstance);
void (GLAPIENTRYP DrawElementsInstancedBaseVertex)(GLenum mode, GLsizei 
count,
 GLenum type, const GLvoid *indices,
 GLsizei primcount, GLint 
basevertex);
+   void (GLAPIENTRYP DrawElementsInstancedBaseVertexBaseInstance)(GLenum mode, 
GLsizei count,
+  GLenum type, 
const GLvoid *indices,
+  GLsizei 
primcount, GLint basevertex,
+  GLuint 
baseinstance);
void (GLAPIENTRYP DrawTransformFeedback)(GLenum mode, GLuint name);
/*@}*/
 
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index e04f7ae..a0d84cf 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -1337,6 +1337,46 @@ save_DrawElementsInstancedBaseVertexARB(GLenum mode,
   "glDrawElementsInstancedBaseVertex() during display list 
compile");
 }
 
+/* GL_ARB_base_instance. */
+static void GLAPIENTRY
+save_DrawArraysInstancedBaseInstance(GLenum mode,
+ GLint first,
+ GLsizei count,
+ GLsizei primcount,
+ GLuint baseinstance)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   _mesa_error(ctx, GL_INVALID_OPERATION,
+  "glDrawArraysInstancedBaseInstance() during display list 
compile");
+}
+
+static void APIENTRY
+save_DrawElementsInstancedBaseInstance(GLenum mode,
+   GLsizei count,
+   GLenum type,
+   const void *indices,
+   GLsizei primcount,
+   GLuint baseinstance)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   _mesa_error(ct

[Mesa-dev] [PATCH 4/4] docs: update GL3.txt for ARB_base_instance

2012-06-15 Thread Fredrik Höglund
---
 docs/GL3.txt |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/docs/GL3.txt b/docs/GL3.txt
index 17136de..89b46c0 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -119,7 +119,7 @@ GL_ARB_compressed_texture_pixel_storage  not 
started
 GL_ARB_shader_atomic_countersnot started
 GL_ARB_texture_storage   DONE (r300, r600, swrast)
 GL_ARB_transform_feedback_instanced  not started
-GL_ARB_base_instance not started
+GL_ARB_base_instance DONE (nv50, nvc0, r600, 
radeonsi)
 GL_ARB_shader_image_load_store   not started
 GL_ARB_conservative_depthDONE (softpipe)
 GL_ARB_shading_language_420pack  not started
-- 
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/4] gallium: Add PIPE_CAP_START_INSTANCE

2012-06-15 Thread Fredrik Höglund
---
 src/gallium/docs/source/screen.rst   |3 ++-
 src/gallium/drivers/i915/i915_screen.c   |1 +
 src/gallium/drivers/nv30/nv30_screen.c   |1 +
 src/gallium/drivers/nv50/nv50_screen.c   |1 +
 src/gallium/drivers/nvc0/nvc0_screen.c   |1 +
 src/gallium/drivers/r300/r300_screen.c   |1 +
 src/gallium/drivers/r600/r600_pipe.c |1 +
 src/gallium/drivers/radeonsi/radeonsi_pipe.c |1 +
 src/gallium/drivers/svga/svga_screen.c   |1 +
 src/gallium/include/pipe/p_defines.h |3 ++-
 10 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index c86e1c6..2c683ef 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -126,7 +126,8 @@ The integer capabilities:
   resources.
 * ``PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT``: Describes the required
   alignment of pipe_constant_buffer::buffer_offset.
-
+* ``PIPE_CAP_START_INSTANCE``: Whether the driver supports
+  pipe_draw_info::start_instance.
 
 
 .. _pipe_capf:
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index 0046860..9f29339 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -206,6 +206,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
case PIPE_CAP_VERTEX_COLOR_UNCLAMPED:
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
+   case PIPE_CAP_START_INSTANCE:
   return 0;
 
case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
diff --git a/src/gallium/drivers/nv30/nv30_screen.c 
b/src/gallium/drivers/nv30/nv30_screen.c
index f9e647d..ffb49c9 100644
--- a/src/gallium/drivers/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nv30/nv30_screen.c
@@ -115,6 +115,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_VERTEX_COLOR_UNCLAMPED:
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
case PIPE_CAP_MIXED_COLORBUFFER_FORMATS:
+   case PIPE_CAP_START_INSTANCE:
   return 0;
case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
diff --git a/src/gallium/drivers/nv50/nv50_screen.c 
b/src/gallium/drivers/nv50/nv50_screen.c
index 9567abb..6c3f69f 100644
--- a/src/gallium/drivers/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nv50/nv50_screen.c
@@ -148,6 +148,7 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_CONDITIONAL_RENDER:
case PIPE_CAP_TEXTURE_BARRIER:
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
+   case PIPE_CAP_START_INSTANCE:
   return 1;
case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS:
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
diff --git a/src/gallium/drivers/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nvc0/nvc0_screen.c
index 49d6118..0ed3a56 100644
--- a/src/gallium/drivers/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nvc0/nvc0_screen.c
@@ -136,6 +136,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_CONDITIONAL_RENDER:
case PIPE_CAP_TEXTURE_BARRIER:
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
+   case PIPE_CAP_START_INSTANCE:
   return 1;
case PIPE_CAP_TGSI_CAN_COMPACT_VARYINGS:
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
diff --git a/src/gallium/drivers/r300/r300_screen.c 
b/src/gallium/drivers/r300/r300_screen.c
index da47fa2..749c850 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src/gallium/drivers/r300/r300_screen.c
@@ -147,6 +147,7 @@ static int r300_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
 case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
 case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
 case PIPE_CAP_COMPUTE:
+case PIPE_CAP_START_INSTANCE:
 return 0;
 
 /* SWTCL-only features. */
diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index e0ee823..2155ad7 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -383,6 +383,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
case PIPE_CAP_USER_INDEX_BUFFERS:
case PIPE_CAP_USER_CONSTANT_BUFFERS:
case PIPE_CAP_COMPUTE:
+   case PIPE_CAP_START_INSTANCE:
return 1;
 
case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pipe.c 
b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
index 8dd7137..e58a35d 100644
--- a/src/gallium/drivers/radeonsi/radeonsi_pipe.c
+++ b/src/gallium/drivers/radeonsi/radeonsi_pipe.c
@@ -325,6 +325,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum 
pipe_cap param)
case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_USER_INDEX_BUFFERS:
   

[Mesa-dev] [8.0 cherry-pick RFC] Fix bug 46431

2012-06-15 Thread Chad Versace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I want to cherry-pick a short series of 3 to 8.0, but want to check others if
they suspect any problems with the series. If no one responds by Monday morning,
I'll cherry-pick it then.

You can view the series at
http://cgit.freedesktop.org/~chadversary/mesa/log/?h=8.0-bug-46431

Patches 1 and 2 fix
Bug 46431 - [bisected i965] piglit spec/EXT_texture_integer/api-teximage 
fails on mesa 8.0
https://bugs.freedesktop.org/show_bug.cgi?id=46431

Patch 3 is related to 1 and 2. It adds a missing enum to a switch.

- 
Brian Paul (2):
  mesa: new _mesa_error_check_format_and_type() function
  mesa: add missing GL_UNSIGNED_INT_10F_11F_11F_REV case

Marek Olšák (1):
  mesa: allow exposing GL3 without EXT_texture_integer

 src/mesa/main/fbobject.c|   16 ++--
 src/mesa/main/image.c   |  221 +++
 src/mesa/main/image.h   |6 +-
 src/mesa/main/readpix.c |9 +-
 src/mesa/main/texformat.c   |   10 +-
 src/mesa/main/texgetimage.c |   16 ++--
 src/mesa/main/teximage.c|   39 
 src/mesa/main/version.c |1 -
 8 files changed, 216 insertions(+), 102 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP27ImAAoJEAIvNt057x8iwk8P/1AaZOowcNklc4qGSrrXe68C
fwQex9wGjMzd+WOGG50Za2lPF3TAT+sFfpvJeh+QEKZz/LNRBQ4hqaS9Qma0qkyQ
zInjyTJxHWsxKmAAnojU1yAnRor4nxmHlEeV8dG2woyiKYY7X6lMhz2ORjKdxQ+m
011/jmUbIdKVhj6MgeJ0/cihh/BqC9Wl4jRKu/FWWOaG/TiSm9JdrBF/YTU6fxXr
fF0FoasCr8iS4s9oHkmLFQnkGS1hh4W3QeJleO6uvOfjiCwNKeI4NuXSNnDW1sdr
bDfCdyYe5z4B3IKg3NQHPiu2xL+9lnzvTLXgVo4TkPD0OqPeMmbA8V1EHcz2lY5P
BZHOqg0YHauidX1xiO2F/EurHiPwYxjDg/t34Q/i7cjAOsxPAGRxNZPBMLIyZ6y1
s/ShbjGskfSL7jwvDgRINU9t5/zZW9Si5f3h8ByDqakMZBBhbFJ5018VfqQ2ppgJ
eoOoRIu/J0UZHCvh3DkyOk9OMiWLQ14IXrKrnd+m4ZjbxP0MAXKz0oM2C/gKyynz
oCSt65wkYfeGWSd1RCWU0LbKPw69AjESdnXKXwgDiKp91q9ZGAtlRIOddXKdV79L
dTpuEmJ+ho3ytyj+DbJuiaHlmdoUWGasd+DRdQ97rkO3keqgEoAKrfVwWVCXxmN0
hVeVrEPaVuEvPW+xsLT+
=XUhU
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC PATCH] i965/msaa: Disable unsupported formats.

2012-06-15 Thread Paul Berry
On 15 June 2012 14:44, Chad Versace  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/15/2012 11:12 AM, Paul Berry wrote:
> > Due to hardware limitations, MSAA is unsupported on Gen6 for formats
> > containing >64 bits of data per pixel.  From the Sandy Bridge PRM,
> > vol4 part1, p72 ("Surface Format"):
> >
> > If Number of Multisamples is set to a value other than
> > MULTISAMPLECOUNT_1, this field cannot be set to the following
> > formats:
> > - any format with greater than 64 bits per element
> > - any compressed texture format (BC*)
> > - any YCRCB* format
> >
> > Gen7 has a similar, but less stringent limitation: formats with >64
> > bits of data per pixel only support 4x MSAA.
> >
> > This patch causes the unsupported formats to report
> > GL_FRAMEBUFFER_UNSUPPORTED.
> >
> > Fixes piglit "multisample-formats" tests on Gen6.
> > ---
> >
> > It is not 100% clear to me whether this approach is compliant with the
> > spec.  On the one hand, the spec requires formats RGBA32F, RGBA32I,
> > and RGBA32UI to be color-renderable.  On the other hand, the spec
> > allows for the implementation to report GL_FRAMEBUFFER_UNSUPPORTED if
> > the set of attached images violates "an implementation-dependent set
> > of restrictions", which seems to leave a lot of leeway.
> >
> > If we decide that it's not ok to report GL_FRAMEBUFFER_UNSUPPORTED for
> > MSAA buffers using these formats, then we'll have to figure out some
> > other way to work around the hardware's lack of support for MSAA on
> > these formats, and I haven't thought of a good way to do that.  The
> > alternatives I've considered (substitute another buffer format, or
> > substitute a non-multisampled renderbuffer) are definitely
> > non-spec-compliant, and also fraught with implementation difficulties.
> >
> > So for the moment my inclination is to go through with this patch as
> > is, and if we later discover that it causes trouble for a client
> > application, we can consider other options.  I'm curious to hear what
> > others think.
>
> After releasing GL3.0, but before implementing real MSAA, we lied to the
> app.
> If the app requested an MSAA buffer, we said "ok" and just created a
> single-sample
> buffer.
>
> Can we do that for these formats? It may be better to do that than report
> GL_FRAMEBUFFER_UNSUPPORTED. I'm unsure what's best, though.
>

Thanks for the suggestion.  At the risk of giving off the impression that I
already have my mind made up, I *did* consider this approach, and here's
why I rejected it: all attachments to a framebuffer need to have the same
sample count.  So if we secretly substitute a single-sampled RGBA32F buffer
in place of the 4x RGBA32F buffer the client program requests, we'll also
have to secretly substitute single-sampled depth and stencil buffers, as
well as single-sampled versions of all the other color buffers the client
program might have attached to the same framebuffer (because a framebuffer
can have multiple color attachments).  We can't do this substitution until
drawing is done (or the client program calls glCheckFramebufferStatus()),
because between draws, the client program might have incompatible
renderbuffers attached to the same framebuffer as a transitory condition.
 Getting the logic right for secretly swapping in single-sampled
framebuffers, at the time of the draw call, is going to be tricky.

More difficulties arise if the client program tries to re-use some, but not
all, of the renderbuffers in the same framebuffer.  Let's say that after
doing some rendering using an RGBA32F/DEPTH24_STENCIL8 combination, the
user detaches the RGBA32F renderbuffer and attaches a 4x RGBA8 renderbuffer
in its place.  Do we now magically transform the single-sampled
DEPTH24_STENCIL8 buffer (which the client thinks is multisampled) into a
truly multisampled DEPTH24_STENCIL8 buffer?  When do we do the switch?  Do
we try to preserve the contents of the depth/stencil buffer when we do the
switch?

Things get worse for Gen7, which supports these formats for 4x MSAA but not
for 8x MSAA?  Do we substitute in 4x MSAA in the place of 8x MSAA?  If so,
then what happens if the client program tries to blit from a 4x depth
buffer (which they think is 8x) to a depth buffer that truly is 8x?  The
client program would expect that to work, but we can't do it, because the
true sample counts don't match.

These kinds of questions make me really scared of this alternative.  None
of these kinds of questions arose during the period after releasing GL 3.0
when we were deliberately lying to the app, because we were lying uniformly
for all renderbuffers.  Also we were deliberately lying as a stopgap
solution, so that apps that required GL 3.0 but didn't require MSAA would
be able to run while we were finishing the MSAA implementation.
 Deliberately lying as a permanent solution to a hardware limitation seems
harder to justify.

Finally, I'm not entirely convinced that my proposed solution goes agai