On Thu, Nov 30, 2017 at 12:59 AM, James Jones <jajo...@nvidia.com> wrote: > On 11/29/2017 04:09 PM, Miguel Angel Vico wrote: >> >> On Wed, 29 Nov 2017 16:28:15 -0500 >> Rob Clark <robdcl...@gmail.com> wrote: >>> >>> Do we need to define both in-place and copy transitions? Ie. what if >>> GPU is still reading a tiled or compressed texture (ie. sampling from >>> previous frame for some reason), but we need to untile/uncompress for >>> display.. of maybe there are some other cases like that we should >>> think about.. >>> >>> Maybe you already have some thoughts about that? >> >> >> This is the next thing I'll be working on. I haven't given it much >> thought myself so far, but I think James might have had some insights. >> I'll read through some of his notes to double-check. > > > A couple of notes on usage transitions: > > While chatting about transitions, a few assertions were made by others that > I've come to accept, despite the fact that they reduce the generality of the > allocator mechanisms: > > -GPUs are the only things that actually need usage transitions as far as I > know thus far. Other engines either share the GPU representations of data, > or use more limited representations; the latter being the reason non-GPU > usage transitions are a useful thing. > > -It's reasonable to assume that a GPU is required to perform a usage > transition. This follows from the above postulate. If only GPUs are using > more advanced representations, you don't need any transitions unless you > have a GPU available.
This seems reasonable. I can't think of any non-gpu related case where you would need a transition, other than perhaps cache flush/inv. > From that, I derived the rough API proposal for transitions presented on my > XDC 2017 slides. Transition "metadata" is queried from the allocator given > a pair of usages (which may refer to more than one device), but the > realization of the transition is left to existing GPU APIs. I think I put > Vulkan-like pseudo-code in the slides, but the GL external objects > extensions (GL_EXT_memory_object and GL_EXT_semaphore) would work as well. I haven't quite wrapped my head around how this would work in the cross-device case.. I mean from the API standpoint for the user, it seems straightforward enough. Just not sure how to implement that and what the driver interface would look like. I guess we need a capability-conversion (?).. I mean take for example the the fb compression capability from your slide #12[1]. If we knew there was an available transition to go from "Dev2 FB compression" to "normal", then we could have allowed the "Dev2 FB compression" valid set? [1] https://www.x.org/wiki/Events/XDC2017/jones_allocator.pdf > Regarding in-place Vs. copy: To me a transition is something that happens > in-place, at least semantically. If you need to make copies, that's a > format conversion blit not a transition, and graphics APIs are already > capable of expressing that without any special transitions or help from the > allocator. However, I understand some chipsets perform transitions using > something that looks kind of like a blit using on-chip caches and > constrained usage semantics. There's probably some work to do to see > whether those need to be accommodated as conversion blits or usgae > transitions. I guess part of what I was thinking of, is what happens if the producing device is still reading from the buffer. For example, viddec -> gpu use case, where the video decoder is also still hanging on to the frame to use as a reference frame to decode future frames? I guess if transition from devA -> devB can be done in parallel with devA still reading the buffer, it isn't a problem. I guess that limits (non-blit) transitions to decompression and cache op's? Maybe that is ok.. > For our hardware's purposes, transitions are just various levels of > decompression or compression reconfiguration and potentially cache > flushing/invalidation, so our transition metadata will just be some bits > signaling which compression operation is needed, if any. That's the sort of > operation I modeled the API around, so if things are much more exotic than > that for others, it will probably require some adjustments. > [snip] > > Gralloc-on-$new_thing, as well as hwcomposer-on-$new_thing is one of my > primary goals. However, it's a pretty heavy thing to prototype. If someone > has the time though, I think it would be a great experiment. It would help > flesh out the paltry list of usages, constraints, and capabilities in the > existing prototype codebase. The kmscube example really should have added > at least a "render" usage, but I got lazy and just re-used texture for now. > That won't actually work on our HW in all cases, but it's good enough for > kmscube. > btw, I did start looking at it.. I guess this gets a bit into the other side of this thread (ie. where/if GBM fits in). So far I don't think mesa has EGL_EXT_device_base, but I'm guessing that is part of what you had in mind as alternative to GBM ;-) BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
