On 26/07/17 06:20 AM, Eric Anholt wrote: > Daniel Stone <[email protected]> writes: > >> DRI3 version 1.1 adds support for explicit format modifiers, including >> multi-planar buffers. > > I still want proper 64-bit values, and I don't think the little XSync > mess will be much of a blocker. > >> Signed-off-by: Daniel Stone <[email protected]>
[...] >> + combined to specify a single logical source for pixel >> + sampling: 'num_buffers' may be set from 1 (single buffer, >> + akin to PixmapFromBuffer) to 4. This is the number of file >> + descriptors which will be sent with this request; one per >> + buffer. >> + >> + The exact configuration of the buffer is specified by 'format', >> + a DRM FourCC format token as defined in that project's >> + drm_fourcc.h header, in combination with the modifier. >> + >> + Modifiers allow explicit specification of non-linear sources, >> + such as tiled or compressed buffers. 'modifier_hi' (the most >> + significant 32 bits of a 64-bit value) and 'modifier_lo' are >> + combined to produce a single DRM format modifier token, again >> + as defined in drm_fourcc.h. The combination of format and >> + modifier allows unambiguous declaration of the buffer layout >> + in a manner defined by the DRM tokens. >> + >> + DRM_FORMAT_MOD_INVALID may be passed for 'modifier', in which >> + case the driver may make its own inference as to the exact >> + layout of the buffer(s). >> + >> + 'width' and 'height' describe the geometry (in pixels) of the >> + logical pixel-sample source. >> + >> + 'strideN' and 'offsetN' define the number of bytes per logical >> + scanline, and the distance in bytes from the beginning of the >> + buffer passed for that plane until the start of the sample >> + source for that plane, respectively for plane N. If the plane >> + is not used according to the format and modifier specification, >> + both values for that plane must be zero. >> + >> + Precisely how any additional information about the buffer is >> + shared is outside the scope of this extension. >> + >> + If the buffer(s) cannot be used with the screen associated with >> + 'pixmap', a Match error is returned. >> + >> + If the format and modifier combination is not supported by the >> + screen, a Value error is returned. > > Should we be specifying how the depth of the Pixmap is determined from > the fourcc? Should we be specifying if X11 rendering works on various > fourccs, and between pixmaps of different fourccs? It's not clear to me > what glamor would need to be able to do with these pixmaps (can I > CopyArea between XRGB888 and BGRX8888? What does that even mean?) X11 pixmaps provide storage for n bits per pixel, where n is the pixmap depth. CopyArea between pixmaps just copies the bits in the source to the destination verbatim. Note that this is only possible if both pixmaps have the same depth. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
