Hey Emil,
On 12 July 2017 at 16:10, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> There's one small bug that I've missed previously. Other than that the
> patch looks great
Thanks for taking a look!
> On 16 June 2017 at 18:14, Daniel Stone <dani...@collabora.com> wrote:
>> + if (num_modifiers && dri2_dpy->image->base.version >= 15 &&
>> + dri2_dpy->image->createImageWithModifiers) {
>> + dri2_surf->back->dri_image =
>> + dri2_dpy->image->createImageWithModifiers(dri2_dpy->dri_screen,
>> + dri2_surf->base.Width,
>> + dri2_surf->base.Height,
>> + dri_image_format,
>> + modifiers,
>> + num_modifiers,
>> + NULL);
>> + } else {
>> + dri2_surf->back->dri_image =
>> + dri2_dpy->image->createImage(dri2_dpy->dri_screen,
> I believe we should not fallback to the createImage API if num_modifiers != 0.
That was completely intentional, but you're right - it probably
warrants a comment.
Modifiers are just a suggestion from the upstream window system as to
how to allocate. If the driver doesn't support allocating with
modifiers, we don't _need_ to do it. We just fall back to the previous
system, which is for the driver to make an allocation it 'knows' will
succeed, which is either linear, or if on the same GPU, using tiling
with an Intel/VC4-style magic kernel backchannel for the winsys to
determine the tiling on import.
Practically, this would happen when we have i965 used for composition
on the winsys side (offering a list of acceptable modifiers), and
radeonsi used on the client/rendering side (no support for modifiers).
If we refused to use the legacy createImage() hook when modifiers were
provided, we wouldn't be able to use radeonsi at all.
I'll put this into a less wordy comment for v2. :)
Cheers,
Daniel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
