Am 11.10.2014 um 20:30 schrieb Daniel Vetter: > On Thu, Oct 9, 2014 at 8:33 PM, Oded Gabbay <oded.gabbay at amd.com> 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
