On 29/04/15 15:56, Brian Paul wrote:
On 04/29/2015 05:52 AM, Marek Olšák wrote:
On Wed, Apr 29, 2015 at 12:44 PM, Jose Fonseca <jfons...@vmware.com>
wrote:
I think there are two different things here: one is the driver
internally
fakes BGRX with BGRA, and obviously it's the pipe driver that needs
to fix
up alpha channel blending to simulate it's one.
The other is the state tracker is faking BGRX with BGRA, and in that
case,
it's the state tracker that needs to do the fix up (as the pipe has
no way
to know if that's intentional or not).
That's a fair point. On the other hand, I don't see why drivers can't
support BGRX even if they can force A=1 for texturing only.
Yeah, the key thing is whether the driver advertises support for alpha
"X" formats. We've only been doing that for one case
(PIPE_FORMAT_B8G8R8X8_UNORM) which directly corresponds to an SVGA3D_
format (SVGA3D_X8R8G8B8).
If the state tracker can always find a PIPE_FORMAT_RGBX format for a
GL_RGB format then the driver can detect this particular blend / format
combination and work things out itself.
But if the state tracker can't find a PIPE_FORMAT_RGBX format for GL_RGB
and uses a PIPE_FORMAT_RGBA format, it's really up to the state tracker
to fix-up the blend mode in this case.
The gallium interface has never specified a required set of surface
formats. Maybe we need to establish a policy for that first.
Or are you saying that state trackers should never attempt to fulfill
BGRX
formats with BGRA, and that every driver needs to workaround this
internally?
Not necessarily.
I don't fill too strongly about this, but it wouldn't sound consistent.
Nowadays have a pipe cap for every single little thing out there. I
don't
see a reason to treat render target formats differently. Otherwise
something
that can be easily done once in the state tracker now needs to be
replicated
in every driver.
But you have a point about _NEW_BUFFERS. It could be avoided. We could
introduce a new flag _NEW_BUFFERS_EMULATED, set when fbo's with emulated
formats (e.g., backing BGRX with BGRA), so that drivers that support (or
workaround) these things internally don't . On the other hand,
_NEW_BUFFERS
probably doesn't change that frequently, blend state probably changes
much
more often.
A new CAP would work. There is an easier way to do it though, see the
attached patch (assuming blend_force_dst_alpha_to_one is set
correctly).
I guess we could do yet another new cap.
I think that the is_format_support suffices. Like you said, if the
driver doesn't support the RGBX format, the state tracker will emulate
it with the RGBA. So no new cap necessary, unless some driver actually
doesn't want this automatic conversion.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
