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 mean, maybe, but seeing as blending is non-sensical for integer RTs, and all of the settings are meaningless...it's really nice to have the state tracker just clean this up. As I said in my patches, it also should improve CSO cache hits by making more state combinations become identical...which might also be nice. Fundamentally, you /are/ doing different blending settings per render target in the presence of integer buffers. I figured this couldn't possibly have worked in that case. But, as you said, it does. I don't know. Seems like modern HW really wants things to work differently than old HW. Maybe old HW drivers can be the ones to carry the burden since there are fewer of them. They could look for any blend state that isn't all 0's. Or, we could make st skip this for drivers without per-RT blending caps. Or, just ensure that set_blend_state's blend[0] is a non-integer setting for those drivers, somehow. This is my first time contributing to Gallium and I'd really like the answer to every patch I send to not be "we can't make the common framework do that, please foist the problem back onto your driver". :( At the same time, I know we can't break them...sorry about not thinking about it...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
