Am 11.10.2014 um 20:30 schrieb Daniel Vetter:
On Thu, Oct 9, 2014 at 8:33 PM, Oded Gabbay <oded.gabbay@xxxxxxx> wrote:
Thanks for the input.
I do _not_ intend to fork IOCTLs for new H/W generations, if possible.
i.e, our driver now supports 2 h/w generations with the exact same set
of IOCTLs and I don't see how that would change in the future..
What I'm more worried about is supporting different sets of UMD, which
will require different IOCTLs for the same operation, e.g. CreateQueue
for HSA runtime and OpenCL runtime.
However, due to a very limited amount of UMDs, the "regular" way of
adding IOCTLs may be sufficient.
Bottom line, need to think more about it :)
Hm, generally the ioctls should be modelled on the hw for a generic
umd. Of course that's a bit hard in practice since predicting the
unkown is difficult ;-).
Yeah, exactly what I'm telling to the closed source people here at AMD
as well :) It took me a while, but I think it's slowly sinking in now
that IOCTL interfaces shouldn't be specialized for a certain use case.
The good news is that as far as I've seen the HSA IOCTL interface it
actually looks quite generic to me.
Regards,
Christian.
But on intel hw we have about 5+ different
umd stacks if you count them all, and they all seem to be more-or-less
happy with the same ioctl interface. Like I've said it does require a
bit a mindset change though since clean-slate designs should only be
done when there's overwhelming reasons that the old interfaces just
don't cut it any more. Otoh you also need to make sure that all the
different umd teams talk to each another since ime they also err on
the other side and each come up with their own special hack to enable
a given new feature.
-Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
