[Mesa-dev] [PATCH] mesa/st: In the precense of integer buffers enable per buffer blending

[Ilia Mirkin]

On Tue, Sep 25, 2018 at 6:54 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On Wednesday, September 26, 2018 12:48:13 AM CEST Kenneth Graunke wrote:
>> On Tuesday, September 25, 2018 4:20:04 PM CEST Ilia Mirkin wrote:
>> > I haven't double-checked yet, but doesn't this result in a reduction
>> > of functionality for pre-independent-blend GPUs (like the early NVIDIA
>> > Tesla series)? Configuring blending for an integer RT does nothing on
>> > NVIDIA hardware, so it all works out there just fine...
>> >
>> > Perhaps both patches should just be reverted and keep things as they
>> > were, and let drivers worry about this?
>
> I forgot to mention...since my patch did break things, and this fix
> apparently isn't ready to land...IMO feel free to revert both patches
> for now.  I do want the eventual solution to not be "make the driver
> deal with it", but there's no sense leaving things broken while we
> figure out a final solution.

Well, this change landed, which is how I noticed it. (Only by reading
the commit, mind you -- haven't tested, but I don't think there's any
other possible outcome.)

The problem is that (some) new hardware is totally hard-wired for
per-rt blend settings, and the global one makes no sense. Old hardware
can't do independent blend, or there's a performance penalty to doing
it (or put another way, a performance gain to be had from having
identical settings).

As for "is there blend for integer RTs" question, one can define it
however. I can make the argument that sure, there is integer blend.
The blend equation works like this: use source color, always. Your
hardware doesn't take the rt format into account as part of the blend
equation, NVIDIA hardware does. It is what it is.

I know that you're coming into this from a position of mild
frustration -- you thought the gallium API worked like X, but it
worked like Y. You'd like it to work like X since that'd make your
driver simpler (and perhaps some other drivers), but that breaks other
drivers that rely on Y. You feel like X is really the correct way of
doing it, so wouldn't it be nice if we could just do X. I get that
feeling every so often too. My pet peeve is the stupid resolve you
have to do in pipe_transfer_map for winsys fbo's. But other than some
initial driver bringup, you tend not to run into it -- I mean how
often do you touch blend settings once you get blending all figured
out.

That said, it's hard to create a single low-level interface that works
well for all hardware out there. My understanding is that gallium even
had fixed function api support back in the bad old days. Things need
to get dropped every so often. One avenue is to make a st/mesa-old and
st/mesa-new, where the latter assumes certain new features and thus
can make life easier on the drivers. We could make the cut-off at
nv50/r600-pre-eg, for example. Don't know if that'd be beneficial.

  -ilia