RFC: Radeon multi ring support branch

[Jerome Glisse]

On Wed, Nov 02, 2011 at 11:12:42AM +0100, Christian König wrote:
> On 31.10.2011 16:05, Jerome Glisse wrote:
> >On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian König wrote:
> >>Hello everybody,
> >>
> >>to support multiple compute rings, async DMA engines and UVD we need
> >>to teach the radeon kernel module how to sync buffers between
> >>different rings and make some changes to the command submission
> >>ioctls.
> >>
> >>Since we can't release any documentation about async DMA or UVD
> >>(yet), my current branch concentrates on getting the additional
> >>compute rings on cayman running. Unfortunately those rings have
> >>hardware bugs that can't be worked around, so they are actually not
> >>very useful in a production environment, but they should do quite
> >>well for this testing purpose.
> >>
> >>The branch can be found here:
> >>http://cgit.freedesktop.org/~deathsimple/linux/log/
> >>
> >>Since some of the patches are quite intrusive, constantly rebaseing
> >>them could get a bit painful. So I would like to see most of the
> >>stuff included into drm-next, even if we don't make use of the new
> >>functionality right now.
> >>
> >>Comments welcome,
> >>Christian.
> >So for all patches except the interface change see below
> >Reviewed-by: Jerome Glisse<jglisse at redhat.com>
> >
> >For the interface change, as discussed previously, i believe prio
> >should be a userspace argument, kernel could override it.
> >
> >
> Yeah, I'm still not sure what we should do about the priority.
> 
> Say for example we have 2 processes. Process A is sending compute
> jobs both with high and low priority, while process B is sending
> jobs with only high priority. Unfortunately the jobs send by B
> doesn't utilizes the hardware to its limits, so that even jobs on a
> lower priority rings get their share of the compute resources.
> 
> The effect is that it reverses the priority A wants for its jobs.
> The high priority jobs of A get executed much slower than the low
> priority jobs of A, because B is spamming the hight priority ring
> with its under utilizing jobs.
> 
> In such a situation it would be better to adjust the job scheduling
> a bit so that jobs of process A gets on ring 1 on jobs from B get on
> ring 2, but I have now idea how to detect such a situation. Anyway,
> the primary goal of the different compute rings is to separate
> compute from GFX so that even with big compute jobs running the
> system still stays responsible to user input, so I think adding a
> better scheduling for compute jobs can be done much later.
> 
> Christian.

I think this was already pointed out, my idea was to have the prio
argument in ioctl and have kernel override it. For instance i was
thinking the drm master could set for each process what is the
top priority this process can get, so which ever process is drm
master would choose. Or we could do some kind of userspace daemon
that would have special right from kernel/drm pov and would be
able to set the max priority each process get on the gpu.

But as a first step just getting the prio as an argument sounds
what we should do as right now we won't be doing anykind of
real GPU scheduling.

Cheers,
Jerome