AMD GPU new API for new module

2014-10-14 Thread Dave Airlie
On 9 October 2014 19:20, Daniel Vetter wrote: > On Wed, Oct 8, 2014 at 6:00 PM, Jerome Glisse wrote: >> >> struct radeon_ioctl { >> u32 version; >> u32 size; >> }; > > How is this any different from just another ioctl multiplexer and why > can't we just add a new version i

AMD GPU new API for new module

2014-10-12 Thread Christian König
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 s

AMD GPU new API for new module

2014-10-12 Thread Oded Gabbay
On 11/10/14 21:30, Daniel Vetter wrote: > 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 h

AMD GPU new API for new module

2014-10-11 Thread 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'

AMD GPU new API for new module

2014-10-10 Thread Olaf Buddenhagen
Hi, On Wed, Oct 08, 2014 at 12:00:27PM -0400, Jerome Glisse wrote: [...] > And now all ioctl go through this single entry point : > > int radeon_ioctl_stub(int ioctl, void *data, ...) > { > struct radeon_ioctl *rio = data; > > return rdispatch_ioctls[rio->version][ioctl](data, ...); >

AMD GPU new API for new module

2014-10-09 Thread Oded Gabbay
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

AMD GPU new API for new module

2014-10-09 Thread Daniel Vetter
On Thu, Oct 9, 2014 at 12:15 PM, Oded Gabbay wrote: > Well, I don't expect to reach 100 ioctls anytime soon, but I can tell > you that for the features we have in the pipeline, I can see the IOCTL > number go up to 20-30, just for the current H/W generation. So our Android folks seem to routinely

AMD GPU new API for new module

2014-10-09 Thread Oded Gabbay
On 09/10/14 11:02, Jerome Glisse wrote: > On Thu, Oct 09, 2014 at 09:54:14AM +0300, Oded Gabbay wrote: >> Hi Jerome, >> >> Do you think your proposed change should also be applied to amdkfd's >> IOCTLs ? > > It might make sense it really depends on the lifespan you expect for > amdkfd, do you ex

AMD GPU new API for new module

2014-10-09 Thread Christian König
Am 09.10.2014 um 09:54 schrieb Jerome Glisse: > On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote: >> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote: >>> So idea is simple, each ioctl would use some struct like : >>> >>> struct radeon_ioctl { >>> u32 version; >>>

AMD GPU new API for new module

2014-10-09 Thread Daniel Vetter
On Wed, Oct 8, 2014 at 6:00 PM, Jerome Glisse wrote: > > struct radeon_ioctl { > u32 version; > u32 size; > }; How is this any different from just another ioctl multiplexer and why can't we just add a new version if an ioctl needs to be revised? E.g. in i915 we've just add

AMD GPU new API for new module

2014-10-09 Thread Oded Gabbay
Hi Jerome, Do you think your proposed change should also be applied to amdkfd's IOCTLs ? Oded On 08/10/14 19:00, Jerome Glisse wrote: > Hi, > > So if i do not start the discussion now it might be already too late. Given > plan to converge open source driver and closed source driver to u

AMD GPU new API for new module

2014-10-09 Thread Rob Clark
On Thu, Oct 9, 2014 at 3:54 AM, Jerome Glisse wrote: > On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote: >> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote: >> > >> > So idea is simple, each ioctl would use some struct like : >> > >> > struct radeon_ioctl { >> > u32 vers

AMD GPU new API for new module

2014-10-09 Thread Jerome Glisse
On Thu, Oct 09, 2014 at 09:54:14AM +0300, Oded Gabbay wrote: > Hi Jerome, > > Do you think your proposed change should also be applied to amdkfd's > IOCTLs ? It might make sense it really depends on the lifespan you expect for amdkfd, do you expect that you will need substential API evolution dur

AMD GPU new API for new module

2014-10-09 Thread Jerome Glisse
On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote: > On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote: > > > > So idea is simple, each ioctl would use some struct like : > > > > struct radeon_ioctl { > > u32 version; > > u32 size; > > }; > > > fwiw, drm_ioctl(

AMD GPU new API for new module

2014-10-09 Thread Rob Clark
On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote: > > So idea is simple, each ioctl would use some struct like : > > struct radeon_ioctl { > u32 version; > u32 size; > }; fwiw, drm_ioctl() will do the right thing (zero-pad) for growing ioctls these days.. BR, -R

AMD GPU new API for new module

2014-10-08 Thread Christian König
Hi Jerome, yeah that's what we have already planned for the IOCTLs anyway. The main question currently is rather how we do the fence representation and synchronization between different engines. For fences I think we can agree to use 64bit values (maybe plus engine index) for internal represen

AMD GPU new API for new module

2014-10-08 Thread Jerome Glisse
Hi, So if i do not start the discussion now it might be already too late. Given plan to converge open source driver and closed source driver to use a single common kernel driver and that this would be a new kernel driver. This is an opportunity to fix some of the radeon design issues (at least thi