Re: RFC: Radeon multi ring support branch

["Christian König" <deathsimple@vodafone.de>]

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@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.