On Fri, Oct 25, 2019 at 4:29 PM Chris Wilson
wrote:
> Quoting Jason Ekstrand (2019-10-25 19:22:04)
> > On Thu, Oct 24, 2019 at 6:40 AM Chris Wilson
> wrote:
> >
> > Our existing behaviour is to allow contexts and their GPU requests to
> > persist past
using the magic side-channel this provides.
>
> This would totally break a lot of the igts, but they're already broken
> for the same reasons as userspace on gen12 would be.
>
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Chris Wilson
> Cc: Lucas De Marchi
>
On Fri, Dec 13, 2019 at 4:07 PM Niranjana Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> Shared Virtual Memory (SVM) runtime allocator support allows
> binding a shared virtual address to a buffer object (BO) in the
> device page table through an ioctl call.
>
> Cc: Joonas Lahtine
On Fri, Dec 13, 2019 at 5:24 PM Niranjan Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> On Fri, Dec 13, 2019 at 04:58:42PM -0600, Jason Ekstrand wrote:
> >
> > +/**
> > + * struct drm_i915_gem_vm_bind
> > + *
> >
On Sun, Dec 15, 2019 at 10:24 PM Niranjan Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> On Sat, Dec 14, 2019 at 10:31:37AM +, Chris Wilson wrote:
> >Quoting Jason Ekstrand (2019-12-14 00:36:19)
> >> On Fri, Dec 13, 2019 at 5:24 PM
Just to be clear, is this just adding a CLFLUSH or is it actually changing
the default caching state of buffers from CACHED to NONE? If it's actually
changing the default state, that's going to break userspace badly.
--Jason
On Fri, Jul 19, 2019 at 5:21 AM Chris Wilson
wrote:
> Quoting Lionel
This is consistent with what the Windows driver does and what I've heard
from HW people.
Reviewed-by: Jason Ekstrand
On Thu, Aug 8, 2019 at 11:36 AM Chris Wilson
wrote:
> This bit was fliped on for "syncing dependencies between camera and
> graphics". BSpec has no recoll
Note: This doesn't actually fix 110998. I can still get a hard-hang with a
slightly different version of the reproducer example. However, it does fix
the original and I suspect it will fix the UE4 editor hang in 110228
On Thu, Aug 8, 2019 at 12:30 PM Jason Ekstrand wrote:
> This is co
Also, I think we can provide a better commit message. I'll type something
in the morning when I can actually look stuff up and provide correct
references.
On August 8, 2019 12:33:15 Jason Ekstrand wrote:
Note: This doesn't actually fix 110998. I can still get a hard-hang with a
getting pulled into the sampler cache. If the
over-fetch from the sampler on a BUFFER surface leaks over into an atomic
on the L3$, hangs can occur.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110228
On Thu, Aug 8, 2019 at 11:35 PM Jason Ekstrand wrote:
> Also, I think we can provid
On Wed, Aug 21, 2019 at 8:12 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Introduces a new parameters to execbuf so that we can specify syncobj
> handles as well as timeline points.
>
> v2: Reuse i915_user_extension_fn
>
> v3: Check that the chained extension is only present once
Acked-by: Jason Ekstrand
On Wed, Aug 21, 2019 at 10:20 AM Daniel Vetter
wrote:
> On Wed, Aug 21, 2019 at 3:55 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Aug 20, 2019 at 01:57:44PM -0700, Daniele Ceraolo Spurio wrote:
> > >
> > >
> > > On 8/20/19 1
Bump? Has this been landed or looked at beyond my review?
On Wed, Aug 14, 2019 at 1:40 PM Jason Ekstrand wrote:
> I was going to ask the status of this and then I looked and realized that
> I never provided a commit message blrub. Oops. Here you go:
>
> On Broadwell, the sampler
; >
> > Suggested-by: Ville Syrjälä
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707
> > Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS")
> > Signed-off-by: Chris Wilson
> > Cc: Ville Syrjälä
> > Cc: Jason Ekstrand
I double-checked and Vulkan doesn't do/allow this.
Acked-by: Jason Ekstrand
On Thu, Jan 28, 2021 at 10:26 AM Maarten Lankhorst
wrote:
>
> It doesn't make sense to export a memory address, we will prevent
> allowing access this way to different address spaces when we
> r
g
> piglit's opencl tests.
Did you test against mesa at all?
>
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Thomas Hellström
> Cc: Jason Ekstrand
>
> -- Still needs an ack from relevant userspace that it won't break, but should
> be good.
> ---
> dr
We've never used this bit in mesa.
Acked-by: Jason Ekstrand
On Thu, Jan 28, 2021 at 10:26 AM Maarten Lankhorst
wrote:
>
> We should not allow this any more, as it will break with the new userptr
> implementation, it could still be made to work, but there's no
On January 29, 2021 05:42:47 Maarten Lankhorst
wrote:
Op 28-01-2021 om 17:47 schreef Jason Ekstrand:
On Thu, Jan 28, 2021 at 10:26 AM Maarten Lankhorst
wrote:
There are a couple of ioctl's related to tiling and cache placement,
that make no sense for userptr, reject
erf hit to atomics sucks but, fortunately, most games don't use
them heavily enough for it to make a significant impact. We should
just eat the perf hit and fix the hangs.
Reviewed-by: Jason Ekstrand
--Jason
On Wed, Jul 24, 2019 at 3:02 PM Francisco Jerez wrote:
>
> Chris Wilson
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:
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
On Fri, Jan 22, 2021 at 4:40 PM Ashutosh Dixit wrote:
>
> The guidance for i915 at this time is to start phasing out pread/pwrite
> ioctl's, the rationale being (a) the functionality can be done entirely in
> userspace with a combination of mmap + memcpy, and (b) no existing user
> mode clients ac
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
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'
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
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 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
removed [1] so
expecting them to drop it going forward is reasonable.
IGT changes which handle this kernel change have also been submitted [2].
[1] https://github.com/intel/media-driver/pull/1160
[2] https://patchwork.freedesktop.org/series/81384/
v2 (Jason Ekstrand):
- Improved commit messa
e and they're easily removed [1] so
expecting them to drop it going forward is reasonable.
IGT changes which handle this kernel change have also been submitted [2].
[1] https://github.com/intel/media-driver/pull/1160
[2] https://patchwork.freedesktop.org/series/81384/
v2 (Jason Ekstrand):
First off, I'm just here asking questions right now trying to start
getting my head around some of this stuff. Feel free to ignore me or
tell me to go away if I'm being annoying. :-)
On Thu, Mar 11, 2021 at 7:49 AM Maarten Lankhorst
wrote:
>
> Instead of sharing pages with breadcrumbs, give each
On Thu, Mar 11, 2021 at 7:49 AM Maarten Lankhorst
wrote:
>
> We're starting to require the reservation lock for pinning,
> so wait until we have that.
>
> Update the selftests to handle this correctly, and ensure pin is
> called in live_hwsp_rollover_user() and mock_hwsp_freelist().
>
> Changes si
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,
On Fri, Mar 12, 2021 at 6:17 AM Matthew Auld
wrote:
>
> On Fri, 12 Mar 2021 at 11:47, Tvrtko Ursulin
> wrote:
> >
> >
> > On 12/03/2021 10:56, Matthew Auld wrote:
> > > On Fri, 12 Mar 2021 at 09:50, Tvrtko Ursulin
> > > wrote:
> > >>
pread/pwrite ioctl's for future platforms (v3)
Jason Ekstrand (2):
drm/i915/gem: Drop legacy execbuffer support (v2)
drm/i915/gem: Drop relocation support on all new hardware (v5)
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 113 ++
drivers/gpu/drm/i915/gem/i915_gem_ioctls.
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 message
.
v2 (Jason Ekstrand):
- Add a comment saying what Linux version it's being removed in.
Signed-off-by: Jason Ekstrand
Acked-by: Keith Packard
Acked-by: Dave Airlie
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 100 --
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
e and they're easily removed [1] so
expecting them to drop it going forward is reasonable.
IGT changes which handle this kernel change have also been submitted [2].
[1] https://github.com/intel/media-driver/pull/1160
[2] https://patchwork.freedesktop.org/series/81384/
v2 (Jason Ekstrand):
On Wed, Mar 17, 2021 at 2:55 AM Petri Latvala wrote:
>
> On Mon, Mar 15, 2021 at 10:29:20PM -0700, Ashutosh Dixit wrote:
> > From: Jason Ekstrand
> >
> > The Vulkan driver in Mesa for Intel hardware never uses relocations if
> > it's running on a version of
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 message
I should probably have said that the reviews are on v5 and it's very
different in v6 so they should probably be considered dropped until
re-confirmed.
On Wed, Mar 17, 2021 at 9:39 AM Jason Ekstrand wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
>
in i915
in the first place.
Test-with: 20210121083742.46592-1-ashutosh.di...@intel.com
Cc: Daniel Vetter
Cc: Dave Airlie
Ashutosh Dixit (1):
drm/i915: Disable pread/pwrite ioctl's for future platforms (v3)
Jason Ekstrand (4):
drm/i915/gem: Drop legacy execbuffer support (v2)
drm
.
v2 (Jason Ekstrand):
- Add a comment saying what Linux version it's being removed in.
Signed-off-by: Jason Ekstrand
Acked-by: Keith Packard
Acked-by: Dave Airlie
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 100 --
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h
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 message
e and they're easily removed [1] so
expecting them to drop it going forward is reasonable.
IGT changes which handle this kernel change have also been submitted [2].
[1] https://github.com/intel/media-driver/pull/1160
[2] https://patchwork.freedesktop.org/series/81384/
v2 (Jason Ekstrand):
This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
has never been used by any real userspace.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 94 ++-
drivers/gpu/drm/i915
It's never been used by any real userspace. It's used by IGT as a
short-cut for sharing VMs and other stuff between contexts.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 217 +---
include/uapi/drm/
-with: 20210319223233.2982842-1-ja...@jlekstrand.net
Jason Ekstrand (4):
drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP
drm/i915: Drop the CONTEXT_CLONE API
drm/i915: Implement SINGLE_TIMELINE with a syncobj
drivers/gpu/drm/i915/Mak
This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
has never been used by any real userspace.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 112 ++
drivers/gpu/drm
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
t, together with deleting
the CLONE_CONTEXT API, we should now have a 1:1 mapping between
intel_context and intel_timeline which should make some of our locking
mess a bit easier.
Signed-off-by: Jason Ekstrand
Cc: Maarten Lankhorst
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gem/
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 +---
include/uapi/drm/i915_drm.h | 16 +-
2 files changed, 6 insertions
On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand wrote:
>
> This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
> has never been used by any real userspace.
After further digging, there is a compute-runtime PR for this. I
still think we should drop it and I'
On Mon, Mar 22, 2021 at 5:52 AM Matthew Auld
wrote:
>
> On Sat, 20 Mar 2021 at 14:48, Jason Ekstrand wrote:
> >
> > On Fri, Mar 19, 2021 at 5:39 PM Jason Ekstrand wrote:
> > >
> > > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
&
On Mon, Mar 22, 2021 at 7:01 AM Jani Nikula wrote:
>
> On Sat, 20 Mar 2021, Jason Ekstrand wrote:
> > This reverts commit 88be76cdafc7e60e2e4ed883bfe7e8dd7f35fa3a. This API
>
> Small nit, I think it would be useful to reference commits with the
> citation style:
>
&
On Mon, Mar 22, 2021 at 7:28 AM Tvrtko Ursulin
wrote:
>
>
> On 19/03/2021 22:38, Jason Ekstrand wrote:
> > I'd love to delete the SINGLE_TIMELINE API because it leaks an
> > implementation detail of contexts through to the API and is something
> > that us
On Mon, Mar 22, 2021 at 6:55 AM Jani Nikula wrote:
>
> On Fri, 19 Mar 2021, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: uAPI clean-ups part 2
> > URL : https://patchwork.freedesktop.org/series/88196/
> > State : failure
> >
> > == Summary ==
> >
> > Applying: drm/i915: D
gt;>> On Mon, Mar 22, 2021 at 11:22:01AM +0000, Tvrtko Ursulin wrote:
> >>>>
> >>>> On 19/03/2021 22:38, Jason Ekstrand wrote:
> >>>>> This API allows one context to grab bits out of another context upon
> >>>>> creation. It can
On Mon, Mar 22, 2021 at 11:59 AM Daniel Vetter wrote:
>
> On Fri, Mar 19, 2021 at 05:38:56PM -0500, Jason Ekstrand wrote:
> > I'd love to delete the SINGLE_TIMELINE API because it leaks an
> > implementation detail of contexts through to the API and is something
> >
Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory. Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.
Signed-off-by:
On Thu, May 7, 2020 at 10:44 AM Chris Wilson wrote:
>
> Quoting Jason Ekstrand (2020-05-07 16:36:00)
> > 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 version
This matches my understanding for what it's worth. In my little bit
of synchronization work in drm, I've gone out of my way to ensure we
can maintain this constraint.
Acked-by: Jason Ekstrand
On Thu, Jul 9, 2020 at 7:33 AM Daniel Vetter wrote:
>
> Comes up every few year
First off, I think you all did a fantastic job. I felt that things
ran very smoothly and, as far as the talks themselves go, I think it
went almost as smoothly as an in-person XDC. I'm really quite
impressed. I do have a couple pieces of more nuanced feedback:
1. I think we were maybe a bit to
On Fri, Feb 28, 2020 at 11:00 AM Rob Clark wrote:
>
> On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote:
> >
> > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
> > >
> > > We could also do stuff like reducing the amount of tests we run on each
> > > commit, and punt some testing to a per-weeke
On Sat, Feb 29, 2020 at 3:47 PM Timur Kristóf wrote:
>
> On Sat, 2020-02-29 at 14:46 -0500, Nicolas Dufresne wrote:
> > >
> > > 1. I think we should completely disable running the CI on MRs which
> > > are
> > > marked WIP. Speaking from personal experience, I usually make a lot
> > > of
> > > cha
I don't think we need to worry so much about the cost of CI that we need to
micro-optimize to to get the minimal number of CI runs. We especially
shouldn't if it begins to impact coffee quality, people's ability to merge
patches in a timely manner, or visibility into what went wrong when CI
fai
hort order.
Again, sorry I was so terse. I was just trying to slow the panic.
> Le dimanche 01 mars 2020 à 14:18 -0600, Jason Ekstrand a écrit :
> > I've seen a number of suggestions which will do one or both of those things
> > including:
> >
> > - Batching m
FYI: For compute shaders, we have a bit in INTERFACE_DESCRIPTOR_DATA
for this which we can set from userspace without whitelisting a
register. If drivers can't handle mid-thread, they should just set
that bit. Unless we can mid-thread preempt media or 3D which don't
have such a bit in which case
ral thinking is, since MTP is considered not validated / broken /
> dangerous, i915 should default it off. But yes, whitelisting or not on
> top is open."
>
> Maybe we should simply ban it and be done. So this patch is:
>
> Acked-by: Rafael Antognolli
Agreed. If we think that it's broken or is likely to take additional
kernel work to enable it properly, we shouldn't allow userspace to
turn it on until we know the kernel is in good shape. Just ban it
outright and we can figure out white-listing later if and when we get
it properly working.
Acked-by: Jason Ekstrand
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Apr 14, 2017 at 11:34 AM, Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> Patch is
> Reviewed-by: Rafael Antognolli
>
Thanks! Pushed.
> On Fri, Mar 24, 2017 at 04:45:01PM -0700, Jason Ekstrand wrote:
> > A gem handle of 0 can be used to check f
Fine with me.
Reviewed-by: Jason Ekstrand
On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
wrote:
> This is used for handling future fences. Currently no driver use
> these, and I think given the new timeline fence proposed by KHR it
> would be better to have a more abstract interface f
> Gen8+ have 64 bit GTT entries, so we need to allocate twice as much
> space for the GTT table in order to cover the same number of GTT
> pages. Fixes sporadic page-fault crashes on the simulator.
> ---
> tools/aubdump.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions
aubdump was only writing 32-bits regardless of platform. This is fine if
the client being dumped leaves the top 32 bits zero since the aubdump GTT
is fairly small. However, if the client does store something in the upper
32 bits, this results in an invalid relocation.
Cc: Kristian Høgsberg
---
On May 1, 2016 6:04 PM, "Kenneth Graunke" wrote:
>
> On Sunday, May 1, 2016 9:51:00 AM PDT Emil Velikov wrote:
> > On 28 April 2016 at 19:13, Eric Engestrom
wrote:
> > > On Mon, Apr 25, 2016 at 05:08:18PM +0100, Emil Velikov wrote:
> > >> On 21 April 2016 at 11:24, Eric Engestrom
> wrote:
> > >>
On Mon, May 9, 2016 at 3:13 PM, Chad Versace wrote:
> On Mon 09 May 2016, Eric Engestrom wrote:
> > On Sun, May 01, 2016 at 09:39:58PM -0700, Jason Ekstrand wrote:
> > > On May 1, 2016 6:04 PM, "Kenneth Graunke"
> wrote:
> > > > On Sunday, Ma
> - struct dma_fence *old_fence = NULL;
> + struct dma_fence *old_fence;
>
This change looks unrelated. Valid, but unrelated. :-)
Having worked through your i915 syncobj patch, this definitely makes some
things a little bit nicer.
Reviewed-by: Jason Ekstrand
>
On Fri, Jul 7, 2017 at 3:34 AM, Chris Wilson
wrote:
> Quoting Ben Widawsky (2017-07-07 00:27:01)
> > drivers/gpu/drm/i915/i915_drv.c | 3 +++
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_pci.c | 13 +
> > include/uapi/drm/i915_drm.h | 8
> >
On Thu, Jul 6, 2017 at 4:27 PM, Ben Widawsky wrote:
> We don't yet have optimal MOCS settings, but we have enough to know how
> to at least determine when we might have non-optimal settings within our
> driver.
>
> Signed-off-by: Ben Widawsky
> ---
> src/intel/vulkan/anv_device.c |
esktop.org/show_bug.cgi?id=101571
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Jason Ekstrand
>
Chris and I discussed this for a while on Friday and I think I understand
the problem and I think this is the correct fix.
Reviewed-by: Jason Ekstrand
That said, I don&
surface layout
> v4: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
>
> Cc: Daniel Vetter
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Reviewed-by: Ben Widawsky (v3)
> Signed-off-by: Ville Syrjä
> ---
> drivers/gpu/drm/drm_fourcc.c | 2 +-
&g
e exposed). However, due to
> system memory pressure, the object may be paged out before use,
> requiring them to be paged back in on execbuf (as may always happen).
>
> Testcase: igt/gem_userptr_blits/populate
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Michał
Closing the sw_sync timeline now signals any remaining fences upon it;
but test_wait_snapshot requires the fence to continue to be busy so that
the __syncobj_wait() will return with -ETIME.
---
tests/syncobj_wait.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/syn
On October 25, 2017 06:05:16 Joonas Lahtinen
wrote:
On Mon, 2017-10-23 at 16:19 -0700, Kenneth Graunke wrote:
On Monday, October 23, 2017 3:53:15 PM PDT Rodrigo Vivi wrote:
> On Mon, Oct 23, 2017 at 10:32:43PM +, Jordan Justen wrote:
> > On 2017-10-19 16:30:44, Kristian Høgsberg wrote:
>
On Wed, Oct 25, 2017 at 10:31 AM, Kenneth Graunke
wrote:
> On Wednesday, October 25, 2017 7:33:41 AM PDT Jason Ekstrand wrote:
> > On October 25, 2017 06:05:16 Joonas Lahtinen wrote:
> [snip]
> > > There indeed seems to be quite a lot of missing registers from the i915
&
The userspace mesa patches to produce Y_TILED_CCS surfaces have been
reviewed for a couple of weeks now. So long as kmscube counts as
userspace, I think this should be good to land.
Acked-by: Jason Ekstrand
On Mon, Jul 31, 2017 at 12:04 AM, Vidya Srinivas
wrote:
> From: Ville Syrj
Drp... replied to an old patch.
The userspace mesa patches to produce Y_TILED_CCS surfaces have been
reviewed for a couple of weeks now. So long as kmscube counts as
userspace, I think this should be good to land.
Acked-by: Jason Ekstrand
On Tue, Aug 1, 2017 at 9:58 AM, Ben Widawsky wrote
On Thu, May 18, 2017 at 2:46 AM, Chris Wilson
wrote:
> Use a priority stored in the context as the initial value when
> submitting a request. This allows us to change the default priority on a
> per-context basis, allowing different contexts to be favoured with GPU
> time at the expense of lower
everything CCS cache-line aligned, our chances of
generating correct data for an arbitrary-size surface are much higher.
Signed-off-by: Jason Ekstrand
Cc: Ville Syrjälä
Cc: Ben Widawsky
Cc: Daniel Stone
Cc: Daniel Vetter
---
tests/kms_ccs.c | 91 -
Here's a re-spin of the userspace bits:
https://patchwork.freedesktop.org/series/27278/
On Thu, Aug 3, 2017 at 11:58 AM, Chris Wilson
wrote:
> From: Jason Ekstrand
>
> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf. It does so
On August 4, 2017 2:59:56 AM Daniel Stone wrote:
Hi Jason,
On 4 August 2017 at 01:52, Jason Ekstrand wrote:
Previously, the test used the old 64x64 convention that Ville introduced
for CCS tiles and not the current 128x32 Y-tile convention. Also, the
original scheme for generating the CCS
On Fri, Aug 4, 2017 at 8:42 AM, Daniel Stone wrote:
> On 4 August 2017 at 15:56, Jason Ekstrand wrote:
> > On August 4, 2017 2:59:56 AM Daniel Stone wrote:
> >>> + width = ALIGN(f.width * 4, 32) / 32;
> >>> +
Reviewed-by: Jason Ekstrand
On Fri, Aug 4, 2017 at 9:37 AM, Daniel Stone wrote:
> Due to a mix-up in kernel branches being used, I'd mangled Jason's
> original CCS test to hopelessly overallocate the CCS surface size.
> Restore it back to its original.
>
> Signed-o
On Thu, Aug 3, 2017 at 11:58 AM, Chris Wilson
wrote:
> From: Jason Ekstrand
>
> This commit adds support for waiting on or signaling DRM syncobjs as
> part of execbuf. It does so by hijacking the currently unused cliprects
> pointer to instead point to an array of i915_gem_exe
A bunch of these tests assume that the handle is looked up after the other
parameters are checked. Other than that, looks good.
Reviewed-by: Jason Ekstrand
On Tue, Aug 8, 2017 at 4:09 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> Some basic sync object interface tests
>
>
This adds both trivial error-checking tests as well as more complex
tests which actually test whether or not waits do what they're supposed
to do. They only currently work on i915 but it should be simple to hook
them up for other drivers by simply implementing the little function
pointer hook prov
hook provided at the top for triggering a syncobj.
v2:
- Actually add the reset tests.
Signed-off-by: Jason Ekstrand
---
tests/Makefile.sources | 1 +
tests/syncobj_wait.c | 714 +
2 files changed, 715 insertions(+)
create mode 100644
---
include/drm/i915_drm.h | 61 ++
1 file changed, 52 insertions(+), 9 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 5ebe046..c26bf7c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -412,6 +412,
501 - 600 of 653 matches
Mail list logo
