On Thu, 2017-11-30 at 13:20 -0500, Rob Clark wrote: > 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 There is wip from ajax to add support for this actually, although it didn't do much correctly the last time I played with it:
https://cgit.freedesktop.org/~ajax/mesa/log/?h=egl-ext-device I was also hoping to write a simple egl device testing extension that lists devices and that sort of stuff, as well made an entire seperate repo to start holding glxinfo, eglinfo, and group said tool in with that. Haven't actually written any code for this yet though > 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
