On Sat, Jul 12, 2014 at 6:49 PM, Jerome Glisse <j.glisse@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
