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'm probably not going to pursue this any further right now. I'm going
off-line for a few days and have other things to finish up.
In any case, this is an odd state combination that a real app would
never hit. Why would one use GL_DST_ALPHA if the dest surface doesn't
have an alpha channel?? I am tempted to change the piglit
fbo-blend-formats test to skip the GL_DST_ALPHA blend test if the
surface doesn't have alpha. As it is, we get failures for some formats
when, in fact, all the other blend modes work fine. It's just this odd
case that's spoiling the party and given a false impression of brokenness.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
