[Mesa-dev] [PATCH] gallium: add PIPE_BIND_BLENDABLE flag

[Roland Scheidegger]

Am 12.10.2011 19:35, schrieb Christoph Bumiller:
> On 12.10.2011 19:17, Roland Scheidegger wrote:
>> Am 12.10.2011 16:31, schrieb Christoph Bumiller:
>>>> 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.
>> How do you emulate blending in some semi-sane way? Looks impossible to me.
> 
> The best I can think of, short of software rendering (which the NV blob
> does), is to render each primitive separately with a texture barrier in
> between and performing the blend operation at the end of the fragment
> shader.
That, in contrast to software rendering, sounds potentially useful, but
only if you have few large primitives, not really for the general case.

> 
>> Maybe if proprietary drivers don't do anything useful in that case (that
>> is when they are asked to render to a surface with blending they don't
>> support) we could just do the same. I don't consider software render
>> fallbacks terribly useful hence my preference would be to just not ask
>> for the PIPE_BLENDABLE flag when we don't know we need blending (which
>> means in the OpenGL state tracker) and just ignore blending in the driver.
> 
> That's what I'd prefer, not changing the GL state tracker at all.
> 
> The presence of the BLENDABLE flag would imply strict checking of
> blending functionality and allow drivers to either refuse to perform it
> (surface creation to fail, such as with formats that are not supported
> at all) or have to fall back to software (guarantee that it works),
> while its absence merely indicates that the state tracker leaves it to
> the driver to do what seems fit, which is what we have right now.
> 
>> That's not very correct though but since the whole point seems to be you
>> want to expose formats (in OpenGL) which aren't blendable and you don't
>> expect blending to actually happen how could we do better?
> 
> That, and also, as the comment in the patch says, give other state
> trackers (especially d3d1x, which has a blending support query) a means
> to check if blending would work / be slow, which, in my opinion, is
> quite useful to have.

Yes, this looks good to me. The OpenGL side will just be a bit sloppy
but not much we can do about.

Roland