On 27.07.2017 03:14, Michel Dänzer wrote:
On 26/07/17 09:15 PM, Nicolai Hähnle wrote:
On 26.07.2017 08:29, Michel Dänzer wrote:
On 25/07/17 05:28 PM, Nicolai Hähnle wrote:
On 22.07.2017 14:00, Daniel Stone wrote:
Given that, I'm fairly inclined to punt those until we have the grand
glorious allocator, rather than trying to add it to EGL/GBM
separately. The modifiers stuff was a fairly obvious augmentation -
EGL already had no-modifier format import but no query as to which
formats it would accept, and modifiers are a logical extension of
format - but adding the other restrictions is a bigger step forward.
Perhaps a third option would be to encode the required pitch_in_bytes
alignment as part of the modifier?
So DRI3GetSupportedModifiers would return DRM_FORMAT_MOD_LINEAR_256B
when the display GPU is a Raven Ridge.
More generally, we could say that fourcc_mod_code(NONE, k) means that
the pitch_in_bytes has to be a multiple of 2**k for e.g. k <= 31. Or if
you prefer, we could have a stride requirement in elements or pixels
instead of bytes.
Interesting idea. FWIW, I suspect we'd need to support specifying the
requirement in both bytes or pixels, since one or the other alone may
not be sufficient to describe the constraints of all hardware.
From what I've seen, modifiers are always specified together with one
specific format, so the bytes-per-pixel are always known, so I don't
think we need both.
The proposal adds two DRI3 extension requests for querying the list of
supported formats and modifiers, respectively. This suggests that the
supported formats and modifiers can be freely combined.
Which are these? I only saw DRI3GetSupportedModifiers, which takes both
a window and a format argument.
Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
