On Fri, 12 Sep 2014 18:08:23 +0200
Christian König <christian.koenig@xxxxxxx> wrote:
> > As Daniel said using fd is most likely the way we want to do it but this
> > remains vague.
> Separating the discussion if it should be an fd or not. Using an fd
> sounds fine to me in general, but I have some concerns as well.
>
> For example what was the maximum number of opened FDs per process again?
> Could that become a problem? etc...
You can check out the i915 patches I posted if you want to see
examples. Max fds may be an issue if userspace doesn't clean up its
fences. The implementation is pretty easy with the stuff Maarten has
done recently.
The changes I still need to make to mine:
- sit on top of Chris's request/seqno changes (driver internals
really)
- switch over to execbuf as the main API on the render side (like
you're doing)
- add support for display and other timelines
As far as compat goes, I don't think it should be too hard. Even with
GPU scheduling, a given context's buffers should all be in-order with
respect to one another, so we ought to be able to mix & match clients
using explicit fencing and implicit fencing. Though in Mesa I still
haven't looked at how to handle server vs client side arb_sync with the
scheduler and explicit fencing in place; might need some extra work
there...
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
