current
location?
IMHO there is no reason not to have a special API to create small
amounts of GPU dedicated locked memory that cannot be moved off the
GPU.
For instance this paper:
http://www.ziti.uni-heidelberg.de/ziti/uploads/ce_group/2014-ASHESIPDPS.pdf
Considers usin
the special flag set on the PTE as well.. Feels weird
to have a special VMA without also having special PTEs?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Feb 04, 2021 at 06:16:27PM +0100, Daniel Vetter wrote:
> On Thu, Feb 4, 2021 at 5:13 PM Jason Gunthorpe wrote:
> > On Wed, Feb 03, 2021 at 10:19:48PM +0100, Daniel Vetter wrote:
> > > tldr; DMA buffers aren't normal memory, expecting that you can use
> > &
d much
> and the code is sometimes a maze (to me at least).
Yes, that makes sense. VM_PFNMAP and !VM_MIXEDMAP seems like the right
check after the VMA is populated
But how do you stuff special pfns into a VMA outside the fault
handler?
Jason
___
dri-d
On Thu, Feb 04, 2021 at 09:19:57PM +0100, Daniel Vetter wrote:
> On Thu, Feb 4, 2021 at 9:09 PM Jason Gunthorpe wrote:
> >
> > On Thu, Feb 04, 2021 at 08:59:59PM +0100, Daniel Vetter wrote:
> >
> > > So I think just checking for VM_PFNMAP after the vma is se
On Thu, Feb 04, 2021 at 10:50:51AM -0800, Jianxin Xiong wrote:
> Compilation of pyverbs/dmabuf_alloc.c depends on a few DRM headers
> that are installed by either the kernel-header or the libdrm package.
> The installation is optional and the location is not unique.
>
> The standard locations (suc
@@ -25,6 +23,18 @@ rdma_cython_module(pyverbs ""
>xrcd.pyx
> )
>
> +if (DRM_INCLUDE_DIRS)
> +rdma_cython_module(pyverbs ""
> + dmabuf.pyx
> + dmabuf_alloc.c
> +)
> +else()
> +rdma_cython_module(pyverbs ""
> + dmabuf.pyx
> + dmabuf_allo
r end up in there?
ZONE_DEVICE should already not be returned from GUP.
I've understood in the hmm casse the idea was a CPU touch of some
ZONE_DEVICE pages would trigger a migration to CPU memory, GUP would
want to follow the same logic, presumab
On Fri, Feb 05, 2021 at 04:53:04PM +0100, Daniel Vetter wrote:
> On Fri, Feb 05, 2021 at 11:43:19AM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 05, 2021 at 04:39:47PM +0100, Daniel Vetter wrote:
> >
> > > > And again, for slightly older hardware, without pinning to V
iers for the CPU page.
The fact the page is lost from the MM seems to be the main issue here.
> Yes, I would like to avoid the long term pin constraints as well if possible
> I
> just haven't found a solution yet. Are you suggesting it might be possible to
> add a callback in
s protection seems unsafe, ZONE_DEVICE is not so special
that the refcount means nothing
Is this a side effect of the extra refcounts that Ralph was trying to
get rid of? I'd rather see that work finished :)
Jason
___
dri-devel mailing list
dri-deve
ry, it
doesn't need to be special for atomics. In that case it can free the
CPU struct page completely as the data now lives in the ZONE_DEVICE
page so no need for a pin, no problem with movable
Jason
___
dri-devel mailing list
dri-devel@lists.freedeskto
On Wed, Feb 10, 2021 at 02:40:10PM +1100, Alistair Popple wrote:
> On Wednesday, 10 February 2021 12:39:32 AM AEDT Jason Gunthorpe wrote:
> > On Tue, Feb 09, 2021 at 12:07:14PM +1100, Alistair Popple wrote:
> > > Device private pages are used to represent device memory that is
is not the only path to get to a page.
I mean find out that the page is now owned by the GPU driver to tell
it that it needs to migrate that reference. Normally that would go
through the VMA to the mmu notifier, but with the page removed from
the normal VMA it can't get to a mmu notifier or the
e. Then
all the proper machinery will continue to work.
IMHO "migration" is the wrong idea if the data isn't actually moving.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
the hmm naming for new code (we should probably also kill
> it off for the existing code)?
Yes please, I'd prefer it if hmm.c was just the special page walker
and not a grab bag of unrelated things
Is there is a more natural place to put this in the mm for this idea?
Jason
__
;vm_flags &
VM_SHARED))
During mmap to reject use of MAP_PRIVATE on BAR pages.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
k(&pvmw)) {
> + /*
> + * If the page is mlock()d, we cannot swap it out.
> + * If it's recently referenced (perhaps page_referenced
> + * skipped over this mm) then we should reactivate it.
> +
e is locked
> - */
> - BUG_ON(!PageLocked(compound_head(p)));
> - return p;
And this constraint has been completely lost?
A comment in front of the is_special_entry explaining all the rule
would help alot
Transformation looks fine otherwise
Jason
_
nged, 100 insertions(+), 62 deletions(-)
Reviewed-by: Jason Gunthorpe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ve been called the device will no longer have exclusive
> access to the region.
This makes alot more sense than the prior versions!
I don't know the migration area especially well, but nothing caught my
eye in here
Jason
___
dri-dev
ols/testing/selftests/vm/hmm-tests.c | 219 +
> 3 files changed, 345 insertions(+)
Please get Ralph to review this, otherwise:
Acked-by: Jason Gunthorpe
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
}
> +
> + if (!try_to_protect(pages[i])) {
Isn't this racy? get_user_pages returns the ptes at an instant in
time, they could have already been changed to something else?
I would think you'd want to switch to the swap entry atomically under
th
g the HW to use the
pages, nothing else.
> However try_to_protect() scans the PTEs again under the PTL so checking the
> mapping of interest actually gets replaced during the rmap walk seems like a
> reasonable solution. Thanks for the comments.
It does seem cleaner if you can manage it, the
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
since that commit, we've been having issues where a hang in one client
can propagate to another. In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.
Signed-off-by:
gt; -{
> - return init_pseudo(fc, PPC_CMM_MAGIC) ? 0 : -ENOMEM;
Should we clean these unusued magic constants too?
include/uapi/linux/magic.h:#define PPC_CMM_MAGIC0xc7571590
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
py for RDMA and Alex will need one for vfio..
Thanks,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
X11 has always used execbuffer2.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 100 --
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h| 2 -
drivers/gpu/drm/i915/i915_drv.c | 2 +-
3 files changed, 1 insertion(+), 103 deletions
memory is directly CPU-accessible
carries significant advantages.
Signed-off-by: Jason Ekstrand
Cc: Dave Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ex
memory is directly CPU-accessible
carries significant advantages.
v2 (Jason Ekstrand):
- Allow TGL-LP platforms as they've already shipped
v3 (Jason Ekstrand):
- WARN_ON platforms with LMEM support in case the check is wrong
Signed-off-by: Jason Ekstrand
Cc: Dave Airlie
Cc: Daniel Vetter
-
+Zbigniew for review
On Wed, Mar 10, 2021 at 3:50 PM Jason Ekstrand wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do. On the O
On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
wrote:
>
> On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of i915 that supports at least softpin wh
On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter wrote:
>
> On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand wrote:
> >
> > On Thu, Mar 11, 2021 at 5:44 AM Zbigniew Kempczyński
> > wrote:
> > >
> > > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstran
all memory is
directly CPU-accessible carries significant advantages.
v2 (Jason Ekstrand):
- Allow TGL-LP platforms as they've already shipped
v3 (Jason Ekstrand):
- WARN_ON platforms with LMEM support in case the check is wrong
v4 (Jason Ekstrand):
- Call out Rocket Lake in the commit mess
On Thu, Mar 11, 2021 at 10:31 AM Chris Wilson wrote:
>
> Quoting Zbigniew Kempczyński (2021-03-11 11:44:32)
> > On Wed, Mar 10, 2021 at 03:50:07PM -0600, Jason Ekstrand wrote:
> > > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > > it'
7; access)
> > * Shared ('read' access)
> > * No fence - ensures the BO is mapped, but doesn't add any implicit
> > fences.
> >
> > The last may make sense when doing explicit fences and e.g. doing
> > front-buffer rendering with a display driver whi
On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
wrote:
>
> On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ekstrand wrote:
> > On Thu, Mar 11, 2021 at 9:57 AM Daniel Vetter wrote:
> > >
> > > On Thu, Mar 11, 2021 at 4:50 PM Jason Ekstrand
> > > wrot
On Thu, Mar 11, 2021 at 11:25 AM Boris Brezillon
wrote:
>
> Hi Jason,
>
> On Thu, 11 Mar 2021 10:58:46 -0600
> Jason Ekstrand wrote:
>
> > Hi all,
> >
> > Dropping in where I may or may not be wanted to feel free to ignore. : -)
>
> I'm glad you d
On Thu, Mar 11, 2021 at 12:20 PM Zbigniew Kempczyński
wrote:
>
> On Thu, Mar 11, 2021 at 11:18:11AM -0600, Jason Ekstrand wrote:
> > On Thu, Mar 11, 2021 at 10:51 AM Zbigniew Kempczyński
> > wrote:
> > >
> > > On Thu, Mar 11, 2021 at 10:24:38AM -0600, Jason Ek
On March 11, 2021 20:26:06 "Dixit, Ashutosh" wrote:
On Wed, 10 Mar 2021 13:00:49 -0800, Jason Ekstrand wrote:
libdrm has supported the newer execbuffer2 ioctl and using it by default
when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
which landed Mar 2,
ich
might allocate memory. I don't even think there's a way userspace can
trust itself there. It also blows up my plan of moving the fences to
transition boundaries.
Not sure where that leaves us.
--Jason
On Mon, May 3, 2021 at 9:42 AM Alex Deucher wrote:
>
> On Sat, May 1, 2021
On Mon, May 3, 2021 at 10:03 AM Christian König
wrote:
>
> Am 03.05.21 um 16:59 schrieb Jason Ekstrand:
> > Sorry for the top-post but there's no good thing to reply to here...
> >
> > One of the things pointed out to me recently by Daniel Vetter that I
> > did
On Mon, May 3, 2021 at 10:16 AM Bas Nieuwenhuizen
wrote:
>
> On Mon, May 3, 2021 at 5:00 PM Jason Ekstrand wrote:
> >
> > Sorry for the top-post but there's no good thing to reply to here...
> >
> > One of the things pointed out to me recently by Daniel Vetter
xt.
3. Get rid of the separation between context close and context destroy
4. Get rid of the RCU on i915_gem_context
However, these should probably be done as a separate patch series as this
one is already starting to get longish, especially if you consider the 89
IGT patches that go along w
really care
about solving this problem, they can do it properly.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 85 +--
drivers/gpu/drm/i915/gt/intel_conte
patch adds a new ring_size field and makes everything use
that.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
drivers/gpu/drm/i915/gt/intel_context.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 5 -
drivers/gpu/drm/i915/gt
ml
[2]: https://lists.freedesktop.org/archives/intel-gfx/2015-May/067031.html
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++--
.../gpu/drm/i915/gem/i915_gem_context_types.h| 1 -
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
e races setting request_timeout_ms and context creation, they
can theoretically end up with different timeouts. However, since both
of these are fairly harmless and require changing kernel params, we
don't care.
v2 (Tvrtko Ursulin):
- Add a comment about races with request_timeout_ms
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff
imeline, they can
use a syncobj and set it as an in and out fence on every submit.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 199 +-
.../drm/i915/gt/intel_execlists_submission.c | 28 ---
.../drm/i915/gt/intel_execlists_
text::syncobj to mention that it's
an emulation and the possible race if userspace calls execbuffer2
twice on the same context concurrently.
v2 (Jason Ekstrand):
- Wrap the checks for eb.gem_context->syncobj in unlikely()
- Drop the dma_fence reference
- Improved commit message
v3
data so it's not useful for discovering what engines
are in the context. It's also not a replacement for the recently
removed I915_CONTEXT_CLONE_ENGINES because it doesn't return any of the
balancing or bonding information.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
-
he bonding information.
v2 (Jason Ekstrand):
- Don't delete quite as much code.
v3 (Tvrtko Ursulin):
- Add some history to the commit message
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 18 +-
.../drm/i915/gt/intel_execlists_submission.c | 69 --
such that they can run in parallel.
However, this functionality has never been used in the real world. The
media driver (the only user of FENCE_SUBMIT) always picks exactly two
physical engines to bond and never asks us to pick which to use.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42 ---
drivers/gpu/drm/i915
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dr
hey can use set CONTEXT_PARAM_RECOVERABLE to false and look for -EIO
coming from execbuf to check for hangs instead.
v2 (Daniel Vetter):
- Add a comment in the commit message about recoverable contexts
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43 ---
2 fil
round this wart, this
commit adds a proto-context struct which contains all the context create
parameters.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 145 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 22 +++
.../gpu/drm/i915/gem
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
.../gpu/drm/i915/gem/selftests
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
dr
per-client
stats from debugfs/i915_gem_objects")
v2 (Daniel Vetter):
- Delete a struct drm_i915_file_private pre-declaration
- Add a comment to the commit message about history
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 9
ork properly, everything which ever touches
a proto-context is guarded by drm_i915_file_private::proto_context_lock,
including context creation. Yes, this means context creation now takes
a giant global lock but it can't really be helped and that should never
be on any driver's fast-pat
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 267 --
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 119
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
4 files changed
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 304
1 file changed, 304 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ad6e98d8a4fbd..6e5828fe1a792 100644
--- a
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
.../gpu/drm/i915/gem/selftests
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 +-
1 file changed
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us get rid of the complex VM setting code.
Signed-off-by: Jason
is might be different than drivers/gpu.
AFAIK drives/gpu has a lot wider userspace, rdma manages this OK
because we only have one library package that provides the user/kernel
interface.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
> After all when one frame is completed they want to immediately start
>> >>>> rendering the next one.
>> >>> Sure, for the true userspace direct submit model. But with that you don't
>> >>> get dma-fence, which means this gpu will not work fo
users run with enable_guc=3,
as can be seen on Google[2]).
The IGT changes, as I understand them, are entirely around switching to the
new parallel submit API. There shouldn't be a major effect to most users.
--Jason
full without doing a thorough
audit of the surrounding code, though. I'll try to get to that next week if
Daniel doesn't beat me to it. Thanks for working on this!
--Jason
It sounds a plausible argument that fence propagation could be useful in
which case a core flag to enable o
e should delete all the v4l stuff.
Daniel I suppose we missed this relation to follow_pte(), so I agree
that keeping a unsafe_follow_pfn() around is not good.
Regards,
Jason
r free bug is somewhat
harder, exploiting the 'you can write to non-page write protected
memory' bug is not so hard.
Jason
On May 10, 2021 08:55:55 Martin Peres wrote:
On 10/05/2021 02:11, Jason Ekstrand wrote:
On May 9, 2021 12:12:36 Martin Peres wrote:
Hi,
On 06/05/2021 22:13, Matthew Brost wrote:
Basic GuC submission support. This is the first bullet point in the
upstreaming plan covered in the following
bly be re-architected to use drm/scheduler
for dma_fence and look a lot more like GuC on the inside.
The point of bringing this up is that I'm seeing a lot more execlist
love than I think it deserves. :-) It may be free software but that
doesn't mean it's good software. :-P To be clear, I don't mean to
unduly insult Chris or any of the other people who have worked on it.
It works and it's perfectly functional for supporting all the good ol'
use-cases us desktop Linux people are used to. But the ways in which
it would have to change in order to handle the future are substantial.
--Jason
eve this is also being worked on but I don't know when is the
> expected delivery.
>
> If we are tracking a TODO list of items somewhere I think these ones
> should be definitely considered.
Yup, let's get it all in the ToDo and not flip GuC on by default in
the wild until it's all checked off.
--Jason
On Tue, May 4, 2021 at 3:47 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:23AM -0500, Jason Ekstrand wrote:
> > Previously, we were storing the ring size in the ring pointer before it
> > was actually allocated. We would then guard setting the ring size o
On Tue, May 4, 2021 at 3:50 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:27AM -0500, Jason Ekstrand wrote:
> > This API allows one context to grab bits out of another context upon
> > creation. It can be used as a short-cut for setparam(getparam()) f
On Tue, May 4, 2021 at 3:56 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:31AM -0500, Jason Ekstrand wrote:
> > Even though FENCE_SUBMIT is only documented to wait until the request in
> > the in-fence starts instead of waiting until it completes, it has a bit
> &
On Tue, May 4, 2021 at 11:17 AM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:38AM -0500, Jason Ekstrand wrote:
> > Since free_engines works for partially constructed engine sets, we can
> > use the usual goto pattern.
> >
> > Signed-off-by: Jason Ekstrand
On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
>
> On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > This means that the proto-context needs to grow support for engine
> > configuration information as well as setparam logic. Fortunately, we'll
&
On Mon, May 17, 2021 at 8:40 AM Daniel Vetter wrote:
>
> On Fri, May 14, 2021 at 02:13:57PM -0500, Jason Ekstrand wrote:
> > On Tue, May 4, 2021 at 3:33 PM Daniel Vetter wrote:
> > >
> > > On Mon, May 03, 2021 at 10:57:40AM -0500, Jason Ekstrand wrote:
> > &
it's worth trying to get around that for now.
> > I915 and iirc msm has explicit flags for this, panfrost was designed to
> > support this correctly from the start (also with flags I think). That's at
> > least what I remember from all the discussions at XDC and #dri-de
t; > >> synchronization.
> > > So the way this is fixed in every other vulkan driver is that vulkan
> > > userspace sets flags in the CS ioctl when it wants to synchronize with
> > > implicit sync. This gets you mostly there. Last time I checked amdgpu
> > &g
grate back to a CPU page and write protect it
- Copy to a new device exclusive page
Jason
king about
It is just a page and it is tied to some specific pgmap?
If the thing providing the migration stuff goes away then all
device_exclusive pages should revert back to CPU pages and destroy the
pgmap?
Jason
On Tue, May 18, 2021 at 4:17 PM Daniel Vetter wrote:
>
> On Tue, May 18, 2021 at 7:40 PM Christian König
> wrote:
> >
> > Am 18.05.21 um 18:48 schrieb Daniel Vetter:
> > > On Tue, May 18, 2021 at 2:49 PM Christian König
> > > wrote:
> > >> Hi
On Tue, May 18, 2021 at 04:29:14PM -0400, Peter Xu wrote:
> On Tue, May 18, 2021 at 04:45:09PM -0300, Jason Gunthorpe wrote:
> > On Tue, May 18, 2021 at 02:01:36PM -0400, Peter Xu wrote:
> > > > > Indeed it'll be odd for a COW page since for COW page then it means
>
On Tue, May 18, 2021 at 07:45:05PM -0400, Peter Xu wrote:
> On Tue, May 18, 2021 at 08:03:27PM -0300, Jason Gunthorpe wrote:
> > Logically during fork all these device exclusive pages should be
> > reverted back to their CPU pages, write protected and the CPU page PTE
> &g
ketchy at
best and can be weaponized to attack other things so it's not really a
good design. This commit restores a bit of the Gen7 functionality on
Gen9 (smashing the start of the shadow batch to MI_BB_END) so that
it's always safe to run the batch post-parser. A later commit will
get
Once we no longer rely on error propagation, I think there's a lot we
can rip out.
--Jason
On Wed, May 19, 2021 at 5:15 AM Daniel Vetter wrote:
>
> From: Jason Ekstrand
>
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've b
On Wed, May 19, 2021 at 5:52 AM Michel Dänzer wrote:
>
> On 2021-05-19 12:06 a.m., Jason Ekstrand wrote:
> > On Tue, May 18, 2021 at 4:17 PM Daniel Vetter wrote:
> >>
> >> On Tue, May 18, 2021 at 7:40 PM Christian König
> >> wrote:
> >>&g
On Wed, May 19, 2021 at 6:43 AM Christian König
wrote:
>
> Am 19.05.21 um 00:06 schrieb Jason Ekstrand:
> > [SNIP]
> >>> E.g. we can't add a fence which doesn't wait for the exclusive one as
> >>> shared.
> >> Ok I think that's a re
> Sorry for the noise.
Not at all, it is good that more people understand things!
Jason
On May 19, 2021 12:16:15 Daniel Vetter wrote:
On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand wrote:
Once we no longer rely on error propagation, I think there's a lot we
can rip out.
I honestly did not find that much ... what did you uncover?
When I was digging through this ea
On Thu, May 20, 2021 at 9:18 AM Daniel Vetter wrote:
>
> On Thu, May 20, 2021 at 10:13:38AM +0200, Michel Dänzer wrote:
> > On 2021-05-20 9:55 a.m., Daniel Vetter wrote:
> > > On Wed, May 19, 2021 at 5:48 PM Michel Dänzer wrote:
> > >>
> > >>
401 - 500 of 3569 matches
Mail list logo
