RFC: Radeon multi ring support branch
deathsimple at vodafone.de
Wed Nov 2 03:12:42 PDT 2011
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
>> 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:
>> 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,
> 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
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.
More information about the dri-devel