lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 13 Jul 2014 11:42:58 +0200 From: Daniel Vetter <daniel@...ll.ch> To: Jerome Glisse <j.glisse@...il.com> Cc: Christian König <christian.koenig@....com>, "Gabbay, Oded" <Oded.Gabbay@....com>, "oded.gabbay@...il.com" <oded.gabbay@...il.com>, "Lewycky, Andrew" <Andrew.Lewycky@....com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, "Deucher, Alexander" <Alexander.Deucher@....com>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, Jesse Barnes <jbarnes@...tuousgeek.org> Subject: Re: [PATCH 00/83] AMD HSA kernel driver On Sat, Jul 12, 2014 at 6:49 PM, Jerome Glisse <j.glisse@...il.com> wrote: >> Hm, so the hsa part is a completely new driver/subsystem, not just an >> additional ioctl tacked onto radoen? The history of drm is littered with >> "generic" ioctls that turned out to be useful for exactly one driver. >> Which is why _all_ the command submission is now done with driver-private >> ioctls. >> >> I'd be quite a bit surprised if that suddenly works differently, so before >> we bless a generic hsa interface I really want to see some implementation >> from a different vendor (i.e. nvdidia or intel) using the same ioctls. >> Otherwise we just repeat history and I'm not terribly inclined to keep on >> cleanup up cruft forever - one drm legacy is enough ;-) >> >> Jesse is the guy from our side to talk to about this. >> -Daniel > > I am not worried about that side, the hsa foundation has pretty strict > guidelines on what is hsa compliant hardware ie the hw needs to understand > the pm4 packet format of radeon (well small subset of it). But of course > this require hsa compliant hardware and from member i am guessing ARM Mali, > ImgTech, Qualcomm, ... so unless Intel and NVidia joins hsa you will not > see it for those hardware. > > So yes for once same ioctl would apply to different hardware. The only things > that is different is the shader isa. The hsafoundation site has some pdf > explaining all that but someone thought that slideshare would be a good idea > personnaly i would not register to any of the website just to get the pdf. > > So to sumup i am ok with having a new device file that present uniform set > of ioctl. It would actualy be lot easier for userspace, just open this fix > device file and ask for list of compliant hardware. > > Then radeon kernel driver would register itself as a provider. So all ioctl > decoding marshalling would be share which makes sense. There's also the other side namely that preparing the cp ring in userspace and submitting the entire pile through a doorbell to the hw scheduler isn't really hsa exclusive. And for a solid platform with seamless gpu/cpu integration that means we need standard ways to set gpu context priorities and get at useful stats like gpu time used by a given context. To get there I guess intel/nvidia need to reuse the hsa subsystem with the command submission adjusted a bit. Kinda like drm where kms and buffer sharing is common and cs driver specific. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists