From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Christian_K=F6nig?= Subject: Re: AMD GPU new API for new module Date: Sun, 12 Oct 2014 11:33:07 +0200 Message-ID: <543A4AD3.2040107@vodafone.de> References: <20141008160026.GA7643@gmail.com> <54363116.2050900@amd.com> <20141009080256.GB4576@gmail.com> <54366026.9020408@amd.com> <5436D50D.6070502@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id B1D706E054 for ; Sun, 12 Oct 2014 02:33:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by pegasos-out.vodafone.de (Rohrpostix2 Daemon) with ESMTP id 19E005F02D1 for ; Sun, 12 Oct 2014 11:33:42 +0200 (CEST) Received: from pegasos-out.vodafone.de ([127.0.0.1]) by localhost (rohrpostix2.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snpbncB3IN24 for ; Sun, 12 Oct 2014 11:33:20 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter , Oded Gabbay Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org Am 11.10.2014 um 20:30 schrieb Daniel Vetter: > On Thu, Oct 9, 2014 at 8:33 PM, Oded Gabbay 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