search for: is_pre_tur

...or formats on > >> + * pre-Turing GPUs. > > > > Hm, maybe a tiny static inline function which canonizalizes modifiers? > > Something like > > > > static inline u64 > > drm_fourcc_canonicalize_nvidia_block_linear_2d(u64 modifer, bool > > is_pre_turing) > > { > > } > > > > Would then give you a nice place to stick this backward compat note and > > make it really clear what should be done. I think establishing this as a > > pattern would also be nice, since I'm sure we'll have a pile more of these &gt...

...t; + * "generic" kind used for simple single-sample color formats on > + * pre-Turing GPUs. Hm, maybe a tiny static inline function which canonizalizes modifiers? Something like static inline u64 drm_fourcc_canonicalize_nvidia_block_linear_2d(u64 modifer, bool is_pre_turing) { } Would then give you a nice place to stick this backward compat note and make it really clear what should be done. I think establishing this as a pattern would also be nice, since I'm sure we'll have a pile more of these cases where modifiers turn out to assume a few too many things...

...kind used for simple single-sample color formats on >> + * pre-Turing GPUs. > > Hm, maybe a tiny static inline function which canonizalizes modifiers? > Something like > > static inline u64 > drm_fourcc_canonicalize_nvidia_block_linear_2d(u64 modifer, bool > is_pre_turing) > { > } > > Would then give you a nice place to stick this backward compat note and > make it really clear what should be done. I think establishing this as a > pattern would also be nice, since I'm sure we'll have a pile more of these > cases where modifiers turn...

Beyond general review, I'm looking for feedback on a few things specifically here: -Is the level of backwards compatibility described here sufficient? Technically I can make the user space drivers support the old modifiers too, but that would mean the layout they specify would morph based on the GPU they're being used on, and sharing buffers between two different NV GPUs, which would