Re: AMD GPU new API for new module

["Christian König" <deathsimple@vodafone.de>]

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