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

[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.

> 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.

> Roland
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev