Alyssa Rosenzweig <aly...@rosenzweig.io> writes: >> Alyssa: do you see any problem if we change to submit only one atom per >> ioctl? > > I don't think so; aesthetically I don't like the extra kernel traffic, > but that's not a real concern, and it sounds like that's the correct > approach anyway. > > A big reason we submit together on non-DRM is so we can get the kernel > to deal with dependency tracking; if we have proper syncobjs/fences, > that doesn't matter I don't think. > >> Guess syncobj refs are akin to GEM handles and fences to dmabuf buffers from >> the userspace POV? > > *tries to figure out what the difference between GEM handles and dmabuf > buffers*
GEM handles: per-DRM-fd small integer references to your BOs. Non-refcounted (GEM_CLOSE frees that number). dmabuf: fd reference to a BO. May be imported/exported to/from a GEM handle using the prime interfaces. Watch out for how it'll hand you back the same handle for a reimport of a buffer you already have a GEM handle to! The fd can be passed over unix domain sockets, which is how we move references to buffers between processes.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
