On 2021-03-25 08:11:45, Jason Ekstrand wrote:
> On Thu, Mar 25, 2021 at 9:41 AM Rob Clark wrote:
> >
> > yeah, I meant to convert a repo w/ more MRs than 7 but less than mesa
> > using the script to beta test that, wasn't suggesting to do it by hand
>
> Plan is to convert piglit next. It's sitti
On Wed, Apr 28, 2021 at 04:39:24PM -0400, Alex Deucher wrote:
> On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote:
> >
> > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> > > Am 28.04.21 um 15:34 schrieb Daniel Vetter:
> > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christi
On Wed, Apr 28, 2021 at 04:45:01PM +0200, Christian König wrote:
> Am 28.04.21 um 16:34 schrieb Daniel Vetter:
> > On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> > > Am 28.04.21 um 15:34 schrieb Daniel Vetter:
> > > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wro
Treat it the same as the fake local-memory stuff, where it is disabled
for normal kernels, in case some random UMD is tempted to use this. Once
we have all the other bits and pieces in place, like the TTM conversion,
we can turn this on for real.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
C
All userspace objects must be cleared when allocating the backing store,
before they are potentially visible to userspace. For now use simple
CPU based clearing to do this for device local-memory objects, note that
in the near future this will instead use the blitter engine.
Signed-off-by: Matthe
For some internal device local-memory objects it would be useful to have
an option to CPU clear the pages upon gathering the backing store. Note
that this might be before the blitter is useable, which is the case for
some internal GuC objects.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc:
Add new extension to support setting an immutable-priority-list of
potential placements, at creation time.
If we use the normal gem_create or gem_create_ext without the
extensions/placements then we still get the old behaviour with only
placing the object in system memory.
v2(Daniel & Jason):
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases.
v2:(Chris)
- Use separate ioctl number for gem_create_ext, instead of hijacking
the existing gem_create ioctl, otherwise we run into the issue
with being unable to detect
With the upcoming gem_create_ext we want to be able create a "vanilla"
object upfront and pass that directly to the extensions, before actually
initialising the object. Functionally this should be the same expect we
now feed the object into the lower-level region specific init_object.
Signed-off-b
From: Abdiel Janulgue
Returns the available memory region areas supported by the HW.
v2(Daniel & Jason):
- Add some kernel-doc, including example usage.
- Drop all the extra rsvd
v3(Jason & Tvrtko)
- add back rsvd
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joon
In the next patch we want to expose the supported regions to userspace,
which can then be fed into the gem_create_ext placement extensions. For
now treat stolen memory as private from userspace pov.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc: Daniele Ceraolo Spurio
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
v3:
(D
> -Original Message-
> From: Auld, Matthew
> Sent: Monday, April 26, 2021 2:39 AM
> To: intel-...@lists.freedesktop.org
> Cc: Joonas Lahtinen ; Thomas Hellström
> ; Ceraolo Spurio, Daniele
> ; Lionel Landwerlin
> ; Bloomfield, Jon
> ; Justen, Jordan L ;
> Vetter, Daniel ; Kenneth Graunke
>
13 matches
Mail list logo
