On Tue, Sep 25, 2018 at 6:54 PM, Kenneth Graunke <kenn...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev