[Mesa-dev] [PATCH 5/7] mesa: add support for AMD_blend_minmax_factor

Maxence Le Doré maxence.ledore at gmail.com
Fri Jan 3 07:51:20 PST 2014


- You're right ! I've just checked spec and initial draft is from
march 2010. 2009 is a mistake. Thanks.
- You're the third one to request piglit tests. I'll have to do it. Or
I could not complain if some devs become angry against me for sending
patches and never with at least a pinch of according update to piglit
test suite. I found to
About the fact that some gallium driven gpu may not support factored
min/max blending, I supposed it initialy and, indeed, added a cap
enum. But when I saw the way min/max blending what implemented in
gallium for all drivers, I supposed it was ok (A piglit test for
EXT_blend_minmax is in the codebase since 2004. If this piglit test
would failed with some gallium drivers, I assumed this problem would
have been already fixed on the gallium side). Of course I should have
already checked this by myself instead of suppose it.
- For the facts that d3d 9/10 require blend factors to be ignored, I
even didn't know. And this sound important indeed.

So I'm going to correct this, but first I'll sent one or more piglit
tests to the appropriate dev mailing list.
I found two interesting model to write them in the piglit code base :
tests/general/blendminmax.c
tests/general/blendsquare.c


2014/1/3 Roland Scheidegger <sroland at vmware.com>:
> Am 03.01.2014 02:18, schrieb Maxence Le Doré:
>> ---
>>  src/mesa/main/blend.c      | 3 +++
>>  src/mesa/main/extensions.c | 1 +
>>  src/mesa/main/mtypes.h     | 1 +
>>  3 files changed, 5 insertions(+)
>>
>> diff --git a/src/mesa/main/blend.c b/src/mesa/main/blend.c
>> index 9e11ca7..4995143 100644
>> --- a/src/mesa/main/blend.c
>> +++ b/src/mesa/main/blend.c
>> @@ -326,6 +326,9 @@ legal_blend_equation(const struct gl_context *ctx, GLenum mode)
>>     case GL_MIN:
>>     case GL_MAX:
>>        return ctx->Extensions.EXT_blend_minmax;
>> +   case GL_FACTOR_MIN_AMD:
>> +   case GL_FACTOR_MAX_AMD:
>> +      return ctx->Extensions.AMD_blend_minmax_factor;
>>     default:
>>        return GL_FALSE;
>>     }
>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
>> index f0e1858..b46c788 100644
>> --- a/src/mesa/main/extensions.c
>> +++ b/src/mesa/main/extensions.c
>> @@ -299,6 +299,7 @@ static const struct extension extension_table[] = {
>>
>>     /* Vendor extensions */
>>     { "GL_3DFX_texture_compression_FXT1",           o(TDFX_texture_compression_FXT1),           GL,             1999 },
>> +   { "GL_AMD_blend_minmax_factor",                 o(AMD_blend_minmax_factor),                 GL,             2009 },
>>     { "GL_AMD_conservative_depth",                  o(ARB_conservative_depth),                  GL,             2009 },
>>     { "GL_AMD_draw_buffers_blend",                  o(ARB_draw_buffers_blend),                  GL,             2009 },
>>     { "GL_AMD_performance_monitor",                 o(AMD_performance_monitor),                 GL,             2007 },
>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
>> index f93bb56..4081e4e 100644
>> --- a/src/mesa/main/mtypes.h
>> +++ b/src/mesa/main/mtypes.h
>> @@ -3433,6 +3433,7 @@ struct gl_extensions
>>     GLboolean EXT_vertex_array_bgra;
>>     GLboolean OES_standard_derivatives;
>>     /* vendor extensions */
>> +   GLboolean AMD_blend_minmax_factor;
>>     GLboolean AMD_performance_monitor;
>>     GLboolean AMD_seamless_cubemap_per_texture;
>>     GLboolean AMD_vertex_shader_layer;
>>
>
> Where did you get the 2009 year from? The earliest I can find is 2010.
> Also, I think it would be nice if there'd be some test (piglit) for this.
> And could this be enabled for gallium drivers? Right now the state
> tracker translates away the blend factors for min/max as the gallium
> interface already could handle this extension without any effort. That
> said, I'm not sure if all drivers can handle it (nvidia in particular),
> since afair d3d (9 and 10) also require blend factors to be ignored
> hence it is indeed possible not everyone can do it. In this case a cap
> bit would be required.
>
> Roland


More information about the mesa-dev mailing list