On 12.10.2011 16:12, Brian Paul wrote:
> On 10/10/2011 01:53 PM, Christoph Bumiller wrote:
>> This is required for d3d1x's CheckFormatSupport query.
>>
>> It also seems generally useful for state trackers, which could
>> choose alternative rendering paths or formats if blending would
>> come at a significant performance loss.
>> ---
>> src/gallium/docs/source/screen.rst | 3 +++
>> src/gallium/include/pipe/p_defines.h | 9 +++++----
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/gallium/docs/source/screen.rst
>> b/src/gallium/docs/source/screen.rst
>> index 924858e..4a61835 100644
>> --- a/src/gallium/docs/source/screen.rst
>> +++ b/src/gallium/docs/source/screen.rst
>> @@ -160,6 +160,9 @@ resources might be created and handled quite
>> differently.
>> * ``PIPE_BIND_DEPTH_STENCIL``: A depth (Z) buffer and/or stencil
>> buffer. Any
>> depth/stencil surface/resource attached to
>> pipe_framebuffer_state::zsbuf must
>> have this flag set.
>> +* ``PIPE_BIND_BLENDABLE``: Used in conjunction with
>> PIPE_BIND_RENDER_TARGET to query
>> + whether a device supports blending for a given format.
>> + If surface creation succeeds with this flag set, the driver must
>> emulate blending.
>> * ``PIPE_BIND_DISPLAY_TARGET``: A surface that can be presented to
>> screen. Arguments to
>> pipe_screen::flush_front_buffer must have this flag set.
>> * ``PIPE_BIND_SAMPLER_VIEW``: A texture that may be sampled from in
>> a fragment
>> diff --git a/src/gallium/include/pipe/p_defines.h
>> b/src/gallium/include/pipe/p_defines.h
>> index acae4b1..447df35 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -295,10 +295,11 @@ enum pipe_transfer_usage {
>> */
>> #define PIPE_BIND_DEPTH_STENCIL (1<< 0) /* create_surface */
>> #define PIPE_BIND_RENDER_TARGET (1<< 1) /* create_surface */
>> -#define PIPE_BIND_SAMPLER_VIEW (1<< 2) /*
>> create_sampler_view */
>> -#define PIPE_BIND_VERTEX_BUFFER (1<< 3) /*
>> set_vertex_buffers */
>> -#define PIPE_BIND_INDEX_BUFFER (1<< 4) /* draw_elements */
>> -#define PIPE_BIND_CONSTANT_BUFFER (1<< 5) /*
>> set_constant_buffer */
>> +#define PIPE_BIND_BLENDABLE (1<< 2) /* create_surface */
>> +#define PIPE_BIND_SAMPLER_VIEW (1<< 3) /*
>> create_sampler_view */
>> +#define PIPE_BIND_VERTEX_BUFFER (1<< 4) /*
>> set_vertex_buffers */
>> +#define PIPE_BIND_INDEX_BUFFER (1<< 5) /* draw_elements */
>> +#define PIPE_BIND_CONSTANT_BUFFER (1<< 6) /*
>> set_constant_buffer */
>> #define PIPE_BIND_DISPLAY_TARGET (1<< 8) /*
>> flush_front_buffer */
>> #define PIPE_BIND_TRANSFER_WRITE (1<< 9) /* get_transfer */
>> #define PIPE_BIND_TRANSFER_READ (1<< 10) /* get_transfer */
>
> So do we need to go in and add PIPE_BIND_BLENDABLE to all of our
> existing surface-create calls in the state tracker, etc?
>
Well, that depends on whether we want to put blending fallbacks at the
state tracker level (OpenGL is probably the only API that requires them)
or let each driver handle them internally.
Right now, drivers for GPUs that don't support blending on some formats
(e.g. DX10 level hardware for 16 bits per component or SNORM formats)
don't care much about doing fallbacks and silently ignore that blending
won't work (speaking at least for nv50 here).
You pass the flag on resource creation, not surface creation, but since
surface creation can specify a different format, it applies only there.
I should change the wording to:
"If this flag is set, surface creation may fail if blending is not
supported for the specified format. If it is not set, a driver may
choose to ignore blending on surfaces with formats that would require
emulation."
That would leave it to the individual driver to choose whether to bother
with fallbacks or not.
-Christoph
> -Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
