From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: RFC: Radeon multi ring support branch Date: Wed, 02 Nov 2011 11:12:42 +0100 Message-ID: <4EB1179A.9050109@vodafone.de> References: <4EABF8EC.3020701@vodafone.de> <20111031150538.GA3036@homer.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id A43F69E7B6 for ; Wed, 2 Nov 2011 03:12:47 -0700 (PDT) In-Reply-To: <20111031150538.GA3036@homer.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Jerome Glisse Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 31.10.2011 16:05, Jerome Glisse wrote: > On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian K=F6nig 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 > > 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.