On Mon, Sep 11, 2017 at 10:57 AM, Nicolai Hähnle <[email protected]> wrote: > On 11.09.2017 16:47, Ilia Mirkin wrote: >> >> On Mon, Sep 11, 2017 at 10:44 AM, Nicolai Hähnle <[email protected]> >> wrote: >>> >>> From: Nicolai Hähnle <[email protected]> >>> >>> It breaks integer inputs and outputs on vertex processing stages >>> (e.g. geometry stages). Instead, rely on the driver to choose >>> smooth interpolation by default. >>> --- >>> >>> How about this instead? I haven't fully thought it through, but >>> that's where the INTERP_MODE_SMOOTH is coming from. >>> >>> To be honest I'm not 100% sure about what INTERP_MODE_NONE can >>> mean, but I think it's definitely better than removing the (very >>> valid!) assertion in the packing code. >> >> >> I couldn't understand what that assertion was asserting, esp in the >> presence of struct in/out variables. > > > structs can't have per-member interpolation qualifiers. So a struct that > contains integer values must have FLAT or NONE interpolation as a whole. > > That clashes pretty hard with that ES rule, though ("When no interpolation > qualifier is present, smooth interpolation is used."). > > On second thought, that assertion is actually irrelevant for varying packing > itself, but it's still pretty disturbing that it's broken by this particular > shader.
I'm just saying... what exactly is that assert protecting against that varying packing cares so much about... I guess it wants to avoid packing an int with a smooth float into a single varying? But that's handled at packing time when it decides which packed varying to stuff it into. As an aside, what about doubles or int64? Also I'm pretty sure you can explicitly say "smooth" in non-frag shaders with little to no consequence. But I haven't checked. -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
