On 28/07/17 05:03 PM, Daniel Stone wrote: > On 28 July 2017 at 01:11, Keith Packard <kei...@keithp.com> wrote: >> Eric Anholt <e...@anholt.net> writes: >>> I think one option would be to have this extension create pixmaps with a >>> depth equal to the highest populated bit of the fourcc plus one. Sure, >>> it's weird that rgbx8888 and xrgb888 have a different depth, but "depth" >>> is a pretty awful concept at this point. >> >> It's just supposed to express which bits in the pixel contribute to >> generating the resulting color; bits outside of depth 'don't matter', >> and may not even be retained. Of course, for fourcc values which spread >> 'pixel' data across multiple storage units. >> >> Sorry for not reading the whole proposal up front; I've been out >> crabbing in the San Juan's for a week and trying to catch up on email in >> the last few days... > > Really can't fault your choices there. > >> When I was doing Present, what I figured was that we'd define new kinds >> of read-only picture which had image storage data associated with it >> that could be in a non-pixel format -- various fourcc formats using >> multiple buffers, jpeg, png or whatever. You could use those with Render >> or Present to get data into RGB format or onto the screen. Trying to >> mash them into 'pixmaps' makes little sense. >> >> In this case, I'd imagine we'd add fourcc pictures, and a new >> DRI3PictureFromBuffers request. Adding a PresentPicture request would be >> a nice bonus feature to make sure the copy was synchronized with vblank. > > Hm. I think I prefer Eric's suggestion, of just declaring this to be > undefined behaviour.
Declaring where? Once a pixmap is created, it only has a depth, no format, so there's nothing to base on that e.g. CopyArea between two pixmaps of the same depth is undefined. > You're right that it makes little to no sense to mix the two, but I'm > not sure what practical gain we get from expressing things as > Pictures. Ultimately, the server still deals in Window Pixmaps and > Screen Pixmaps for backing storage, and the compositor interface is > NameWindowPixmap. Your suggestion of another type seems nicer, but it > doesn't look like we can avoid Pixmaps as the lowest common > denominator anyway. > > By implementation if not spec, DRI3 v1.0 enforces that depth 16 is > RGB565, depth 24 is XRGB8888, and depth 32 is ARGB8888. No, it doesn't. How the bits stored in a pixmap are interpreted is outside of the scope of DRI3 1.0. > Or at least in Mesa: the server only supports the latter two with > glamor_egl. It seems like this has served well enough for long enough, > so equally we could just eliminate the FourCC from the protocol, stick > with the fixed depth <-> base format mapping, and encode that in the > protocol text as well. > > That would much more clearly match the intention of the spec > additions, which was to allow non-linearly-addressed (Intel X/Y*, > Vivante tiled/supertiled, VC4 T-tiled, the infinite AMD/NV tiling > modes) buffers, as well as losslessly-compressed buffers (Intel CCS, > whatever Tegra calls its mode which similarly has an auxiliary buffer > to interpret the tiled primary colour buffer, ARM AFBC which is just > an inline block format). Allowing YUV buffers, attaching colourspace > information (e.g. converting between primaries/EOTF), replacing the > use of Pixmaps with another buffer type (Readable as a counterpart to > Drawable ... ?), would all be objectively good things to have, but > equally I don't think trying to fix them in a protocol which is really > just a better version of PutImage for Pixmaps is the best thing. > > tl;dr: we could replace FourCC with depth as the format determinant to > better match DRI3 v1.0, or just declare that doing anything with those > Pixmaps other than displaying them to a Window with a compatible > Visual results in undefined behaviour I'm getting less and less convinced that any reference at all to formats in the context of pixmaps in the DRI3 specification is a good idea. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel