Thanks for this! Series is:
Acked-by: Kenneth Graunke
https://gitlab.freedesktop.org/kwg/mesa/-/commits/iris-userptr-probe
is an untested branch that uses the new probe API in Mesa.
On Thursday, July 15, 2021 3:15:35 AM PDT Matthew Auld wrote:
> From: Chris Wilson
>
> Jason
Thanks! Series is:
Acked-by: Kenneth Graunke
https://gitlab.freedesktop.org/kwg/mesa/-/commits/iris-userptr-probe
is an untested Mesa branch that makes use of the new probe uAPI.
On Thursday, July 15, 2021 3:15:35 AM PDT Matthew Auld wrote:
> From: Chris Wilson
>
> Jason Ekstrand
On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
> +Existing uAPI issues
> +
> +Some potential issues we still need to resolve.
> +
> +I915 MMAP
> +-
> +In i915 there are multiple ways to MMAP GEM object, including mapping the
> same
> +object using differen
e/create-ext-placement-each
> Testcase: igt/gem_create/create-ext-placement-all
> Signed-off-by: Matthew Auld
> Signed-off-by: CQ Tang
> Cc: Joonas Lahtinen
> Cc: Daniele Ceraolo Spurio
> Cc: Lionel Landwerlin
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Ken
On Wednesday, April 28, 2021 9:56:25 AM PDT Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld wrote:
[snip]
> > Slightly orthogonal: what does Mesa do here for snooped vs LLC
> > platforms? Does it make such a distinction? Just curious.
>
> In Vulkan on non-LLC platforms, we o
Auld
> Cc: Joonas Lahtinen
> Cc: Thomas Hellström
> Cc: Daniele Ceraolo Spurio
> Cc: Lionel Landwerlin
> Cc: Jon Bloomfield
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: dri-devel@lists.freedesktop
Hello,
Yes, that bit only exists on Haswell. On Haswell, sample_c operations
were processed at 1 pixel/clock unless you set that bit, in which case
they get processed at 4 pixels/clock. The downside is that it breaks
some obscure media feature that apparently no one used.
Broadwell and later al
On Friday, July 2, 2021 12:22:58 PM PDT Daniel Vetter wrote:
> On Fri, Jul 02, 2021 at 03:31:08PM +0100, Tvrtko Ursulin wrote:
> >
> > On 01/07/2021 16:10, Matthew Auld wrote:
> > > The CPU domain should be static for discrete, and on DG1 we don't need
> > > any flushing since everything is alread
gt; through a new gem_create_ext extension.
>
> v2: add some kernel doc for the discrete changes, and document the
> implicit rules
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Maarten Lankhorst
> Cc: Tvrtko Ursulin
> Cc: Jo
On Thursday, July 15, 2021 4:27:44 AM PDT Tvrtko Ursulin wrote:
>
> On 15/07/2021 12:07, Daniel Vetter wrote:
> > On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 15/07/2021 11:15, Matthew Auld wrote:
> >>> From: Chris Wilson
> >>>
> >>> Jason Ekstrand requested a more
On Wednesday, April 27, 2016 9:37:07 AM PDT Thorsten Leemhuis wrote:
> Thorsten Leemhuis wrote on 26.04.2016 13:41:
> > Lo! Below patch adds the PCI-ID for the Intel(R) Iris Graphics 550
(Skylake
> > GT3e mobile) to libdrm. It afaics is the last piece that is missing to
> > make those GPUs work pr
xf86drm: Fix spelling mistakes
Gustavo Padovan (3):
tests: add virtio_gpu to the driver list
gitignore: ignore kms-steal-crtc and kms-universal-planes
modetest: print signed values correctly
Kenneth Graunke (1):
Bump version for release
MichaÅ Winiarski (1
On Tuesday, February 19, 2019 10:08:13 AM PST Ville Syrjälä wrote:
> On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> > On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> > >
> > > 0x0f30
> > > ff049b
On Monday, April 3, 2023 9:48:40 AM PDT Ville Syrjälä wrote:
> On Mon, Apr 03, 2023 at 09:35:32AM -0700, Matt Roper wrote:
> > On Mon, Apr 03, 2023 at 07:02:08PM +0300, Ville Syrjälä wrote:
> > > On Fri, Mar 31, 2023 at 11:38:30PM -0700, fei.y...@intel.com wrote:
> > > > From: Fei Yang
> > > >
>
On Thursday, June 22, 2023 11:27:30 AM PDT Lucas De Marchi wrote:
> Most of the context workarounds tweak masked registers, but not all. For
> masked registers, when writing the value it's sufficient to just write
> the wa->set_bits since that will take care of both the clr and set bits
> as well a
workarounds.c | 32 ++---
> 1 file changed, 16 insertions(+), 16 deletions(-)
Patches 1 and 3 are:
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
On Friday, June 23, 2023 8:49:05 AM PDT Lucas De Marchi wrote:
> On Thu, Jun 22, 2023 at 04:37:21PM -0700, Kenneth Graunke wrote:
> >On Thursday, June 22, 2023 11:27:30 AM PDT Lucas De Marchi wrote:
> >> Most of the context workarounds tweak masked registers, but not all. For
>
On Saturday, June 24, 2023 10:17:57 AM PDT Lucas De Marchi wrote:
> The comment on the parameter being 0 to avoid the read back doesn't
> apply as this is not a call to wa_mcr_add(), but rather to
> wa_mcr_clr_set(). So, this register is actually checked and it's
> according to the Bspec that the r
WA is intentionally
> overwriting all the bits to avoid a read-modify-write.
>
> v2: Reword commit message wrt GEN12_FF_MODE2 and the changed behavior
> on preparatory patches.
>
> Cc: Kenneth Graunke
> Cc: Matt Roper
> Link:
> https://gitlab.freedesktop.org/mesa/me
in clr_set()
>
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 129 ++--
> 1 file changed, 66 insertions(+), 63 deletions(-)
Whole series is now:
Reviewed-by: Kenneth Graunke
Thanks a lot for fixing this, Lucas!
signature.asc
Description: This is a digitally signed message part.
On Thursday, March 23, 2017 4:39:50 AM PDT Emil Velikov wrote:
> On 22 March 2017 at 20:10, Dylan Baker wrote:
[snip]
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\
"Bug-free" - famous last words :)
It is de
On 11/21/2013 08:12 PM, Keith Packard wrote:
> The __DRIimage createImageFromFds function takes a fourcc code, but there was
> no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
> that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
> __DRI_IMAGE_FOURCC
uest_serial;
> uint32_t present_msc_event_serial;
> -
> - uint64_t previous_time;
> - unsigned frames;
>
> struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
> int cur_back;
> - int depth;
>
> uint32_t *stamp;
>
>
This one is easy.
Re
On 12/13/2013 05:25 PM, Keith Packard wrote:
> These are duplicates from gl.h; I'm not sure which file they belong in, but
> you don't get to have them in both places.
>
> Signed-off-by: Keith Packard
> ---
> include/GL/glext.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/G
On 11/18/2013 12:58 PM, Emil Velikov wrote:
> On 18/11/13 01:08, Keith Packard wrote:
>> libudev doesn't have a stable API/ABI, and if the application wants to use
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard
>> ---
>>
> Hi Keith,
>
> Did you had t
t;
> uint32_t sync_fence; /* XID of X SyncFence object */
> - int32_t *shm_fence; /* pointer to xshmfence object */
> + struct xshmfence *shm_fence; /* pointer to xshmfence object */
Would be great to line these comments up. Patches 2 and 4-6 are:
Reviewed-by: Kenneth Graunke
> GLbooleanbusy; /* Set on swap, cleared on IdleNotify */
> void *driverPrivate;
>
>
> + if (modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> + modifier == I915_FORMAT_MOD_Yf_TILED_CCS)
> + return true;
> case DRM_FORMAT_RGB565:
> case DRM_FORMAT_XRGB2101010:
> case DRM_FORMAT_XBGR2101010:
> @@ -1230,7
On Tuesday, August 1, 2017 3:47:53 PM PDT Ben Widawsky wrote:
> On 17-08-01 15:43:50, Kenneth Graunke wrote:
> >On Tuesday, August 1, 2017 9:58:17 AM PDT Ben Widawsky wrote:
> >> v2:
> >> - Support sprite plane.
> >> - Support pipe C/D limitation on
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/i915_drv.c |4 ++--
> drivers/gpu/drm/i915/i915_drv.h |2 +-
> drivers/gpu/drm/i915/intel_display.c | 26 +++---
> 3 files changed, 26 insertions(+), 6 deletions
On 06/04/2012 10:53 PM, Dave Airlie wrote:
>>
>> I've run these on various workloads and saw nothing worth mentioning.
>
> Nothing at all? no speedups, slowdowns, etc
>
> why should we merge all this code then :-)
>
> Dave.
Preserving hardware state across batches is going to be necessary for:
>
> 0-16: kernel patches
> 17-21: libdrm patches (wait render patch is temporary)
Patches 17-21 look fine.
Reviewed-by: Kenneth Graunke
> 22-24: intel-gpu-tools
> 25: mesa
Patch 25 looks fine too. Feel free to apply some combination of:
Reviewed-by: Kenneth Graunke
Signed-off-by
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/i915_drv.c |4 ++--
> drivers/gpu/drm/i915/i915_drv.h |2 +-
> drivers/gpu/drm/i915/intel_display.c | 26 +++---
> 3 files changed, 26 insertions(+), 6 deletions(-)
Reviewed-by: Kenneth Graunke
On 06/04/2012 10:53 PM, Dave Airlie wrote:
>>
>> I've run these on various workloads and saw nothing worth mentioning.
>
> Nothing at all? no speedups, slowdowns, etc
>
> why should we merge all this code then :-)
>
> Dave.
Preserving hardware state across batches is going to be necessary for:
>
> 0-16: kernel patches
> 17-21: libdrm patches (wait render patch is temporary)
Patches 17-21 look fine.
Reviewed-by: Kenneth Graunke
> 22-24: intel-gpu-tools
> 25: mesa
Patch 25 looks fine too. Feel free to apply some combination of:
Reviewed-by: Kenneth Graunke
Signed-off-by
++
> 2 files changed, 21 insertions(+)
Reviewed-by: Kenneth Graunke
2 insertions(+), 1 deletion(-)
Nice, makes sense...if they submit a batch referencing the buffer, it
might be busy, so we need to check...if not, and it isn't shared, it's
definitely idle, so skip the check. I like it.
Reviewed-by: Kenneth Graunke
intel: Track whether a buffer is idle to avoid trips to the kernel.
Hyungwon Hwang (1):
tests/kmstest: support exynos
Keith Packard (1):
Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))
Kenneth Graunke (2):
intel: Create a new drm_intel_bo offset64 field.
):
> intel/bdw: Add gen8 to the decode init
> intel/bdw: Update MI_BATCH_BUFFER_START for aub dumps
>
> Kenneth Graunke (1):
> intel/bdw/aub: Update AUB trace block writes for 48-bit addressing.
>
> intel/intel_bufmgr_gem.c | 24 +++-
> intel/in
work.
>
> v3: Fix compile failures from last-minute typos. Sigh.
>
> Signed-off-by: Ian Romanick
> Cc: Mika Kuoppala
> Cc: Daniel Vetter
Assuming Mika's kernel patch actually lands, and the ioctl numbers don't
get out of sync, this is:
Reviewed-by: Kenneth Grau
On 11/08/2013 02:32 PM, Matt Turner wrote:
> On Fri, Nov 8, 2013 at 11:29 AM, Dave Airlie wrote:
>> Since we seemed to have some confusion over this I'll state it clearly here.
>>
>> You should not merge kernel interface and ioctls to libdrm until they
>> have appeared in a git commit upstream wit
On 11/17/2013 06:43 PM, Keith Packard wrote:
> Emil Velikov writes:
>
>> On 18/11/13 01:08, Keith Packard wrote:
>>> libudev doesn't have a stable API/ABI, and if the application wants to use
>>> one
>>> version, we'd best not load another into libGL.
>>>
>>> Signed-off-by: Keith Packard
>>> --
y a message that said:
Welcome Kenneth Graunke
Member since 2010-09-16
Based on the fact that I logged in successfully, and the website greeted me as
a member, I would have suspected my membership was current. However, this
email made me check the "List of Members" page, where I
42 matches
Mail list logo
