> - about 1/5 of the patch seems to be white space changes ...Oops. Any tips for avoiding this type of diff churn in the future? I suppose it's not inherently harmful, but maybe it could make merging more difficult than strictly necessary.
> - doesn't seem like BIFROST is defined anywhere Indeed it's not; Bifrost is not yet supported, but at least this way we can share headers with the out-of-tree work on Bifrost (is anyone working on these parts right now..?) > - other drivers keep details like is_t6xx, require_sfbd, others in > driver/screen specific struct Aye, that'll be fixed next patch :) > - the __LP64__ checks seems suspicious, no other mesa driver has those Is there a better way to handle mixed bit-ness? We have shared memory (sort of -- separate MMUs, separate address spaces, but they're mapped together with shared physical RAM and we opt for SAME_VA where gpu_va == user_cpu_va). As such, 32-bit Mali and 64-bit Mali behave differently, since pointers are larger and then some fields get rearranged to pack tighter/less-so depending on pointer sizes. There's no real benefit to support both modes in the same build of the driver; by far, having a 32-bit build for armhf with 32-bit Mali descriptors and a 64-bit build for aarch64 with 64-bit descriptors is the sane approach. Accordingly, I reasoned that __LP64__ is the cleanest way to check what type of system we're building for, and from there which descriptor flavour we should use. Is there something inherently problematic about this scheme? In theory we can mix and match, the hardware can do both regardless of the CPU as far as I know, but that complicates things dramatically for little benefit. Keep in mind that Midgard onwards uses descriptors in shared memory, rather than a true command stream, so it's possible no other mesa driver does this since no other mesa-supported hardware needs this. Thank you, Alyssa _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
