linux-kernel - RE: [PATCH 02/83] drm/radeon: reduce number of free VMIDs and pipes in KV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <D89D60253BB73A4E8C62F9FD18A939CA01031F22@storexdag02.amd.com>
Date:	Fri, 11 Jul 2014 22:54:31 +0000
From:	"Bridgman, John" <John.Bridgman@....com>
To:	Ilyes Gouta <ilyes.gouta@...il.com>
CC:	Alex Deucher <alexdeucher@...il.com>,
	"Koenig, Christian" <Christian.Koenig@....com>,
	Oded Gabbay <oded.gabbay@...il.com>,
	"Deucher, Alexander" <Alexander.Deucher@....com>,
	"Lewycky, Andrew" <Andrew.Lewycky@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Maling list - DRI developers" <dri-devel@...ts.freedesktop.org>
Subject: RE: [PATCH 02/83] drm/radeon: reduce number of free VMIDs and pipes
 in KV

>From: Ilyes Gouta [mailto:ilyes.gouta@...il.com] 
>Sent: Friday, July 11, 2014 2:00 PM
>To: Bridgman, John
>Cc: Alex Deucher; Koenig, Christian; Oded Gabbay; Deucher, Alexander; Lewycky, Andrew; LKML; Maling list - DRI developers
>Subject: Re: [PATCH 02/83] drm/radeon: reduce number of free VMIDs and pipes in KV
>
>Hi,
>
>Just a side question (for information),
>
>On Fri, Jul 11, 2014 at 6:07 PM, Bridgman, John <John.Bridgman@....com> wrote:
>
>Right. The SET_RESOURCES packet (kfd_pm4_headers.h, added in patch 49) allocates a range of HW queues, VMIDs and GDS to the HW scheduler, then >the scheduler uses the allocated VMIDs to support a potentially larger number of user processes by dynamically mapping PASIDs to VMIDs and memory >queue descriptors (MQDs) to HW queues.
>
>Are there any documentation/specifications online describing these mechanisms?

Nothing yet, but we should write some docco for this similar to what was written for the gfx blocks. I'll add that to the list, thanks.