On Mon, Oct 9, 2017 at 5:22 PM, Daniel Stone <[email protected]> wrote: > Hi Marek, > > On 4 October 2017 at 12:38, Marek Olšák <[email protected]> wrote: >> Yeah I don't have an answer to that. I think it's better to pageflip than >> blit. Can Wayland reallocate the buffer to make it displayable? If not, it >> may be better to create displayable buffers always. > > Not sure what you mean by 'Wayland reallocate'? The buffers are > (DRI3-style) allocated by the client's EGLSurface, with no > intermediate server-allocated storage at any point There is no > explicit hint to the client whether it is being scanned out or not. > Even if there was, there is no indication of which device the buffer > might be scanned out on - a device the client might not have access to > (e.g. a display controller with no render nodes). I've mostly been > waiting for the allocator to come around before trying to deal with > this. But even with that, we'd still require the tiling information to > actually be exposed externally (i.e. through modifiers); currently the > compositor can't introspect the tiling flags at all, so it has no idea > that it shouldn't try to scan this particular buffer out. > > Which is exactly the problem validateUsage() is supposed to solve. All > we can do is rely on gbm_bo_import failing (which is best, as it can > never be used for scanout), or at least the KMS commit fail (worse, > especially pre-atomic, but still beats displaying garbage?). We don't > need magic blits, or untiled views, or anything: just failing is fine > and we'll fall back to composition.
I prefer page flipping over composition. With X/DRI, the DRI state tracker (or maybe libGL/libEGL) always sets the scanout flag. Starting with our Raven APU, the scanout and non-scanout tiling mode is the same for 32bpp, so there won't be any compatibility issue. Marek _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
