Hi,
So, I've built a generic LLVM tree for mesa and other projects and
installed it alongside SPIRV-LLVM-Translator into
$HOME/opt/llvm-dev-reldebug.
I have installed libclc there too, although it wouldn't build as part of
llvm and make install wouldn't install to the same llvm dir for some
Thanks everybody. The initial proposal is dead. Here are some thoughts on
how to do it differently.
I think we can have direct command submission from userspace via
memory-mapped queues ("user queues") without changing window systems.
The memory management doesn't have to use GPU page faults
On Mon, Apr 26, 2021 at 11:25:09AM -0500, Jason Ekstrand wrote:
> On Mon, Apr 26, 2021 at 10:31 AM Matthew Auld wrote:
> >
> > On 26/04/2021 16:11, Jason Ekstrand wrote:
> > > On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld
> > > wrote:
> > >>
> > >> Add an entry for the new uAPI needed for DG1.
On Mon, Apr 26, 2021 at 10:31 AM Matthew Auld wrote:
>
> On 26/04/2021 16:11, Jason Ekstrand wrote:
> > On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1. Also add the overall
> >> upstream plan, including some notes for the TTM
On 26/04/2021 16:11, Jason Ekstrand wrote:
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
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
On Wed, Apr 21, 2021 at 2:23 PM Daniel Vetter wrote:
>
> On Wed, Apr 21, 2021 at 8:28 PM Tvrtko Ursulin
> wrote:
> > On 21/04/2021 18:17, Jason Ekstrand wrote:
> > > On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
> > > wrote:
> > >> On 21/04/2021 14:54, Jason Ekstrand wrote:
> > >>> On Wed, Apr
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
>
> 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
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
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:
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):
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
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
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Thomas Hellström
Cc:
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.
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
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:
16 matches
Mail list logo
