[Mesa-dev] [PATCH] intel: fix potential segfault error at intel_(un)map_texture_image
intel_image->mt might be NULL, say with border width set. It then would
trigger a segfault at intel_map/unmap_texture_image function.
This would fix the oglc misctest(basic.textureBorderIgnore) fail.
Signed-off-by: Yuanhan Liu
---
src/mesa/drivers/dri/intel/intel_tex.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex.c
b/src/mesa/drivers/dri/intel/intel_tex.c
index f979523..cf3aa54 100644
--- a/src/mesa/drivers/dri/intel/intel_tex.c
+++ b/src/mesa/drivers/dri/intel/intel_tex.c
@@ -106,7 +106,7 @@ intel_map_texture_image(struct gl_context *ctx,
* row of blocks. intel_miptree_get_image_offset() already does
* the divide.
*/
- _mesa_get_format_block_size(mt->format, &bw, &bh);
+ _mesa_get_format_block_size(tex_image->TexFormat, &bw, &bh);
assert(y % bh == 0);
y /= bh;
@@ -143,7 +143,8 @@ intel_unmap_texture_image(struct gl_context *ctx,
struct intel_context *intel = intel_context(ctx);
struct intel_texture_image *intel_image = intel_texture_image(tex_image);
- intel_region_unmap(intel, intel_image->mt->region);
+ if (intel_image->mt && intel_image->mt->region)
+ intel_region_unmap(intel, intel_image->mt->region);
if (intel_image->stencil_rb) {
/*
--
1.7.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: Finalize texture on render-to-texture.
On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote: > On 09/14/2011 11:16 AM, Michel Dänzer wrote: > > From: Michel Dänzer > > > > This makes sure that stObj->pt exists and is up to date. > > > > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39193 . > > > > Signed-off-by: Michel Dänzer [...] > Reviewed-by: Brian Paul Thanks, Brian. > I assume there's no piglit regressions. There are no regressions per se with quick-driver.tests, but there's a change for the fbo-incomplete-texture-03 test: Without this patch, it fails with "FBO clear didn't work". With this patch, it passes without --enable-debug or with GALLIUM_ABORT_ON_ASSERT=0, but there are some assertion failures: state_tracker/st_texture.c:369:st_texture_image_copy: Assertion `u_minify(src->width0, srcLevel) == width' failed. state_tracker/st_texture.c:370:st_texture_image_copy: Assertion `u_minify(src->height0, srcLevel) == height' failed. Not sure if this is a new problem introduced by this patch, or an old one uncovered by it, but I'm leaning towards the latter. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: move clear paths from rgba to a pointer to a color union
On Thu, Sep 15, 2011 at 02:35:49PM +0100, Dave Airlie wrote:
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 722db8d..f36994a 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -215,7 +215,7 @@ void st_init_limits(struct st_context *st)
>c->MinProgramTexelOffset = screen->get_param(screen,
> PIPE_CAP_MIN_TEXEL_OFFSET);
>c->MaxProgramTexelOffset = screen->get_param(screen,
> PIPE_CAP_MAX_TEXEL_OFFSET);
>
> - c->GLSLVersion = 120;
> + c->GLSLVersion = 130;
>c->UniformBooleanTrue = ~0;
> }
> }
> @@ -678,4 +678,6 @@ void st_init_extensions(struct st_context *st)
> PIPE_BIND_SAMPLER_VIEW)) {
>ctx->Extensions.ARB_depth_buffer_float = GL_TRUE;
> }
> + ctx->Extensions.EXT_texture_integer = GL_TRUE;
> + ctx->Extensions.EXT_gpu_shader4 = GL_TRUE;
> }
> --
really?
;)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: handle errors in _mesa_unpack_image instead in unpack_image
On 09/14/2011 11:34 PM, Yuanhan Liu wrote:
Handle errors in _mesa_unpack_image instead in unpack_image. This
would make the error message more detailed and specified.
This patch does:
1. trigger a GL_INVALID_VALUE if (width< 0 || height< 0 || depth< 0)
It's incorrect to generate an error like that during display list
construction. The error should be raised when the command/list is
actually executed.
2. do not trigger an error if (width == 0 || height == 0 || depth == 0)
the old code would trigger a GL_OUT_OF_MEMORY error if user called
glDrawPixels function with width == 0 and height == 0. This is wrong
and will misguide user.
Yes, that needs to be fixed.
3. trigger a GL_INVALID_ENUM error if bad format or type is met.
But not at list compilation time.
4. do trigger a GL_OUT_OF_MEMORY error just when malloc failed.
Signed-off-by: Yuanhan Liu
---
src/mesa/main/dlist.c |9 +
src/mesa/main/pack.c | 27 ++-
2 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 6e075b4..21840e6 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -881,12 +881,8 @@ unpack_image(struct gl_context *ctx, GLuint dimensions,
{
if (!_mesa_is_bufferobj(unpack->BufferObj)) {
/* no PBO */
- GLvoid *image = _mesa_unpack_image(dimensions, width, height, depth,
+ return _mesa_unpack_image(dimensions, width, height, depth,
format, type, pixels, unpack);
- if (pixels&& !image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "display list construction");
- }
- return image;
}
else if (_mesa_validate_pbo_access(dimensions, unpack, width, height,
depth, format, type, INT_MAX, pixels)) {
@@ -908,9 +904,6 @@ unpack_image(struct gl_context *ctx, GLuint dimensions,
ctx->Driver.UnmapBuffer(ctx, unpack->BufferObj);
- if (!image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "display list construction");
- }
return image;
}
/* bad access! */
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index fd3f89d..ba5917d 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -5102,12 +5102,15 @@ _mesa_unpack_image( GLuint dimensions,
{
GLint bytesPerRow, compsPerRow;
GLboolean flipBytes, swap2, swap4;
+ GET_CURRENT_CONTEXT(ctx);
- if (!pixels)
- return NULL; /* not necessarily an error */
-
- if (width<= 0 || height<= 0 || depth<= 0)
- return NULL; /* generate error later */
+ if (width< 0 || height< 0 || depth< 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, __func__);
+ return NULL;
+ } else if (!pixels || width == 0 || height == 0 || depth == 0) {
+ /* not necessarily an error */
+ return NULL;
+ }
if (type == GL_BITMAP) {
bytesPerRow = (width + 7)>> 3;
@@ -5123,8 +5126,12 @@ _mesa_unpack_image( GLuint dimensions,
if (_mesa_type_is_packed(type))
components = 1;
- if (bytesPerPixel<= 0 || components<= 0)
- return NULL; /* bad format or type. generate error later */
+ if (bytesPerPixel<= 0 || components<= 0) {
+ /* bad format or type. generate error later */
+ _mesa_error(ctx, GL_INVALID_ENUM, __func__);
This call and the one below are incorrect. __func__ will evaluate to
"_mesa_unpack_image" but that's not what we want to report to the user.
+ return NULL;
+ }
+
bytesPerRow = bytesPerPixel * width;
bytesPerComp = bytesPerPixel / components;
flipBytes = GL_FALSE;
@@ -5139,8 +5146,10 @@ _mesa_unpack_image( GLuint dimensions,
= (GLubyte *) malloc(bytesPerRow * height * depth);
GLubyte *dst;
GLint img, row;
- if (!destBuffer)
- return NULL; /* generate GL_OUT_OF_MEMORY later */
+ if (!destBuffer) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, __func__);
+ return NULL;
+ }
dst = destBuffer;
for (img = 0; img< depth; img++) {
The attached patch fixes the issues you've raised but defers error
generation from compile-time to execute-time. OK?
-Brian
dlist.c.patch
Description: application/pgp-keys
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: move clear paths from rgba to a pointer to a color union
On Thu, Sep 15, 2011 at 3:17 PM, Jose Fonseca wrote: > The interpretation of pipe_color_union depends on state which is not readily > available (IIUC, it depends on the pipe format of the respective color > rendertarget). I think this is recipe for a lot of bugs. Apart from u_blitter you should have the surface passes in the clear. clear color should be opaque data until someone has to interpret it. I'm going to fix u_blitter when I had integer clear support to it. > c) simply use double[4] for colors (and when int64 comes along, just use long > double double). Maybe, though it seems like overkill. As I said it should be opaque until someone decides to interpret it and when they decide to interpret it they should have the format for the surface it corresponds to. You can't use integer clear values on non-integer surfaces. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: handle errors in _mesa_unpack_image instead in unpack_image
On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote:
> On 09/14/2011 11:34 PM, Yuanhan Liu wrote:
>>
>> Handle errors in _mesa_unpack_image instead in unpack_image. This
>> would make the error message more detailed and specified.
>>
>> This patch does:
>> 1. trigger a GL_INVALID_VALUE if (width< 0 || height< 0 || depth< 0)
>
> It's incorrect to generate an error like that during display list
> construction. The error should be raised when the command/list is actually
> executed.
Got it. Thanks.
>
>>
>> 2. do not trigger an error if (width == 0 || height == 0 || depth == 0)
>>
>> the old code would trigger a GL_OUT_OF_MEMORY error if user called
>> glDrawPixels function with width == 0 and height == 0. This is wrong
>> and will misguide user.
>
> Yes, that needs to be fixed.
>
>>
>> 3. trigger a GL_INVALID_ENUM error if bad format or type is met.
>
> But not at list compilation time.
>
>
>> 4. do trigger a GL_OUT_OF_MEMORY error just when malloc failed.
>>
>> Signed-off-by: Yuanhan Liu
>> ---
>> src/mesa/main/dlist.c | 9 +
>> src/mesa/main/pack.c | 27 ++-
>> 2 files changed, 19 insertions(+), 17 deletions(-)
>>
>> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
>> index 6e075b4..21840e6 100644
>> --- a/src/mesa/main/dlist.c
>> +++ b/src/mesa/main/dlist.c
>> @@ -881,12 +881,8 @@ unpack_image(struct gl_context *ctx, GLuint
>> dimensions,
>> {
>> if (!_mesa_is_bufferobj(unpack->BufferObj)) {
>> /* no PBO */
>> - GLvoid *image = _mesa_unpack_image(dimensions, width, height,
>> depth,
>> + return _mesa_unpack_image(dimensions, width, height, depth,
>> format, type, pixels, unpack);
>> - if (pixels&& !image) {
>> - _mesa_error(ctx, GL_OUT_OF_MEMORY, "display list construction");
>> - }
>> - return image;
>> }
>> else if (_mesa_validate_pbo_access(dimensions, unpack, width, height,
>> depth, format, type, INT_MAX,
>> pixels)) {
>> @@ -908,9 +904,6 @@ unpack_image(struct gl_context *ctx, GLuint
>> dimensions,
>>
>> ctx->Driver.UnmapBuffer(ctx, unpack->BufferObj);
>>
>> - if (!image) {
>> - _mesa_error(ctx, GL_OUT_OF_MEMORY, "display list construction");
>> - }
>> return image;
>> }
>> /* bad access! */
>> diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
>> index fd3f89d..ba5917d 100644
>> --- a/src/mesa/main/pack.c
>> +++ b/src/mesa/main/pack.c
>> @@ -5102,12 +5102,15 @@ _mesa_unpack_image( GLuint dimensions,
>> {
>> GLint bytesPerRow, compsPerRow;
>> GLboolean flipBytes, swap2, swap4;
>> + GET_CURRENT_CONTEXT(ctx);
>>
>> - if (!pixels)
>> - return NULL; /* not necessarily an error */
>> -
>> - if (width<= 0 || height<= 0 || depth<= 0)
>> - return NULL; /* generate error later */
>> + if (width< 0 || height< 0 || depth< 0) {
>> + _mesa_error(ctx, GL_INVALID_VALUE, __func__);
>> + return NULL;
>> + } else if (!pixels || width == 0 || height == 0 || depth == 0) {
>> + /* not necessarily an error */
>> + return NULL;
>> + }
>>
>> if (type == GL_BITMAP) {
>> bytesPerRow = (width + 7)>> 3;
>> @@ -5123,8 +5126,12 @@ _mesa_unpack_image( GLuint dimensions,
>> if (_mesa_type_is_packed(type))
>> components = 1;
>>
>> - if (bytesPerPixel<= 0 || components<= 0)
>> - return NULL; /* bad format or type. generate error later */
>> + if (bytesPerPixel<= 0 || components<= 0) {
>> + /* bad format or type. generate error later */
>> + _mesa_error(ctx, GL_INVALID_ENUM, __func__);
>
> This call and the one below are incorrect. __func__ will evaluate to
> "_mesa_unpack_image" but that's not what we want to report to the user.
Yeah, I was trying to figure out a good error message then, but didn't find one.
>
>
>> + return NULL;
>> + }
>> +
>> bytesPerRow = bytesPerPixel * width;
>> bytesPerComp = bytesPerPixel / components;
>> flipBytes = GL_FALSE;
>> @@ -5139,8 +5146,10 @@ _mesa_unpack_image( GLuint dimensions,
>> = (GLubyte *) malloc(bytesPerRow * height * depth);
>> GLubyte *dst;
>> GLint img, row;
>> - if (!destBuffer)
>> - return NULL; /* generate GL_OUT_OF_MEMORY later */
>> + if (!destBuffer) {
>> + _mesa_error(ctx, GL_OUT_OF_MEMORY, __func__);
>> + return NULL;
>> + }
>>
>> dst = destBuffer;
>> for (img = 0; img< depth; img++) {
>
>
> The attached patch fixes the issues you've raised but defers error
> generation from compile-time to execute-time. OK?
It's OK to me. But it seems that you are not just defer the error, but
dismiss it, right?
BTW, what should I do with the issue. Resend the patch you attached,
or you just push it to git repo?
Thanks,
Yuanhan Liu
___
mesa-dev mailing list
mesa-de
Re: [Mesa-dev] [PATCH] gallium: move clear paths from rgba to a pointer to a color union
On Thu, Sep 15, 2011 at 3:14 PM, Marcin Slusarz
wrote:
> On Thu, Sep 15, 2011 at 02:35:49PM +0100, Dave Airlie wrote:
>> diff --git a/src/mesa/state_tracker/st_extensions.c
>> b/src/mesa/state_tracker/st_extensions.c
>> index 722db8d..f36994a 100644
>> --- a/src/mesa/state_tracker/st_extensions.c
>> +++ b/src/mesa/state_tracker/st_extensions.c
>> @@ -215,7 +215,7 @@ void st_init_limits(struct st_context *st)
>> c->MinProgramTexelOffset = screen->get_param(screen,
>> PIPE_CAP_MIN_TEXEL_OFFSET);
>> c->MaxProgramTexelOffset = screen->get_param(screen,
>> PIPE_CAP_MAX_TEXEL_OFFSET);
>>
>> - c->GLSLVersion = 120;
>> + c->GLSLVersion = 130;
>> c->UniformBooleanTrue = ~0;
>> }
>> }
>> @@ -678,4 +678,6 @@ void st_init_extensions(struct st_context *st)
>> PIPE_BIND_SAMPLER_VIEW)) {
>> ctx->Extensions.ARB_depth_buffer_float = GL_TRUE;
>> }
>> + ctx->Extensions.EXT_texture_integer = GL_TRUE;
>> + ctx->Extensions.EXT_gpu_shader4 = GL_TRUE;
>> }
>> --
>
> really?
oops. git commit . fail
Dave.
> ;)
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: handle errors in _mesa_unpack_image instead in unpack_image
On Thu, Sep 15, 2011 at 10:44 PM, Liu Aleaxander wrote: > On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote: [snip] ... >> >> The attached patch fixes the issues you've raised but defers error >> generation from compile-time to execute-time. OK? > > It's OK to me. oops, I didn't look it carefully then. In fact, your patch still didn't handle the (width == 0 || height == 0) case. Thanks, Yuanhan Liu ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: Finalize texture on render-to-texture.
On 09/15/2011 04:55 AM, Michel Dänzer wrote: On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote: On 09/14/2011 11:16 AM, Michel Dänzer wrote: From: Michel Dänzer This makes sure that stObj->pt exists and is up to date. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39193 . Signed-off-by: Michel Dänzer [...] Reviewed-by: Brian Paul Thanks, Brian. I assume there's no piglit regressions. There are no regressions per se with quick-driver.tests, but there's a change for the fbo-incomplete-texture-03 test: Without this patch, it fails with "FBO clear didn't work". With this patch, it passes without --enable-debug or with GALLIUM_ABORT_ON_ASSERT=0, but there are some assertion failures: state_tracker/st_texture.c:369:st_texture_image_copy: Assertion `u_minify(src->width0, srcLevel) == width' failed. state_tracker/st_texture.c:370:st_texture_image_copy: Assertion `u_minify(src->height0, srcLevel) == height' failed. Not sure if this is a new problem introduced by this patch, or an old one uncovered by it, but I'm leaning towards the latter. Yeah, I'm looking into it. I have a patch that fixes the assertion but it needs testing... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: handle errors in _mesa_unpack_image instead in unpack_image
On 09/15/2011 08:44 AM, Liu Aleaxander wrote:
On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote:
On 09/14/2011 11:34 PM, Yuanhan Liu wrote:
Handle errors in _mesa_unpack_image instead in unpack_image. This
would make the error message more detailed and specified.
This patch does:
1. trigger a GL_INVALID_VALUE if (width<0 || height<0 || depth<0)
It's incorrect to generate an error like that during display list
construction. The error should be raised when the command/list is actually
executed.
Got it. Thanks.
2. do not trigger an error if (width == 0 || height == 0 || depth == 0)
the old code would trigger a GL_OUT_OF_MEMORY error if user called
glDrawPixels function with width == 0 and height == 0. This is wrong
and will misguide user.
Yes, that needs to be fixed.
3. trigger a GL_INVALID_ENUM error if bad format or type is met.
But not at list compilation time.
4. do trigger a GL_OUT_OF_MEMORY error just when malloc failed.
Signed-off-by: Yuanhan Liu
---
src/mesa/main/dlist.c |9 +
src/mesa/main/pack.c | 27 ++-
2 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 6e075b4..21840e6 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -881,12 +881,8 @@ unpack_image(struct gl_context *ctx, GLuint
dimensions,
{
if (!_mesa_is_bufferobj(unpack->BufferObj)) {
/* no PBO */
- GLvoid *image = _mesa_unpack_image(dimensions, width, height,
depth,
+ return _mesa_unpack_image(dimensions, width, height, depth,
format, type, pixels, unpack);
- if (pixels&&!image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "display list construction");
- }
- return image;
}
else if (_mesa_validate_pbo_access(dimensions, unpack, width, height,
depth, format, type, INT_MAX,
pixels)) {
@@ -908,9 +904,6 @@ unpack_image(struct gl_context *ctx, GLuint
dimensions,
ctx->Driver.UnmapBuffer(ctx, unpack->BufferObj);
- if (!image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "display list construction");
- }
return image;
}
/* bad access! */
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index fd3f89d..ba5917d 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -5102,12 +5102,15 @@ _mesa_unpack_image( GLuint dimensions,
{
GLint bytesPerRow, compsPerRow;
GLboolean flipBytes, swap2, swap4;
+ GET_CURRENT_CONTEXT(ctx);
- if (!pixels)
- return NULL; /* not necessarily an error */
-
- if (width<= 0 || height<= 0 || depth<= 0)
- return NULL; /* generate error later */
+ if (width<0 || height<0 || depth<0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, __func__);
+ return NULL;
+ } else if (!pixels || width == 0 || height == 0 || depth == 0) {
+ /* not necessarily an error */
+ return NULL;
+ }
if (type == GL_BITMAP) {
bytesPerRow = (width + 7)>>3;
@@ -5123,8 +5126,12 @@ _mesa_unpack_image( GLuint dimensions,
if (_mesa_type_is_packed(type))
components = 1;
- if (bytesPerPixel<= 0 || components<= 0)
- return NULL; /* bad format or type. generate error later */
+ if (bytesPerPixel<= 0 || components<= 0) {
+ /* bad format or type. generate error later */
+ _mesa_error(ctx, GL_INVALID_ENUM, __func__);
This call and the one below are incorrect. __func__ will evaluate to
"_mesa_unpack_image" but that's not what we want to report to the user.
Yeah, I was trying to figure out a good error message then, but didn't find one.
+ return NULL;
+ }
+
bytesPerRow = bytesPerPixel * width;
bytesPerComp = bytesPerPixel / components;
flipBytes = GL_FALSE;
@@ -5139,8 +5146,10 @@ _mesa_unpack_image( GLuint dimensions,
= (GLubyte *) malloc(bytesPerRow * height * depth);
GLubyte *dst;
GLint img, row;
- if (!destBuffer)
- return NULL; /* generate GL_OUT_OF_MEMORY later */
+ if (!destBuffer) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, __func__);
+ return NULL;
+ }
dst = destBuffer;
for (img = 0; img
Re: [Mesa-dev] [PATCH] mesa: handle errors in _mesa_unpack_image instead in unpack_image
On Thu, Sep 15, 2011 at 11:04 PM, Brian Paul wrote:
> On 09/15/2011 08:44 AM, Liu Aleaxander wrote:
>>
>> On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote:
>>>
>>> On 09/14/2011 11:34 PM, Yuanhan Liu wrote:
Handle errors in _mesa_unpack_image instead in unpack_image. This
would make the error message more detailed and specified.
This patch does:
1. trigger a GL_INVALID_VALUE if (width< 0 || height< 0 || depth<
0)
>>>
>>> It's incorrect to generate an error like that during display list
>>> construction. The error should be raised when the command/list is
>>> actually
>>> executed.
>>
>> Got it. Thanks.
>>
>>>
2. do not trigger an error if (width == 0 || height == 0 || depth == 0)
the old code would trigger a GL_OUT_OF_MEMORY error if user called
glDrawPixels function with width == 0 and height == 0. This is wrong
and will misguide user.
>>>
>>> Yes, that needs to be fixed.
>>>
3. trigger a GL_INVALID_ENUM error if bad format or type is met.
>>>
>>> But not at list compilation time.
>>>
>>>
4. do trigger a GL_OUT_OF_MEMORY error just when malloc failed.
Signed-off-by: Yuanhan Liu
---
src/mesa/main/dlist.c | 9 +
src/mesa/main/pack.c | 27 ++-
2 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 6e075b4..21840e6 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -881,12 +881,8 @@ unpack_image(struct gl_context *ctx, GLuint
dimensions,
{
if (!_mesa_is_bufferobj(unpack->BufferObj)) {
/* no PBO */
- GLvoid *image = _mesa_unpack_image(dimensions, width, height,
depth,
+ return _mesa_unpack_image(dimensions, width, height, depth,
format, type, pixels, unpack);
- if (pixels&& !image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "display list
construction");
- }
- return image;
}
else if (_mesa_validate_pbo_access(dimensions, unpack, width,
height,
depth, format, type, INT_MAX,
pixels)) {
@@ -908,9 +904,6 @@ unpack_image(struct gl_context *ctx, GLuint
dimensions,
ctx->Driver.UnmapBuffer(ctx, unpack->BufferObj);
- if (!image) {
- _mesa_error(ctx, GL_OUT_OF_MEMORY, "display list
construction");
- }
return image;
}
/* bad access! */
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index fd3f89d..ba5917d 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
@@ -5102,12 +5102,15 @@ _mesa_unpack_image( GLuint dimensions,
{
GLint bytesPerRow, compsPerRow;
GLboolean flipBytes, swap2, swap4;
+ GET_CURRENT_CONTEXT(ctx);
- if (!pixels)
- return NULL; /* not necessarily an error */
-
- if (width<= 0 || height<= 0 || depth<= 0)
- return NULL; /* generate error later */
+ if (width< 0 || height< 0 || depth< 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE, __func__);
+ return NULL;
+ } else if (!pixels || width == 0 || height == 0 || depth == 0) {
+ /* not necessarily an error */
+ return NULL;
+ }
if (type == GL_BITMAP) {
bytesPerRow = (width + 7)>> 3;
@@ -5123,8 +5126,12 @@ _mesa_unpack_image( GLuint dimensions,
if (_mesa_type_is_packed(type))
components = 1;
- if (bytesPerPixel<= 0 || components<= 0)
- return NULL; /* bad format or type. generate error later */
+ if (bytesPerPixel<= 0 || components<= 0) {
+ /* bad format or type. generate error later */
+ _mesa_error(ctx, GL_INVALID_ENUM, __func__);
>>>
>>> This call and the one below are incorrect. __func__ will evaluate to
>>> "_mesa_unpack_image" but that's not what we want to report to the user.
>>
>> Yeah, I was trying to figure out a good error message then, but didn't
>> find one.
>>
>>>
>>>
+ return NULL;
+ }
+
bytesPerRow = bytesPerPixel * width;
bytesPerComp = bytesPerPixel / components;
flipBytes = GL_FALSE;
@@ -5139,8 +5146,10 @@ _mesa_unpack_image( GLuint dimensions,
= (GLubyte *) malloc(bytesPerRow * height * depth);
GLubyte *dst;
GLint img, row;
- if (!destBuffer)
- return NULL; /* generate GL_OUT_OF_MEMORY later */
+ if (!destBuffer) {
+ _mesa_error(ctx, GL_OUT_OF_MEMORY, __func__);
+ return NULL;
+ }
dst = destBuffer;
for (img = 0; img< depth; img++)
[Mesa-dev] [PATCH] mesa: fix error handling for dlist image unpacking
From: Brian Paul
When compiling glDrawPixels, glTexImage(), etc. and we're copying
the user's image we need to be careful about GL error checking.
Previously, we were incorrectly generating GL_OUT_OF_MEMORY in
unpack_image() if width < 0 or height < 0 or for invalid format/type
values. We now check those arguments in unpack_image() and return NULL
if there's a bad value. The command will get compiled with the
arguments as-is and image=NULL. Later, when the command is executed the
correct errors will ge generated.
This issue was reported by Yuanhan Liu
---
src/mesa/main/dlist.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 6e075b4..3978eb6 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -871,7 +871,11 @@ translate_id(GLsizei n, GLenum type, const GLvoid * list)
/**
* Wrapper for _mesa_unpack_image() that handles pixel buffer objects.
- * If we run out of memory, GL_OUT_OF_MEMORY will be recorded.
+ * If width < 0 or height < 0 or format or type are invalid we'll just
+ * return NULL. We will not generate an error since OpenGL command
+ * arguments aren't error-checked until the command is actually executed
+ * (not when they're compiled).
+ * But if we run out of memory, GL_OUT_OF_MEMORY will be recorded.
*/
static GLvoid *
unpack_image(struct gl_context *ctx, GLuint dimensions,
@@ -879,6 +883,15 @@ unpack_image(struct gl_context *ctx, GLuint dimensions,
GLenum format, GLenum type, const GLvoid * pixels,
const struct gl_pixelstore_attrib *unpack)
{
+ if (width < 0 || height < 0) {
+ return NULL;
+ }
+
+ if (_mesa_bytes_per_pixel(format, type) <= 0) {
+ /* bad format and/or type */
+ return NULL;
+ }
+
if (!_mesa_is_bufferobj(unpack->BufferObj)) {
/* no PBO */
GLvoid *image = _mesa_unpack_image(dimensions, width, height, depth,
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: handle errors in _mesa_unpack_image instead in unpack_image
On 09/15/2011 09:00 AM, Liu Aleaxander wrote: On Thu, Sep 15, 2011 at 10:44 PM, Liu Aleaxander wrote: On Thu, Sep 15, 2011 at 10:17 PM, Brian Paul wrote: [snip] ... The attached patch fixes the issues you've raised but defers error generation from compile-time to execute-time. OK? It's OK to me. oops, I didn't look it carefully then. In fact, your patch still didn't handle the (width == 0 || height == 0) case. D'oh. I'll post another patch... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: fix error handling for dlist image unpacking
From: Brian Paul
When compiling glDrawPixels, glTexImage(), etc. and we're copying
the user's image we need to be careful about GL error checking.
Previously, we were incorrectly generating GL_OUT_OF_MEMORY in
unpack_image() if width < 0 or height < 0 or for invalid format/type
values. We now check those arguments in unpack_image() and return NULL
if there's a bad value. The command will get compiled with the
arguments as-is and image=NULL. Later, when the command is executed the
correct errors will ge generated.
v2: also check for width or height == 0.
This issue was reported by Yuanhan Liu
---
src/mesa/main/dlist.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 6e075b4..2b2ff90 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -871,7 +871,11 @@ translate_id(GLsizei n, GLenum type, const GLvoid * list)
/**
* Wrapper for _mesa_unpack_image() that handles pixel buffer objects.
- * If we run out of memory, GL_OUT_OF_MEMORY will be recorded.
+ * If width < 0 or height < 0 or format or type are invalid we'll just
+ * return NULL. We will not generate an error since OpenGL command
+ * arguments aren't error-checked until the command is actually executed
+ * (not when they're compiled).
+ * But if we run out of memory, GL_OUT_OF_MEMORY will be recorded.
*/
static GLvoid *
unpack_image(struct gl_context *ctx, GLuint dimensions,
@@ -879,6 +883,15 @@ unpack_image(struct gl_context *ctx, GLuint dimensions,
GLenum format, GLenum type, const GLvoid * pixels,
const struct gl_pixelstore_attrib *unpack)
{
+ if (width <= 0 || height <= 0) {
+ return NULL;
+ }
+
+ if (_mesa_bytes_per_pixel(format, type) <= 0) {
+ /* bad format and/or type */
+ return NULL;
+ }
+
if (!_mesa_is_bufferobj(unpack->BufferObj)) {
/* no PBO */
GLvoid *image = _mesa_unpack_image(dimensions, width, height, depth,
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix error handling for dlist image unpacking
On Thu, Sep 15, 2011 at 11:17 PM, Brian Paul wrote:
> From: Brian Paul
>
> When compiling glDrawPixels, glTexImage(), etc. and we're copying
> the user's image we need to be careful about GL error checking.
> Previously, we were incorrectly generating GL_OUT_OF_MEMORY in
> unpack_image() if width < 0 or height < 0 or for invalid format/type
> values. We now check those arguments in unpack_image() and return NULL
> if there's a bad value. The command will get compiled with the
> arguments as-is and image=NULL. Later, when the command is executed the
> correct errors will ge generated.
>
> v2: also check for width or height == 0.
>
> This issue was reported by Yuanhan Liu
Reviewed-by: Yuanhan Liu
> ---
> src/mesa/main/dlist.c | 15 ++-
> 1 files changed, 14 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
> index 6e075b4..2b2ff90 100644
> --- a/src/mesa/main/dlist.c
> +++ b/src/mesa/main/dlist.c
> @@ -871,7 +871,11 @@ translate_id(GLsizei n, GLenum type, const GLvoid * list)
>
> /**
> * Wrapper for _mesa_unpack_image() that handles pixel buffer objects.
> - * If we run out of memory, GL_OUT_OF_MEMORY will be recorded.
> + * If width < 0 or height < 0 or format or type are invalid we'll just
> + * return NULL. We will not generate an error since OpenGL command
> + * arguments aren't error-checked until the command is actually executed
> + * (not when they're compiled).
> + * But if we run out of memory, GL_OUT_OF_MEMORY will be recorded.
> */
> static GLvoid *
> unpack_image(struct gl_context *ctx, GLuint dimensions,
> @@ -879,6 +883,15 @@ unpack_image(struct gl_context *ctx, GLuint dimensions,
> GLenum format, GLenum type, const GLvoid * pixels,
> const struct gl_pixelstore_attrib *unpack)
> {
> + if (width <= 0 || height <= 0) {
> + return NULL;
> + }
> +
> + if (_mesa_bytes_per_pixel(format, type) <= 0) {
> + /* bad format and/or type */
> + return NULL;
> + }
> +
> if (!_mesa_is_bufferobj(unpack->BufferObj)) {
> /* no PBO */
> GLvoid *image = _mesa_unpack_image(dimensions, width, height, depth,
> --
> 1.7.3.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
regards
Liu Aleaxander
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] util: add util_format_is_luminance/intensity/rgb(), etc
From: Brian Paul
---
src/gallium/auxiliary/util/u_format.c | 94 +
src/gallium/auxiliary/util/u_format.h | 16 ++
2 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_format.c
b/src/gallium/auxiliary/util/u_format.c
index 34922ab..a31634c 100644
--- a/src/gallium/auxiliary/util/u_format.c
+++ b/src/gallium/auxiliary/util/u_format.c
@@ -67,6 +67,100 @@ util_format_is_float(enum pipe_format format)
}
+/**
+ * Return the number of logical channels in the given format by
+ * examining swizzles.
+ * XXX this could be made into a public function if useful elsewhere.
+ */
+static unsigned
+nr_logical_channels(const struct util_format_description *desc)
+{
+ boolean swizzle_used[UTIL_FORMAT_SWIZZLE_NONE + 1];
+
+ memset(swizzle_used, 0, sizeof(swizzle_used));
+
+ swizzle_used[desc->swizzle[0]] = TRUE;
+ swizzle_used[desc->swizzle[1]] = TRUE;
+ swizzle_used[desc->swizzle[2]] = TRUE;
+ swizzle_used[desc->swizzle[3]] = TRUE;
+
+ return (swizzle_used[UTIL_FORMAT_SWIZZLE_X] +
+ swizzle_used[UTIL_FORMAT_SWIZZLE_Y] +
+ swizzle_used[UTIL_FORMAT_SWIZZLE_Z] +
+ swizzle_used[UTIL_FORMAT_SWIZZLE_W]);
+}
+
+
+/** Test if the format contains RGB, but not alpha */
+boolean
+util_format_is_rgb_no_alpha(enum pipe_format format)
+{
+ const struct util_format_description *desc =
+ util_format_description(format);
+
+ if ((desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB ||
+desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) &&
+ nr_logical_channels(desc) == 3) {
+ return TRUE;
+ }
+ return FALSE;
+}
+
+
+boolean
+util_format_is_luminance(enum pipe_format format)
+{
+ const struct util_format_description *desc =
+ util_format_description(format);
+
+ if ((desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB ||
+desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) &&
+ desc->swizzle[0] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[1] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[2] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[3] == UTIL_FORMAT_SWIZZLE_1) {
+ return TRUE;
+ }
+ return FALSE;
+}
+
+
+boolean
+util_format_is_luminance_alpha(enum pipe_format format)
+{
+ const struct util_format_description *desc =
+ util_format_description(format);
+
+ if ((desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB ||
+desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) &&
+ desc->swizzle[0] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[1] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[2] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[3] == UTIL_FORMAT_SWIZZLE_Y) {
+ return TRUE;
+ }
+ return FALSE;
+}
+
+
+boolean
+util_format_is_intensity(enum pipe_format format)
+{
+ const struct util_format_description *desc =
+ util_format_description(format);
+
+ if ((desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB ||
+desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) &&
+ desc->swizzle[0] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[1] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[2] == UTIL_FORMAT_SWIZZLE_X &&
+ desc->swizzle[3] == UTIL_FORMAT_SWIZZLE_X) {
+ return TRUE;
+ }
+ return FALSE;
+}
+
+
boolean
util_format_is_supported(enum pipe_format format, unsigned bind)
{
diff --git a/src/gallium/auxiliary/util/u_format.h
b/src/gallium/auxiliary/util/u_format.h
index 3527103..991dbc3 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -477,6 +477,22 @@ boolean
util_format_is_float(enum pipe_format format);
+boolean
+util_format_is_rgb_no_alpha(enum pipe_format format);
+
+
+boolean
+util_format_is_luminance(enum pipe_format format);
+
+
+boolean
+util_format_is_luminance_alpha(enum pipe_format format);
+
+
+boolean
+util_format_is_intensity(enum pipe_format format);
+
+
/**
* Whether the src format can be blitted to destation format with a simple
* memcpy.
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] softpipe: fix blending for luminance/intensity surfaces
From: Brian Paul
If we're drawing to a luminance, luminance/alpha or intensity surface
we have to adjust (rebase) the fragment/quad colors before writing them
to the tile cache. The tile cache always stores RGBA colors but if
we're caching a L/A surface (for example) we need to be sure that R=G=B
so that subsequent reads from the surface cache appear to return L/A
We previously had a special case for RGB (no alpha) surfaces. This
change generalizes that for the other base formats.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40408, but sRGB
formats are still failing. That'll be addressed in a later patch.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 161 +++---
1 files changed, 96 insertions(+), 65 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_quad_blend.c
b/src/gallium/drivers/softpipe/sp_quad_blend.c
index 65f17d2..c1a9b6f 100644
--- a/src/gallium/drivers/softpipe/sp_quad_blend.c
+++ b/src/gallium/drivers/softpipe/sp_quad_blend.c
@@ -41,12 +41,22 @@
#include "sp_quad_pipe.h"
+enum format
+{
+ RGBA,
+ RGB,
+ LUMINANCE,
+ LUMINANCE_ALPHA,
+ INTENSITY
+};
+
+
/** Subclass of quad_stage */
struct blend_quad_stage
{
struct quad_stage base;
- boolean has_dst_alpha[PIPE_MAX_COLOR_BUFS];
boolean clamp[PIPE_MAX_COLOR_BUFS]; /**< clamp colors to [0,1]? */
+ enum format base_format[PIPE_MAX_COLOR_BUFS];
};
@@ -245,15 +255,13 @@ logicop_quad(struct quad_stage *qs,
* \param dest the destination/framebuffer quad colors
* \param const_blend_color the constant blend color
* \param blend_index which set of blending terms to use
- * \param has_dst_alpha does the dest color buffer have an alpha channel?
*/
static void
blend_quad(struct quad_stage *qs,
float (*quadColor)[4],
float (*dest)[4],
const float const_blend_color[4],
- unsigned blend_index,
- boolean has_dst_alpha)
+ unsigned blend_index)
{
static const float zero[4] = { 0, 0, 0, 0 };
static const float one[4] = { 1, 1, 1, 1 };
@@ -289,20 +297,15 @@ blend_quad(struct quad_stage *qs,
VEC4_MUL(source[2], quadColor[2], dest[2]); /* B */
break;
case PIPE_BLENDFACTOR_DST_ALPHA:
- if (has_dst_alpha) {
+ {
const float *alpha = dest[3];
VEC4_MUL(source[0], quadColor[0], alpha); /* R */
VEC4_MUL(source[1], quadColor[1], alpha); /* G */
VEC4_MUL(source[2], quadColor[2], alpha); /* B */
}
- else {
- VEC4_COPY(source[0], quadColor[0]); /* R */
- VEC4_COPY(source[1], quadColor[1]); /* G */
- VEC4_COPY(source[2], quadColor[2]); /* B */
- }
break;
case PIPE_BLENDFACTOR_SRC_ALPHA_SATURATE:
- if (has_dst_alpha) {
+ {
const float *alpha = quadColor[3];
float diff[4], temp[4];
VEC4_SUB(diff, one, dest[3]);
@@ -311,11 +314,6 @@ blend_quad(struct quad_stage *qs,
VEC4_MUL(source[1], quadColor[1], temp); /* G */
VEC4_MUL(source[2], quadColor[2], temp); /* B */
}
- else {
- VEC4_COPY(source[0], zero); /* R */
- VEC4_COPY(source[1], zero); /* G */
- VEC4_COPY(source[2], zero); /* B */
- }
break;
case PIPE_BLENDFACTOR_CONST_COLOR:
{
@@ -369,18 +367,13 @@ blend_quad(struct quad_stage *qs,
}
break;
case PIPE_BLENDFACTOR_INV_DST_ALPHA:
- if (has_dst_alpha) {
+ {
float inv_alpha[4];
VEC4_SUB(inv_alpha, one, dest[3]);
VEC4_MUL(source[0], quadColor[0], inv_alpha); /* R */
VEC4_MUL(source[1], quadColor[1], inv_alpha); /* G */
VEC4_MUL(source[2], quadColor[2], inv_alpha); /* B */
}
- else {
- VEC4_COPY(source[0], zero); /* R */
- VEC4_COPY(source[1], zero); /* G */
- VEC4_COPY(source[2], zero); /* B */
- }
break;
case PIPE_BLENDFACTOR_INV_DST_COLOR:
{
@@ -444,10 +437,7 @@ blend_quad(struct quad_stage *qs,
case PIPE_BLENDFACTOR_DST_COLOR:
/* fall-through */
case PIPE_BLENDFACTOR_DST_ALPHA:
- if (has_dst_alpha)
- VEC4_MUL(source[3], quadColor[3], dest[3]); /* A */
- else
- VEC4_COPY(source[3], quadColor[3]); /* A */
+ VEC4_MUL(source[3], quadColor[3], dest[3]); /* A */
break;
case PIPE_BLENDFACTOR_SRC_ALPHA_SATURATE:
/* multiply alpha by 1.0 */
@@ -477,14 +467,11 @@ blend_quad(struct quad_stage *qs,
case PIPE_BLENDFACTOR_INV_DST_COLOR:
/* fall-through */
case PIPE_BLENDFACTOR_INV_DST_ALPHA:
- if (has_dst_alpha) {
+ {
float inv_alpha[4];
VEC4_SUB(inv_alpha, one, dest[3]);
VEC4_MUL(source[3], quadColor[3], inv_alpha); /* A */
}
- else {
- VEC4_COPY(source[3], zero); /* A */
- }
break;
case PIPE_BLENDFACTOR_INV_CONST_COLOR:
/* fall-through */
@@ -525,14 +512,9 @@ blend_quad(struct quad_stage *qs,
VEC4_
Re: [Mesa-dev] [PATCH 1/2] util: add util_format_is_luminance/intensity/rgb(), etc
Looks great to me.
Feel free to add a new UTIL_FORMAT_SWIZZLE_MAX if it helps.
Jose
- Original Message -
> From: Brian Paul
>
> ---
> src/gallium/auxiliary/util/u_format.c | 94
> +
> src/gallium/auxiliary/util/u_format.h | 16 ++
> 2 files changed, 110 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_format.c
> b/src/gallium/auxiliary/util/u_format.c
> index 34922ab..a31634c 100644
> --- a/src/gallium/auxiliary/util/u_format.c
> +++ b/src/gallium/auxiliary/util/u_format.c
> @@ -67,6 +67,100 @@ util_format_is_float(enum pipe_format format)
> }
>
>
> +/**
> + * Return the number of logical channels in the given format by
> + * examining swizzles.
> + * XXX this could be made into a public function if useful
> elsewhere.
> + */
> +static unsigned
> +nr_logical_channels(const struct util_format_description *desc)
> +{
> + boolean swizzle_used[UTIL_FORMAT_SWIZZLE_NONE + 1];
> +
> + memset(swizzle_used, 0, sizeof(swizzle_used));
> +
> + swizzle_used[desc->swizzle[0]] = TRUE;
> + swizzle_used[desc->swizzle[1]] = TRUE;
> + swizzle_used[desc->swizzle[2]] = TRUE;
> + swizzle_used[desc->swizzle[3]] = TRUE;
> +
> + return (swizzle_used[UTIL_FORMAT_SWIZZLE_X] +
> + swizzle_used[UTIL_FORMAT_SWIZZLE_Y] +
> + swizzle_used[UTIL_FORMAT_SWIZZLE_Z] +
> + swizzle_used[UTIL_FORMAT_SWIZZLE_W]);
> +}
> +
> +
> +/** Test if the format contains RGB, but not alpha */
> +boolean
> +util_format_is_rgb_no_alpha(enum pipe_format format)
> +{
> + const struct util_format_description *desc =
> + util_format_description(format);
> +
> + if ((desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB ||
> +desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) &&
> + nr_logical_channels(desc) == 3) {
> + return TRUE;
> + }
> + return FALSE;
> +}
> +
> +
> +boolean
> +util_format_is_luminance(enum pipe_format format)
> +{
> + const struct util_format_description *desc =
> + util_format_description(format);
> +
> + if ((desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB ||
> +desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) &&
> + desc->swizzle[0] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[1] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[2] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[3] == UTIL_FORMAT_SWIZZLE_1) {
> + return TRUE;
> + }
> + return FALSE;
> +}
> +
> +
> +boolean
> +util_format_is_luminance_alpha(enum pipe_format format)
> +{
> + const struct util_format_description *desc =
> + util_format_description(format);
> +
> + if ((desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB ||
> +desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) &&
> + desc->swizzle[0] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[1] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[2] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[3] == UTIL_FORMAT_SWIZZLE_Y) {
> + return TRUE;
> + }
> + return FALSE;
> +}
> +
> +
> +boolean
> +util_format_is_intensity(enum pipe_format format)
> +{
> + const struct util_format_description *desc =
> + util_format_description(format);
> +
> + if ((desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB ||
> +desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) &&
> + desc->swizzle[0] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[1] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[2] == UTIL_FORMAT_SWIZZLE_X &&
> + desc->swizzle[3] == UTIL_FORMAT_SWIZZLE_X) {
> + return TRUE;
> + }
> + return FALSE;
> +}
> +
> +
> boolean
> util_format_is_supported(enum pipe_format format, unsigned bind)
> {
> diff --git a/src/gallium/auxiliary/util/u_format.h
> b/src/gallium/auxiliary/util/u_format.h
> index 3527103..991dbc3 100644
> --- a/src/gallium/auxiliary/util/u_format.h
> +++ b/src/gallium/auxiliary/util/u_format.h
> @@ -477,6 +477,22 @@ boolean
> util_format_is_float(enum pipe_format format);
>
>
> +boolean
> +util_format_is_rgb_no_alpha(enum pipe_format format);
> +
> +
> +boolean
> +util_format_is_luminance(enum pipe_format format);
> +
> +
> +boolean
> +util_format_is_luminance_alpha(enum pipe_format format);
> +
> +
> +boolean
> +util_format_is_intensity(enum pipe_format format);
> +
> +
> /**
> * Whether the src format can be blitted to destation format with a
> simple
> * memcpy.
> --
> 1.7.3.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: Finalize texture on render-to-texture.
On Don, 2011-09-15 at 09:01 -0600, Brian Paul wrote: > On 09/15/2011 04:55 AM, Michel Dänzer wrote: > > On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote: > >> On 09/14/2011 11:16 AM, Michel Dänzer wrote: > >>> From: Michel Dänzer > >>> > >>> This makes sure that stObj->pt exists and is up to date. > >>> > >>> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39193 . > >>> > >>> Signed-off-by: Michel Dänzer > > > > [...] > > > >> Reviewed-by: Brian Paul > > > > Thanks, Brian. > > > >> I assume there's no piglit regressions. > > > > There are no regressions per se with quick-driver.tests, but there's a > > change for the fbo-incomplete-texture-03 test: Without this patch, it > > fails with "FBO clear didn't work". With this patch, it passes without > > --enable-debug or with GALLIUM_ABORT_ON_ASSERT=0, but there are some > > assertion failures: > > > > state_tracker/st_texture.c:369:st_texture_image_copy: Assertion > > `u_minify(src->width0, srcLevel) == width' failed. > > state_tracker/st_texture.c:370:st_texture_image_copy: Assertion > > `u_minify(src->height0, srcLevel) == height' failed. > > > > Not sure if this is a new problem introduced by this patch, or an old > > one uncovered by it, but I'm leaning towards the latter. > > Yeah, I'm looking into it. I have a patch that fixes the assertion > but it needs testing... I'd be happy to give that a spin, but I guess it's okay to push this fix in the meantime? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965 new VS: Fix copy propagation of double negatives.
When copy propagating a value into an instruction that negates its argument, we need to invert the sense of the value's "negate" flag, so that -(+x) becomes -x and -(-x) becomes +x. Previously, we were always setting the value's "negate" flag to true in this circumstance, so that both -(+x) and -(-x) turned into -x. Fixes Piglit test vs-double-negative.shader_test. --- .../drivers/dri/i965/brw_vec4_copy_propagation.cpp |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp index c46735a..e0b2d2a 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp @@ -196,7 +196,7 @@ try_copy_propagation(struct intel_context *intel, value.abs = true; } if (inst->src[arg].negate) - value.negate = true; + value.negate = !value.negate; /* FINISHME: We can't copy-propagate things that aren't normal * vec8s into gen6 math instructions, because of the weird src -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: move clear paths from rgba to a pointer to a color union
Am 15.09.2011 15:35, schrieb Dave Airlie:
> From: Dave Airlie
>
> This moves the gallium interface for clears from using a pointer to 4 floats
> to a pointer to a union of float/unsigned/int values. This is step one
> in allowing integer clears. I've tried to build as many drivers/pieces
> as I could, but I think I missed a couple, (vega for instance seems to
> need a bit more work).
> diff --git a/src/gallium/include/pipe/p_context.h
> b/src/gallium/include/pipe/p_context.h
> index 49c12ec..b2d5f95 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -63,7 +63,7 @@ struct pipe_vertex_element;
> struct pipe_video_buffer;
> struct pipe_video_decoder;
> struct pipe_viewport_state;
> -
> +union pipe_color_union;
>
> /**
> * Gallium rendering context. Basically:
> @@ -281,23 +281,23 @@ struct pipe_context {
> * The entire buffers are cleared (no scissor, no colormask, etc).
> *
> * \param buffers bitfield of PIPE_CLEAR_* values.
> -* \param rgba pointer to an array of one float for each of r, g, b, a.
> +* \param color pointer to a union of fiu array for each of r, g, b, a.
> * \param depth depth clear value in [0,1].
> * \param stencil stencil clear value
> */
> void (*clear)(struct pipe_context *pipe,
> unsigned buffers,
> - const float *rgba,
> + const union pipe_color_union *color,
> double depth,
> unsigned stencil);
>
> /**
> * Clear a color rendertarget surface.
> -* \param rgba pointer to an array of one float for each of r, g, b, a.
> +* \param color pointer to an union of fiu array for each of r, g, b, a.
> */
> void (*clear_render_target)(struct pipe_context *pipe,
> struct pipe_surface *dst,
> - const float *rgba,
> + const union pipe_color_union *color,
> unsigned dstx, unsigned dsty,
> unsigned width, unsigned height);
>
Hmm is it really necessary to change the clear function?
This is sort of a legacy clear, and neither OpenGL nor d3d9(*) allow you
to use anything but floats when specifying clear color.
(Yes I know mesa / mesa state tracker currently use clear and not
clear_render_target/clear_depth_stencil even for the glClearBufferxx
functions right now.)
(*) d3d9 in fact requires the color to be a d3dcolor hence packed 32bit
uint but it can be converted of course without loss to floats.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] memory leak
I am using Mesa 7.10, DRI driver for R600. I believe I see a memory leak of 1
page per frame with the code
drawme(){glClearColor(0.0, 1.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);glClearColor(0.0, 1.0,
1.0, 1.0);glClear(GL_COLOR_BUFFER_BIT);eglSwapBuffers(dpy, surface);}
If I take out the glClearColor, the leak goes away.
I am using a HD4600 series radeon graphics card.
Is this a known defect? Is it reproducible on other systems, or could I have
just screwed something up when I built the software?
Jeff Collins ___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: move clear paths from rgba to a pointer to a color union
>>
>> This moves the gallium interface for clears from using a pointer to 4 floats
>> to a pointer to a union of float/unsigned/int values. This is step one
>> in allowing integer clears. I've tried to build as many drivers/pieces
>> as I could, but I think I missed a couple, (vega for instance seems to
>> need a bit more work).
>
>> diff --git a/src/gallium/include/pipe/p_context.h
>> b/src/gallium/include/pipe/p_context.h
>> index 49c12ec..b2d5f95 100644
>> --- a/src/gallium/include/pipe/p_context.h
>> +++ b/src/gallium/include/pipe/p_context.h
>> @@ -63,7 +63,7 @@ struct pipe_vertex_element;
>> struct pipe_video_buffer;
>> struct pipe_video_decoder;
>> struct pipe_viewport_state;
>> -
>> +union pipe_color_union;
>>
>> /**
>> * Gallium rendering context. Basically:
>> @@ -281,23 +281,23 @@ struct pipe_context {
>> * The entire buffers are cleared (no scissor, no colormask, etc).
>> *
>> * \param buffers bitfield of PIPE_CLEAR_* values.
>> - * \param rgba pointer to an array of one float for each of r, g, b, a.
>> + * \param color pointer to a union of fiu array for each of r, g, b, a.
>> * \param depth depth clear value in [0,1].
>> * \param stencil stencil clear value
>> */
>> void (*clear)(struct pipe_context *pipe,
>> unsigned buffers,
>> - const float *rgba,
>> + const union pipe_color_union *color,
>> double depth,
>> unsigned stencil);
>>
>> /**
>> * Clear a color rendertarget surface.
>> - * \param rgba pointer to an array of one float for each of r, g, b, a.
>> + * \param color pointer to an union of fiu array for each of r, g, b, a.
>> */
>> void (*clear_render_target)(struct pipe_context *pipe,
>> struct pipe_surface *dst,
>> - const float *rgba,
>> + const union pipe_color_union *color,
>> unsigned dstx, unsigned dsty,
>> unsigned width, unsigned height);
>>
>
> Hmm is it really necessary to change the clear function?
> This is sort of a legacy clear, and neither OpenGL nor d3d9(*) allow you
> to use anything but floats when specifying clear color.
> (Yes I know mesa / mesa state tracker currently use clear and not
> clear_render_target/clear_depth_stencil even for the glClearBufferxx
> functions right now.)
You should know better by now than to claim GL can't do something
stupid or insane.
EXT_gpu_shader4 allows this, I even fixed all the mesa entry points last week.
glClearColorIiEXT
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] memory leak
On Don, 2011-09-15 at 13:01 -0400, Jeffrey Collins wrote:
> I am using Mesa 7.10, DRI driver for R600. I believe I see a memory
> leak of 1 page per frame with the code
>
>
> drawme()
> {
> glClearColor(0.0, 1.0, 0.0, 0.0);
> glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
> glClearColor(0.0, 1.0, 1.0, 1.0);
> glClear(GL_COLOR_BUFFER_BIT);
> eglSwapBuffers(dpy, surface);
> }
>
>
> If I take out the glClearColor, the leak goes away.
>
>
> I am using a HD4600 series radeon graphics card.
>
>
> Is this a known defect? Is it reproducible on other systems, or could
> I have just screwed something up when I built the software?
Can you check if it's still there with current Mesa Git or at least
7.11, and if so try and isolate the leak with valgrind?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: Finalize texture on render-to-texture.
On 09/15/2011 10:08 AM, Michel Dänzer wrote:
On Don, 2011-09-15 at 09:01 -0600, Brian Paul wrote:
On 09/15/2011 04:55 AM, Michel Dänzer wrote:
On Mit, 2011-09-14 at 11:44 -0600, Brian Paul wrote:
On 09/14/2011 11:16 AM, Michel Dänzer wrote:
From: Michel Dänzer
This makes sure that stObj->pt exists and is up to date.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39193 .
Signed-off-by: Michel Dänzer
[...]
Reviewed-by: Brian Paul
Thanks, Brian.
I assume there's no piglit regressions.
There are no regressions per se with quick-driver.tests, but there's a
change for the fbo-incomplete-texture-03 test: Without this patch, it
fails with "FBO clear didn't work". With this patch, it passes without
--enable-debug or with GALLIUM_ABORT_ON_ASSERT=0, but there are some
assertion failures:
state_tracker/st_texture.c:369:st_texture_image_copy: Assertion
`u_minify(src->width0, srcLevel) == width' failed.
state_tracker/st_texture.c:370:st_texture_image_copy: Assertion
`u_minify(src->height0, srcLevel) == height' failed.
Not sure if this is a new problem introduced by this patch, or an old
one uncovered by it, but I'm leaning towards the latter.
Yeah, I'm looking into it. I have a patch that fixes the assertion
but it needs testing...
I'd be happy to give that a spin, but I guess it's okay to push this fix
in the meantime?
I guess I'd like to fix up the assertion too or we'll probably get
some new bug reports.
Here's my patch that seems to fix the issue:
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index eab02fb..538a7a3 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1679,7 +1679,7 @@ copy_image_data_to_texture(struct st_context *st,
assert(dstImage->Depth == stImage->base.Depth);
}
- if (stImage->pt) {
+ if (stImage->pt && stObj->base._Complete) {
/* Copy potentially with the blitter:
*/
st_texture_image_copy(st->pipe,
I did a quick run of piglit texture tests and didn't see any
regressions but I'd like to test more.
The idea with this change is that if the texture is not complete
(mismatched image sizes) we can't draw with it anyway so skip copying
the texture data into the texture buffer.
Maybe you can run some tests with this too...
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: move clear paths from rgba to a pointer to a color union
Am 15.09.2011 19:11, schrieb Dave Airlie:
>>>
>>> This moves the gallium interface for clears from using a pointer to 4 floats
>>> to a pointer to a union of float/unsigned/int values. This is step one
>>> in allowing integer clears. I've tried to build as many drivers/pieces
>>> as I could, but I think I missed a couple, (vega for instance seems to
>>> need a bit more work).
>>
>>> diff --git a/src/gallium/include/pipe/p_context.h
>>> b/src/gallium/include/pipe/p_context.h
>>> index 49c12ec..b2d5f95 100644
>>> --- a/src/gallium/include/pipe/p_context.h
>>> +++ b/src/gallium/include/pipe/p_context.h
>>> @@ -63,7 +63,7 @@ struct pipe_vertex_element;
>>> struct pipe_video_buffer;
>>> struct pipe_video_decoder;
>>> struct pipe_viewport_state;
>>> -
>>> +union pipe_color_union;
>>>
>>> /**
>>> * Gallium rendering context. Basically:
>>> @@ -281,23 +281,23 @@ struct pipe_context {
>>> * The entire buffers are cleared (no scissor, no colormask, etc).
>>> *
>>> * \param buffers bitfield of PIPE_CLEAR_* values.
>>> -* \param rgba pointer to an array of one float for each of r, g, b, a.
>>> +* \param color pointer to a union of fiu array for each of r, g, b, a.
>>> * \param depth depth clear value in [0,1].
>>> * \param stencil stencil clear value
>>> */
>>> void (*clear)(struct pipe_context *pipe,
>>> unsigned buffers,
>>> - const float *rgba,
>>> + const union pipe_color_union *color,
>>> double depth,
>>> unsigned stencil);
>>>
>>> /**
>>> * Clear a color rendertarget surface.
>>> -* \param rgba pointer to an array of one float for each of r, g, b, a.
>>> +* \param color pointer to an union of fiu array for each of r, g, b,
>>> a.
>>> */
>>> void (*clear_render_target)(struct pipe_context *pipe,
>>> struct pipe_surface *dst,
>>> - const float *rgba,
>>> + const union pipe_color_union *color,
>>> unsigned dstx, unsigned dsty,
>>> unsigned width, unsigned height);
>>>
>>
>> Hmm is it really necessary to change the clear function?
>> This is sort of a legacy clear, and neither OpenGL nor d3d9(*) allow you
>> to use anything but floats when specifying clear color.
>> (Yes I know mesa / mesa state tracker currently use clear and not
>> clear_render_target/clear_depth_stencil even for the glClearBufferxx
>> functions right now.)
>
> You should know better by now than to claim GL can't do something
> stupid or insane.
>
> EXT_gpu_shader4 allows this, I even fixed all the mesa entry points last week.
>
> glClearColorIiEXT
Ah I see it's part of EXT_texture_integer actually. Ok I'm convinced :-).
It isn't actually really stupid or insane I guess, I just thought the
main reason for the ClearBufferxx funcs was because you couldn't clear
int buffers otherwise.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 40919] New: vgChildImage seems not to be implemented
https://bugs.freedesktop.org/show_bug.cgi?id=40919 Summary: vgChildImage seems not to be implemented Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: andreas.b...@elektrobit.com Regarding the OpenVG 1.1 spec vgChildImage should be used if you have an image and a sub image of it and you still need both... vgChildImage should use the original images data to avoid copying the part of the image ... and so on ... like vgImageSubData + vgCreateImage does. Unfortunately vgChildImage returns VG_INVALID_HANDLE each time i call it. So my question is there a chance that this is ging to be supported? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 40920] New: [openvg] defective pixels using mesa with openvg
https://bugs.freedesktop.org/show_bug.cgi?id=40920 Summary: [openvg] defective pixels using mesa with openvg Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Other AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: andreas.b...@elektrobit.com Hi, every time im using a path e.g. describing a text or a complex thing - like a stick figure :) - i see strange defective pixels. What i can tell you is that i have seen this phenomena on WindowsXP-32bit, Windows7-64bit, WindowsVista-64bit, Kubuntu and Debian. Though mesa is - in my eyes - the best OpenVG emulation for Win32 the defective pixels and the missing antializing are the only two obstacles for "us"... Thank you, Andy -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] softpipe: fix blending for luminance/intensity surfaces
On Thu, Sep 15, 2011 at 5:38 PM, Brian Paul wrote: > From: Brian Paul > > If we're drawing to a luminance, luminance/alpha or intensity surface > we have to adjust (rebase) the fragment/quad colors before writing them > to the tile cache. The tile cache always stores RGBA colors but if > we're caching a L/A surface (for example) we need to be sure that R=G=B > so that subsequent reads from the surface cache appear to return L/A > > We previously had a special case for RGB (no alpha) surfaces. This > change generalizes that for the other base formats. > > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40408, but sRGB > formats are still failing. That'll be addressed in a later patch. The fbo-blending-formats test isn't complete for sRGB yet and it's not in all.tests for the very same reason. It might work with GL_FRAMEBUFFER_SRGB disabled though, not sure. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] Make sure that Gallium code always uses its own MAX_CLIPPED_VERTICES.
On 14 September 2011 13:04, Brian Paul wrote: > On 09/14/2011 01:49 PM, Paul Berry wrote: > >> To support GLSL 1.30, we will need to increase MAX_CLIP_PLANES to 8, >> and as a side effect this will increase the value of >> MAX_CLIPPED_VERTICES defined in src/mesa/main/config.h. Gallium has >> its own value of MAX_CLIPPED_VERTICES, defined in draw_pipe_clip.c, >> but this value only takes effect if MAX_CLIPPED_VERTICES isn't already >> defined, so whether it is used or not depends on what is included by >> draw_pipe_clip.c. >> >> This patch ensures that draw_pipe_clip.c always uses its own >> definition of MAX_CLIPPED_VERTICES, so Gallium drivers won't be >> affected by increasing MAX_CLIP_PLANES to 8 until they're ready. >> --- >> src/gallium/auxiliary/draw/**draw_pipe_clip.c |6 -- >> 1 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/src/gallium/auxiliary/draw/**draw_pipe_clip.c >> b/src/gallium/auxiliary/draw/**draw_pipe_clip.c >> index b49502c..2dd8dee 100644 >> --- a/src/gallium/auxiliary/draw/**draw_pipe_clip.c >> +++ b/src/gallium/auxiliary/draw/**draw_pipe_clip.c >> @@ -49,9 +49,11 @@ >> #define DIFFERENT_SIGNS(x, y) ((x) * (y)<= 0.0F&& (x) - (y) != 0.0F) >> #endif >> >> -#ifndef MAX_CLIPPED_VERTICES >> +/* Don't use the global MAX_CLIPPED_VERTICES (which may be larger for >> other >> + * drivers); use our own. >> + */ >> +#undef MAX_CLIPPED_VERTICES >> #define MAX_CLIPPED_VERTICES ((2 * (6 + PIPE_MAX_CLIP_PLANES))+1) >> -#endif >> >> > I think the #ifndef checks around all those macros are unneeded nowadays. > Early in the gallium development there was some mixing of mesa headers with > gallium code. The #ifndef was probably used to work around that. I don't > think we have that problem or need those #ifndefs anymore. > > I also think you can just bump PIPE_MAX_CLIP_PLANES to 8 while you're at > it. > > -Brian > Ok, thanks. I'm not terribly familiar with the Gallium parts of the code base, but from what research I've done I believe you are right. Consider this patch NAKed and I'll send out a pair of followup patches making the changes you suggest. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: fix build with LLVM 3.0svn
On 09/14/2011 06:39 PM, Tobias Droste wrote: LLVM 3.0svn added SubtargetInfo as additional parameter to createMCDisassembler() and createMCInstPrinter(). See revision 139237 of LLVM. Signed-off-by: Tobias Droste Pushed. Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] softpipe: fix blending for luminance/intensity surfaces
On 09/15/2011 02:24 PM, Marek Olšák wrote: On Thu, Sep 15, 2011 at 5:38 PM, Brian Paul wrote: From: Brian Paul If we're drawing to a luminance, luminance/alpha or intensity surface we have to adjust (rebase) the fragment/quad colors before writing them to the tile cache. The tile cache always stores RGBA colors but if we're caching a L/A surface (for example) we need to be sure that R=G=B so that subsequent reads from the surface cache appear to return L/A We previously had a special case for RGB (no alpha) surfaces. This change generalizes that for the other base formats. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40408, but sRGB formats are still failing. That'll be addressed in a later patch. The fbo-blending-formats test isn't complete for sRGB yet and it's not in all.tests for the very same reason. It might work with GL_FRAMEBUFFER_SRGB disabled though, not sure. Yeah, I looked at fbo-blending-formats and there's no sign of it groking sRGB. It would be nice if the test would skip the srgb formats until they're properly tested as I often run it manually and would rather not see the invalid failures. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] Gallium: remove unnecessary ifdef for MAX_CLIPPED_VERTICES.
draw_pipe_clip.c contained an ifdef to ensure that its local definition of MAX_CLIPPED_VERTICES would not take effect if the global MAX_CLIPPED_VERTICES (defined in src/mesa/main/config.h) was already defined. This was unnecessary because draw_pipe_clip.c doesn't directly or indirectly include src/mesa/main/config.h. Removed the ifdef to reduce confusion. --- src/gallium/auxiliary/draw/draw_pipe_clip.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c b/src/gallium/auxiliary/draw/draw_pipe_clip.c index b49502c..e1eabe2 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_clip.c +++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c @@ -49,9 +49,7 @@ #define DIFFERENT_SIGNS(x, y) ((x) * (y) <= 0.0F && (x) - (y) != 0.0F) #endif -#ifndef MAX_CLIPPED_VERTICES #define MAX_CLIPPED_VERTICES ((2 * (6 + PIPE_MAX_CLIP_PLANES))+1) -#endif -- 1.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] Gallium: Increase PIPE_MAX_CLIP_PLANES to 8.
Since Mesa is now capable of supporting up to 8 clipping planes
instead of 6, this patch updates Gallium internals to support 8
clipping planes as well.
---
src/gallium/include/pipe/p_state.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index 840b3ee..a57e805 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -54,7 +54,7 @@ extern "C" {
* Implementation limits
*/
#define PIPE_MAX_ATTRIBS 32
-#define PIPE_MAX_CLIP_PLANES 6
+#define PIPE_MAX_CLIP_PLANES 8
#define PIPE_MAX_COLOR_BUFS8
#define PIPE_MAX_CONSTANT_BUFFERS 32
#define PIPE_MAX_SAMPLERS 16
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] Gallium: remove unnecessary ifdef for MAX_CLIPPED_VERTICES.
On 09/15/2011 03:55 PM, Paul Berry wrote: draw_pipe_clip.c contained an ifdef to ensure that its local definition of MAX_CLIPPED_VERTICES would not take effect if the global MAX_CLIPPED_VERTICES (defined in src/mesa/main/config.h) was already defined. This was unnecessary because draw_pipe_clip.c doesn't directly or indirectly include src/mesa/main/config.h. Removed the ifdef to reduce confusion. --- src/gallium/auxiliary/draw/draw_pipe_clip.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_pipe_clip.c b/src/gallium/auxiliary/draw/draw_pipe_clip.c index b49502c..e1eabe2 100644 --- a/src/gallium/auxiliary/draw/draw_pipe_clip.c +++ b/src/gallium/auxiliary/draw/draw_pipe_clip.c @@ -49,9 +49,7 @@ #define DIFFERENT_SIGNS(x, y) ((x) * (y)<= 0.0F&& (x) - (y) != 0.0F) #endif -#ifndef MAX_CLIPPED_VERTICES #define MAX_CLIPPED_VERTICES ((2 * (6 + PIPE_MAX_CLIP_PLANES))+1) -#endif For the series: Reviewed-by: Brian Paul BTW, the #ifndef tests around DIFFERENT_SIGNS(), etc. could probably be removed, but it's not urgent. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] softpipe: use util_format_is_depth_or_stencil()
From: Brian Paul --- src/gallium/drivers/softpipe/sp_tile_cache.c |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c b/src/gallium/drivers/softpipe/sp_tile_cache.c index 60870b8..7372470 100644 --- a/src/gallium/drivers/softpipe/sp_tile_cache.c +++ b/src/gallium/drivers/softpipe/sp_tile_cache.c @@ -180,13 +180,7 @@ sp_tile_cache_set_surface(struct softpipe_tile_cache *tc, PIPE_TRANSFER_UNSYNCHRONIZED, 0, 0, ps->width, ps->height); - tc->depth_stencil = (ps->format == PIPE_FORMAT_Z24_UNORM_S8_USCALED || - ps->format == PIPE_FORMAT_Z24X8_UNORM || - ps->format == PIPE_FORMAT_S8_USCALED_Z24_UNORM || - ps->format == PIPE_FORMAT_X8Z24_UNORM || - ps->format == PIPE_FORMAT_Z16_UNORM || - ps->format == PIPE_FORMAT_Z32_UNORM || - ps->format == PIPE_FORMAT_S8_USCALED); + tc->depth_stencil = util_format_is_depth_or_stencil(ps->format); } } -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] softpipe: use pipe_get_tile_rgba_format()
From: Brian Paul
Pass an explicit surface format as we do with pipe_put_tile_rgba_format().
This fixes the piglit fbo-srgb-blit test. With GL_EXT_framebuffer_sRGB we
override the resource's format with an explicit format (linear vs. sRGB).
We need to do so both when getting and putting tiles.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40402
---
src/gallium/drivers/softpipe/sp_tile_cache.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c
b/src/gallium/drivers/softpipe/sp_tile_cache.c
index 7372470..d3d9eb9 100644
--- a/src/gallium/drivers/softpipe/sp_tile_cache.c
+++ b/src/gallium/drivers/softpipe/sp_tile_cache.c
@@ -494,11 +494,12 @@ sp_find_cached_tile(struct softpipe_tile_cache *tc,
tile->data.depth32, 0/*STRIDE*/);
}
else {
-pipe_get_tile_rgba(tc->pipe, pt,
- tc->tile_addrs[pos].bits.x * TILE_SIZE,
- tc->tile_addrs[pos].bits.y * TILE_SIZE,
- TILE_SIZE, TILE_SIZE,
- (float *) tile->data.color);
+pipe_get_tile_rgba_format(tc->pipe, pt,
+ tc->tile_addrs[pos].bits.x * TILE_SIZE,
+ tc->tile_addrs[pos].bits.y * TILE_SIZE,
+ TILE_SIZE, TILE_SIZE,
+ tc->surface->format,
+ (float *) tile->data.color);
}
}
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] glsl hierarchical visitor: Do not overwrite base_ir for parameter lists.
This patch fixes a bug in ir_hirearchical_visitor: when traversing an
exec_list representing the formal or actual parameters of a function,
it modified base_ir to point to each parameter in turn, rather than
leaving it as a pointer to the enclosing statement. This was a
problem, since base_ir is used by visitor classes to locate the
statement containing the node being visited (usually so that
additional statements can be inserted before or after it). Without
this fix, visitors might attempt to insert statements into parameter
lists.
---
src/glsl/ir_hierarchical_visitor.h |3 ++-
src/glsl/ir_hv_accept.cpp | 21 +++--
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/src/glsl/ir_hierarchical_visitor.h
b/src/glsl/ir_hierarchical_visitor.h
index dc177f5..bba046d 100644
--- a/src/glsl/ir_hierarchical_visitor.h
+++ b/src/glsl/ir_hierarchical_visitor.h
@@ -178,6 +178,7 @@ void visit_tree(ir_instruction *ir,
void (*callback)(class ir_instruction *ir, void *data),
void *data);
-ir_visitor_status visit_list_elements(ir_hierarchical_visitor *v, exec_list
*l);
+ir_visitor_status visit_list_elements(ir_hierarchical_visitor *v, exec_list *l,
+ bool statement_list = true);
#endif /* IR_HIERARCHICAL_VISITOR_H */
diff --git a/src/glsl/ir_hv_accept.cpp b/src/glsl/ir_hv_accept.cpp
index d33fc85..0e78fda 100644
--- a/src/glsl/ir_hv_accept.cpp
+++ b/src/glsl/ir_hv_accept.cpp
@@ -30,7 +30,13 @@
*/
/**
- * Process a list of nodes using a hierarchical vistor
+ * Process a list of nodes using a hierarchical vistor.
+ *
+ * If statement_list is true (the default), this is a list of statements, so
+ * v->base_ir will be set to point to each statement just before iterating
+ * over it, and restored after iteration is complete. If statement_list is
+ * false, this is a list that appears inside a statement (e.g. a parameter
+ * list), so v->base_ir will be left alone.
*
* \warning
* This function will operate correctly if a node being processed is removed
@@ -38,19 +44,22 @@
* processed, some of the added nodes may not be processed.
*/
ir_visitor_status
-visit_list_elements(ir_hierarchical_visitor *v, exec_list *l)
+visit_list_elements(ir_hierarchical_visitor *v, exec_list *l,
+bool statement_list)
{
ir_instruction *prev_base_ir = v->base_ir;
foreach_list_safe(n, l) {
ir_instruction *const ir = (ir_instruction *) n;
- v->base_ir = ir;
+ if (statement_list)
+ v->base_ir = ir;
ir_visitor_status s = ir->accept(v);
if (s != visit_continue)
return s;
}
- v->base_ir = prev_base_ir;
+ if (statement_list)
+ v->base_ir = prev_base_ir;
return visit_continue;
}
@@ -129,7 +138,7 @@ ir_function::accept(ir_hierarchical_visitor *v)
if (s != visit_continue)
return (s == visit_continue_with_parent) ? visit_continue : s;
- s = visit_list_elements(v, &this->signatures);
+ s = visit_list_elements(v, &this->signatures, false);
return (s == visit_stop) ? s : v->visit_leave(this);
}
@@ -317,7 +326,7 @@ ir_call::accept(ir_hierarchical_visitor *v)
if (s != visit_continue)
return (s == visit_continue_with_parent) ? visit_continue : s;
- s = visit_list_elements(v, &this->actual_parameters);
+ s = visit_list_elements(v, &this->actual_parameters, false);
if (s == visit_stop)
return s;
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] glsl: Implement a lowering pass for gl_ClipDistance.
In i965 GEN6+ (and I suspect most other hardware), gl_ClipDistance needs to be laid out as a pair of vec4's (the first containing clip distances 0-3, and the second containing clip distances 4-7). However, it is declared in GLSL as an array of 8 floats. This lowering pass acts at the GLSL level, modifying the declaration of gl_ClipDistance so that it is an array of vec4's rather than an array of floats, and renaming it to gl_ClipDistanceMESA. In addition, it modifies all accesses to the array so that they access the appropiate component of one of the vec4's. Since some hardware may not internally represent gl_ClipDistance as a pair of vec4's, this lowering pass is optional. To enable it, set the LowerClipDistance flag in gl_shader_compiler_options to true. --- src/glsl/Makefile|1 + src/glsl/SConscript |1 + src/glsl/ir_optimization.h |1 + src/glsl/linker.cpp |3 + src/glsl/lower_clip_distance.cpp | 347 ++ src/mesa/main/mtypes.h |1 + 6 files changed, 354 insertions(+), 0 deletions(-) create mode 100644 src/glsl/lower_clip_distance.cpp diff --git a/src/glsl/Makefile b/src/glsl/Makefile index c20a6c9..bee21c2 100644 --- a/src/glsl/Makefile +++ b/src/glsl/Makefile @@ -56,6 +56,7 @@ CXX_SOURCES = \ loop_analysis.cpp \ loop_controls.cpp \ loop_unroll.cpp \ + lower_clip_distance.cpp \ lower_discard.cpp \ lower_if_to_cond_assign.cpp \ lower_instructions.cpp \ diff --git a/src/glsl/SConscript b/src/glsl/SConscript index 1da58a9..b4786c5 100644 --- a/src/glsl/SConscript +++ b/src/glsl/SConscript @@ -67,6 +67,7 @@ glsl_sources = [ 'loop_analysis.cpp', 'loop_controls.cpp', 'loop_unroll.cpp', +'lower_clip_distance.cpp', 'lower_discard.cpp', 'lower_if_to_cond_assign.cpp', 'lower_instructions.cpp', diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h index 48448d4..af80e26 100644 --- a/src/glsl/ir_optimization.h +++ b/src/glsl/ir_optimization.h @@ -69,6 +69,7 @@ bool lower_noise(exec_list *instructions); bool lower_variable_index_to_cond_assign(exec_list *instructions, bool lower_input, bool lower_output, bool lower_temp, bool lower_uniform); bool lower_quadop_vector(exec_list *instructions, bool dont_lower_swz); +bool lower_clip_distance(exec_list *instructions); bool optimize_redundant_jumps(exec_list *instructions); ir_rvalue * diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp index 195f58f..ceb49fd 100644 --- a/src/glsl/linker.cpp +++ b/src/glsl/linker.cpp @@ -1743,6 +1743,9 @@ link_shaders(struct gl_context *ctx, struct gl_shader_program *prog) if (!prog->LinkStatus) goto done; + if (ctx->ShaderCompilerOptions[i].LowerClipDistance) + lower_clip_distance(prog->_LinkedShaders[i]->ir); + while (do_common_optimization(prog->_LinkedShaders[i]->ir, true, 32)) ; } diff --git a/src/glsl/lower_clip_distance.cpp b/src/glsl/lower_clip_distance.cpp new file mode 100644 index 000..55a9e9d --- /dev/null +++ b/src/glsl/lower_clip_distance.cpp @@ -0,0 +1,347 @@ +/* + * Copyright © 2011 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +/** + * \file lower_clip_distance.cpp + * + * This pass accounts for the difference between the way + * gl_ClipDistance is declared in standard GLSL (as an array of + * floats), and the way it is frequently implemented in hardware (as + * a pair of vec4s, with four clip distances packed into each). + * + * The declaration of gl_ClipDistance is replaced with a declaration + * of gl_ClipDistanceMESA, and any references to gl_ClipDistance are + * translated to refer to gl_ClipDistanceMESA with the appropriate + * swizzling of array indices. For instance: + * + * gl_ClipDistance[i] + * + * is translated into: + * + * gl_
Re: [Mesa-dev] [PATCH] i965 new VS: Fix copy propagation of double negatives.
On 09/15/2011 09:19 AM, Paul Berry wrote: > When copy propagating a value into an instruction that negates its > argument, we need to invert the sense of the value's "negate" flag, so > that -(+x) becomes -x and -(-x) becomes +x. > > Previously, we were always setting the value's "negate" flag to true > in this circumstance, so that both -(+x) and -(-x) turned into -x. > > Fixes Piglit test vs-double-negative.shader_test. > --- > .../drivers/dri/i965/brw_vec4_copy_propagation.cpp |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp > b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp > index c46735a..e0b2d2a 100644 > --- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp > +++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp > @@ -196,7 +196,7 @@ try_copy_propagation(struct intel_context *intel, >value.abs = true; > } > if (inst->src[arg].negate) > - value.negate = true; > + value.negate = !value.negate; > > /* FINISHME: We can't copy-propagate things that aren't normal > * vec8s into gen6 math instructions, because of the weird src Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 40754] gallivm is broken with LLVM >r139237
https://bugs.freedesktop.org/show_bug.cgi?id=40754 ojab changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] softpipe: use util_format_is_depth_or_stencil()
On Thu, Sep 15, 2011 at 11:26 PM, Brian Paul wrote: > From: Brian Paul Reviewed-by: Dave Airlie Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] softpipe: use pipe_get_tile_rgba_format()
On Thu, Sep 15, 2011 at 11:26 PM, Brian Paul wrote: > From: Brian Paul > > Pass an explicit surface format as we do with pipe_put_tile_rgba_format(). > This fixes the piglit fbo-srgb-blit test. With GL_EXT_framebuffer_sRGB we > override the resource's format with an explicit format (linear vs. sRGB). > We need to do so both when getting and putting tiles. > > Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40402 Makes sense to me, Reviewed-by: Dave Airlie ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
