Daniel Stone <daniel@xxxxxxxxxxxxx> writes: > Hey Eric, > > On 3 March 2018 at 01:34, Eric Anholt <eric@xxxxxxxxxx> wrote: >> Ccing a couple of folks who are likely to have opinions about >> drm_fourcc.h additions (Do we have enough docs? Are the macros OK?), >> and Bootlin who are likely reviewers. >> >> The plan is to use these modifiers in VC4 GL imports as well, and for >> buffers coming from the v4l2 mmal camera driver. You can find a demo >> using this in KMS planes at >> https://github.com/anholt/drm_mmal/commit/sand for now. > > I had a dig through and this seems like the most sensible thing to do > if you have a reasonable variety of tile heights. If you only see a > couple of combinations in the wild, then hardcoding them as separate > modifiers might make things easier than hiving off 24 bits. If you do > keep the split though, and especially if you're envisioning future > flexible tile formats, maybe something like an 8 code / 48 params > split would make more sense. > > Either way, those are just my opinions (you did ask), and I don't see > anything really objectionable, so if you think that's a good split > then this is: > Acked-by: Daniel Stone <daniels@xxxxxxxxxxxxx> I had been thinking of potentially specifying a meaning for the other 24 bits (separate U/V plane v stride if set, if we ever get a component that needs to do that), so I went ahead and did this, along with a couple of fixes due to Ville's patch.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
