Michel Dänzer <[email protected]> writes: > [ Unknown signature status ] > On 27/07/17 07:38 AM, Eric Anholt wrote: >> Michel Dänzer <[email protected]> writes: >> >>> [ Unknown signature status ] >>> 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. >> >> Right. So is the plan that XRGB888 to BGRX8888 (both depth 24) > > I don't see how those can both be depth 24.
That's what both patch 5 of this series and pixman say the depth is for bgrx8888. I think things have only worked because nobody uses bgrx8888 with Render and also tries to do core operations with those contents, but I think we should figure out what we actually want the behavior to be here. I don't think we want to define that CopyArea from XRGB8888 to BGRX8888 shifts the 24 bits of depth up by 8 within the 32bpp pixels. One of the options might be to say something along the lines of "core rendering between pixmaps of different drm_fourccs is undefined". I think figuring out what the exact requirement would be takes a bit more thought, though.
signature.asc
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
