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
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 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
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
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:
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-de...@lists.freedesktop
On Tuesday, January 8, 2019 7:53:05 AM PST Joonas Lahtinen wrote:
> + Ken/Jason for Mesa
> Quoting Matt Roper (2019-01-07 21:19:31)
> > On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote:
> > > On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> > > > Quoting José Rober
On Tuesday, January 8, 2019 5:02:59 PM PST Chris Wilson wrote:
> Quoting Chris Wilson (2019-01-08 12:28:18)
> > Broadwater and the rest of gen4 do support being able to saving and
> > reloading context specific registers between contexts, providing isolation
> > of the basic GPU state (as programm
TANT_BUFFER from the context image, thereby completely avoiding
> the GPU hangs from chasing invalid pointers. This appears to be the
> default behaviour for gen5, and so we just need to tweak gen4 to match.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Kenneth Graunk
This allows userspace to use "legacy" mode for push constants, where
they are committed at 3DPRIMITIVE or flush time, rather than being
committed at 3DSTATE_BINDING_TABLE_POINTERS_XS time. Gen6-8 and Gen11
both use the "legacy" behavior - only Gen9 works in the "new" way.
Conflating push constant
ew" way.
Conflating push constants with binding tables is painful for userspace,
we would like to be able to avoid doing so.
Signed-off-by: Kenneth Graunke
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/d
On Wednesday, September 11, 2019 1:00:51 AM PDT Chris Wilson wrote:
> Quoting Chris Wilson (2019-09-11 08:42:22)
> > Quoting Kenneth Graunke (2019-09-11 02:48:01)
> > > This allows userspace to use "legacy" mode for push constants, where
> > > they are c
be
> constructed as the user desires.
>
> Cc: Joonas Lahtinen
> Cc: Kenneth Graunke
> ---
> src/gallium/drivers/iris/iris_batch.c | 16 ++-
> src/gallium/drivers/iris/iris_batch.h | 5 +--
> src/gallium/drivers/iris/iris_context.c | 56 -
> 3
On Tuesday, March 26, 2019 12:16:20 AM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2019-03-26 05:52:10)
> > On Monday, March 25, 2019 3:58:59 AM PDT Chris Wilson wrote:
> > > iris currently uses two distinct GEM contexts to have distinct logical
> > > HW contexts
dwerlin
> ---
> drivers/gpu/drm/i915/i915_perf.c | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 2 insertions(+)
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
>perf.oa.ctx_oactxctrl_offset = 0x124;
> + dev_priv->perf.oa.ctx_flexeu0_offset = 0x78e;
> + }
> dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
> }
> }
>
Sounds believable.
Ac
The Demand Prefetch workaround (binding table prefetching) only applies
to Icelake A0/B0. But the Sampler Prefetch workaround needs to be
applied to all Gen11 steppings, according to a programming note in the
SARCHKMD documentation.
Using the Intel Gallium driver, I have seen intermittent failure
failures in
the dEQP-GLES31.functional.copy_image.non_compressed.* tests. After
applying this workaround, the tests reliably pass.
BSpec: 9663
Cc: sta...@vger.kernel.org
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
1 file changed, 5 insertions
ven on Icelake / Gen11 - so it might make sense to call this
gen11_emit_pipe_control() and use it on the Icelake functions.
That said, i915 never sets HDC_PIPELINE_FLUSH until Gen12, so we don't
actually have a bug to fix on Icelake today. But if someone started
trying to set it on Gen11, we wou
this means it needs to switch mid-batch, so only
userspace can properly set it. To facilitate this, the kernel needs
to whitelist the register.
Signed-off-by: Kenneth Graunke
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_reg.h| 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c |
On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote:
> Quoting Kenneth Graunke (2018-01-04 19:38:05)
> > Geminilake requires the 3D driver to select whether barriers are
> > intended for compute shaders, or tessellation control shaders, by
> > whacking a
On Thursday, January 4, 2018 4:41:35 PM PST Rodrigo Vivi wrote:
> On Thu, Jan 04, 2018 at 11:39:23PM +0000, Kenneth Graunke wrote:
> > On Thursday, January 4, 2018 1:23:06 PM PST Chris Wilson wrote:
> > > Quoting Kenneth Graunke (2018-01-04 19:38:05)
> > > > Gemini
t (it doesn't have a name).
Signed-off-by: Kenneth Graunke
Acked-by: Rodrigo Vivi
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_reg.h| 2 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg
t within the mappable aperture.
>
> Signed-off-by: Chris Wilson
> Cc: Kenneth Graunke
Cool! I didn't realize we could do page faulting here, since it's
CPU-related. It's definitely nice to be able to map an unlimited
amount of space, at least as a fallback, even if other met
it17 and 9xx hardware are before my time. :( I've copied Ian
in case he remembers anything from that era.
It looks like the only users of pwrite and pread in Mesa's i915 driver
are for linear buffer objects, not miptrees which could be tiled.
So I think this is fine...(famous las
On Tuesday, April 18, 2017 9:56:14 AM PDT Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Engine discovery uAPI allows userspace to probe for engine
> configuration and features without needing to maintain the
> internal PCI id based database.
I don't understand why I would want to query the ex
On Thursday, May 4, 2017 7:47:21 AM PDT David Weinehall wrote:
> On Thu, May 04, 2017 at 10:35:33AM +0200, Arkadiusz Hiler wrote:
> > Thanks for rephrasing - that's exactly what I am concerned with.
> >
> > Did you just use the MediaSDK as it is - meaning that MOCS entries
> > beyond the set of th
On Thursday, May 4, 2017 7:46:34 PM PDT Dmitry Rogozhkin wrote:
>
> On 5/4/2017 9:51 AM, Kenneth Graunke wrote:
> > MediaSDK is not a benchmark. If I'm not mistaken, it's a userspace
> > driver produced by Intel engineers, one which Intel has the full
> >
On Friday, May 5, 2017 9:21:54 AM PDT Dmitry Rogozhkin wrote:
> > My point largely stands, when redirected - someone is developing a
> > broken closed source userspace driver and is apparently unwilling to
> > change it. That's the real problem.
> Broken? Have you ever attempted to run functional
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> Cc: Matthew Auld
> Reviewed-by: Joonas Lahtinen
> Cc: Jason Ekstrand
> Cc: Kenneth Graunke
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --gi
The SF and clipper units mishandle the provoking vertex in some cases,
which can cause misrendering with shaders that use flat shaded inputs.
There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN
(for the clipper) that work around the issue. These registers are
unfortunately not par
On Friday, June 15, 2018 12:06:05 PM PDT Chris Wilson wrote:
> From: Kenneth Graunke
>
> The SF and clipper units mishandle the provoking vertex in some cases,
> which can cause misrendering with shaders that use flat shaded inputs.
>
> There are chicken bits in 3D_CHI
This looks like a mistake in 1f43677f895a88ae880b35f9b18cc7e6869d0ca6.
---
tools/intel_aubdump.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This code still looks really weird. ${foo:bar} means "the value of $foo,
unless it's unset/empty, in which case 'bar'. But if $file is empty...
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
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:
> >> > Commit 3d0fac7aca237bbe8ed8e2a362d3b42d0ef8c46c changed all
On Monday, May 2, 2016 3:40:14 PM PDT Daniel Stone wrote:
> This commit broke Weston/KMS, and presumably also xf86-video-modesetting.
For me, xf86-video-modesetting, and xf86-video-intel/SNA+DRI3 both work
fine with Y-tiling enabled. However, it does break UXA+DRI3.
I'm curious why xf86-video-mo
Allowing register copies where the source and destination are both
whitelisted should be safe, and is useful. For example, Mesa uses
this to load the command streamer math registers with data from the
pipeline statistics counters.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915
This stores a known value to a register, copies it using
MI_LOAD_REGISTER_REG, then stores from the second register back to
memory, and verifies the value. This ensures that MI_LOAD_REGISTER_REG
is allowed by the command parser, and actually takes effect.
Cc: Chris Wilson
Signed-off-by: Kenneth
On Friday, May 6, 2016 8:50:14 AM PDT Chris Wilson wrote:
> From: Kenneth Graunke
>
> Allowing register copies where the source and destination are both
> whitelisted should be safe, and is useful. For example, Mesa uses
> this to load the command streamer math registers wit
;
> Signed-off-by: Chris Wilson
Much more thorough than my test. Thanks :)
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fr
On Friday, January 27, 2017 9:42:00 AM PST Robert Bragg wrote:
> Folds in Matthew Auld's feedback; thanks.
>
> Robert Bragg (5):
> drm/i915/perf: fix gen7_append_oa_reports comment
> drm/i915/perf: avoid poll, read, EAGAIN busy loops
> drm/i915/perf: avoid read back of head register
> drm/
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 2 --
drivers/gpu/drm/i915/i915_gem.c| 2 --
drivers/gpu/drm/i915/i915_gem_ex
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 2 --
drivers/gpu/drm/i915/i915_gem.c| 2 --
drivers/gpu/drm/i915/i915_gem_ex
On Wednesday, February 15, 2017 12:12:50 AM PST Chris Wilson wrote:
> On Tue, Feb 14, 2017 at 08:17:51PM -0800, Kenneth Graunke wrote:
> > This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
> > (indicating the optional feature is not supported), and makes exe
#x27;t think anyone wants this on Gen4-5.
Based on a patch by Dave Gordon.
v3: Return -ENODEV for the getparam, as this is what we do for other
obsolete features. Suggested by Chris Wilson.
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448
Signed-off-by
gt;
> intel: Add support for softpin
>
> Let's restore previous, more readable format.
>
> Cc: Kristian Høgsberg Kristensen
> Signed-off-by: Michał Winiarski
> ---
> intel/intel_bufmgr_gem.c | 23 ++-
> 1 file changed, 14 insertion
e m
> values.
>
> Signed-off-by: Maarten Lankhorst
> Tested-by:
Tested-by: Kenneth Graunke
> --
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/
intel_display.c
> index 7afbdc45a278..aa4f1e69b92e 100644
> --- a/drivers/gpu/drm/i915/intel_di
On Friday, July 7, 2017 3:17:22 AM PDT Daniel Vetter wrote:
> On Fri, Mar 17, 2017 at 12:15 PM, Joonas Lahtinen
> wrote:
> > On to, 2017-03-16 at 13:20 +, Chris Wilson wrote:
> >> Currently, the last object in the execlist is the always the batch.
> >> However, when building the batch buffer w
state uploads for the older platforms.
>
> Cc: Jason Ekstrand
> Cc: Kenneth Graunke
Nice, I saw Ironlake RC6 go by and was wondering if contexts were up
next :)
It makes sense to use them if the kernel supports them.
Reviewed-by: Kenneth Graunke
signature.asc
Description: Thi
to clarify that this
isn't about 32-bit or 64-bit OSes.
Either way,
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
c.c | 9 +
> drivers/gpu/drm/i915/intel_pm.c | 6 --
> 7 files changed, 23 insertions(+), 24 deletions(-)
Series is:
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
__
On Tuesday, October 10, 2017 4:05:17 PM PDT Jordan Justen wrote:
> v2:
> * Use 48-bit rather than 64-bit (Ken)
> * Use 'addr_bits' rather than 'use_64bit'
>
> Signed-off-by: Jordan Justen
Reviewed-by: Kenneth Graunke
and pushed.
signature.asc
Desc
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 Thu, Oct 19, 2017 at 4:18 PM, 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
> > driver where the context is initialized. (Psst. You can read that as:
> > "all the 33 non-
> + 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
Hello,
The Intel Mesa team would like to welcome you to a new public IRC channel
on Freenode: #intel-3d. The topic is Mesa development for Intel GPUs, in
particular the "i965" OpenGL and "anv" Vulkan drivers.
The open source graphics community has grown a lot over the last few
years, and as a re
ko
> Cc: Tvrtko Ursulin
> Cc: Lionel Landwerlin
Thanks Chris!
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ch enables unsynchronized mappings for reusable buffers
on all Gen6+ hardware (which have either LLC or snooping).
On Broxton, this improves the performance of Unigine Valley 1.0
on Low settings at 1280x720 by about 45%, and Unigine Heaven 4.0
(same settings) by about 53%.
Signed-off-by: Kenneth Graunke
On Sunday, March 12, 2017 6:21:12 AM PDT Chris Wilson wrote:
> On Fri, Mar 10, 2017 at 05:14:32PM -0800, Kenneth Graunke wrote:
> > On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has
> > had the surprising behavior of doing a synchronized GTT mapping.
> > This
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.
versions with known bugs before enabling features like async
> > compute.
>
> There was
> https://patchwork.freedesktop.org/patch/560704/?series=124592&rev=1
> which does everything in one go so would be my preference.
Joonas's patch posted here is:
Reviewed-by: Kenne
Jesse,
This patch seems to have a lot of magical numbers in it. In particular,
v_table and cparams both seem rather cryptic. Would it be possible to add a
few comments saying what these numbers mean or where they came from?
Thanks,
--Kenneth
___
Int
Those numbers are fine. See http://isglxgearsabenchmark.com/ or, more usefully
but less comically, http://qa-rockstar.livejournal.com/7869.html
--Kenneth
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/li
On Tuesday, May 7, 2024 3:56:57 PM PDT Matt Roper wrote:
> On Mon, May 06, 2024 at 09:52:35PM +0300, Juha-Pekka Heikkila wrote:
> > These patches introduce I915_FORMAT_MOD_4_TILED_XE2_CCS modifier, which,
> > from the kernel's perspective, behaves similarly to
`I915_FORMAT_MOD_4_TILED`.
> > This n
NTRIES;
ppgtt->enable = gen6_ppgtt_enable;
ppgtt->base.clear_range = gen6_ppgtt_clear_range;
This is much nicer than my old code - thanks!
It might be worth mentioning in the commit message that in particular,
iris_pte_encode was forgotten here. Either way,
R
both worlds, perfect display and fast
access.
Signed-off-by: Chris Wilson
Cc: Ben Widawsky
Awesome. Thanks a ton for doing this, Chris!
Reviewed-by: Kenneth Graunke
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On 05/06/2014 08:26:15 AM, Yang, Rong R wrote:
> Hi,
>
> I am developing the HSW’s OCL driver in the linux. I encounter a LRI
> problem on HSW.
>
>
> Some gpgpu's applications, which use the shared local memory, must load
> the L3CTRLREG2 and L3CTRLREG3 registers to allocate the SLM in the L3
>
On 05/12/2014 01:02 AM, Yang, Rong R wrote:
> Hi, Ken,
>
> Thanks for your patch. But how do you release your driver on the HSW
> products? If can't LRI/LRM from userspace batches, almost all of
> OpenCL application can't run. So if I want to announce that the
> OpenCL driver support HSW, it must
/show_bug.cgi?id=78891
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78935
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78936
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78937
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78938
Signed-off-by: Kenneth Graunke
Cc
_FETCH));
> +
> + /*
>* According to the spec the following bits should be
>* set in order to enable memory self-refresh and fbc:
>* The bit21 and bit22 of 0x42000
>
I'm almost positive Mesa will hit this case. Nice catch!
Reviewed-by: Kennet
Ben and I believe this will be necessary on production hardware.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
I believe this will be necessary on production hardware.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 7 insertions(+)
I just realized tonight that my workarounds series never got merged.
After reviewing
nal design.
Signed-off-by: Kenneth Graunke
---
src/uxa/intel_batchbuffer.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/uxa/intel_batchbuffer.c b/src/uxa/intel_batchbuffer.c
index 579a63a..ca1af0d 100644
--- a/src/uxa/intel_batchbuffer.c
+++ b/src/uxa/intel_batchbuffer.c
@@ -184,6 +184,
These command packets grew on Gen8.
Signed-off-by: Kenneth Graunke
---
src/uxa/i830_reg.h | 12 ++--
src/uxa/intel_uxa.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/uxa/i830_reg.h b/src/uxa/i830_reg.h
index 93d03cf..d8306bc 100644
--- a/src/uxa
This supports solid, copy, put_image, and get_image acceleration via the
BLT engine. RENDER acceleration (composite) would be piles of work,
which is not worth doing since SNA exists, and Glamor is coming.
Signed-off-by: Kenneth Graunke
---
src/uxa/intel_batchbuffer.h | 8 +++-
src/uxa
hang the GPU. It also doesn't
make any sense to do a render ring flush, given that we never use the
render ring for UXA on Broadwell.
Signed-off-by: Kenneth Graunke
---
src/uxa/intel_batchbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
This is an alternative to my old
On 03/18/2014 01:29 AM, Chris Wilson wrote:
> On Mon, Mar 17, 2014 at 09:27:16AM -0700, Kenneth Graunke wrote:
>> Chris,
>>
>> In the future, if you're going to rewrite significant portions of my
>> patches, could you please at least put your Signed-off-by or someth
Hello,
The version of the command parser which landed in drm-intel-nightly (and
is now enabled by default) completely breaks the 3D driver. Running any
program - glxgears, KDE, GNOME, whatever - results in:
intel_do_flush_locked failed: Invalid argument
and then Mesa aborts the program.
Wh
Mesa needs to be able to write OACONTROL in order to expose the
Observability Architecture's performance counters via OpenGL.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 1 +
drivers/gpu/drm/i915/i915_reg.h| 2 ++
2 files changed, 3 insertions(+)
Mesa needs to be able to write OACONTROL in order to expose the
Observability Architecture's performance counters via OpenGL.
v2: Insert in proper sorted order (caught by Jani Nikula).
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 1 +
drivers/gpu/drm
On 03/26/2014 09:38 AM, Daniel Vetter wrote:
> On Wed, Mar 26, 2014 at 09:03:58AM -0700, Volkin, Bradley D wrote:
>> On Tue, Mar 25, 2014 at 11:21:23PM -0700, Daniel Vetter wrote:
>>> On Tue, Mar 25, 2014 at 10:52:03PM -0700, Kenneth Graunke wrote:
>>>> Mesa needs to
On 03/26/2014 11:26 AM, Volkin, Bradley D wrote:
> On Wed, Mar 26, 2014 at 10:37:44AM -0700, Kenneth Graunke wrote:
>> On 03/26/2014 09:38 AM, Daniel Vetter wrote:
>>> On Wed, Mar 26, 2014 at 09:03:58AM -0700, Volkin, Bradley D wrote:
>>>> On Tue, Mar 25, 2014 at 1
On 03/27/2014 01:16 PM, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 4:57 PM, Volkin, Bradley D
> wrote:
>> On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote:
>>> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether it's
>>> an issue with the test or the checker:
>>>
On 03/27/2014 11:43 AM, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> As suggested during review, this makes it much more obvious
> when the tables are not sorted.
>
> Cc: Jani Nikula
> Signed-off-by: Brad Volkin
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 31
--
> 1 file changed, 71 insertions(+), 65 deletions(-)
I like the refactor.
Reviewed-by: Kenneth Graunke
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
for writing OACONTROL.
>
> Cc: Kenneth Graunke
> Signed-off-by: Brad Volkin
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 35
> ++
> 1 file changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_par
On 03/27/2014 03:44 PM, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 10:34 PM, Kenneth Graunke
> wrote:
>> Why are we parsing batches with I915_EXEC_SECURE at all? Secure batches
>> are only issued from trusted code which is guaranteed to be running as
>> root. I
for writing OACONTROL.
>
> v2: Drop an unnecessary '? true : false'
>
> Cc: Kenneth Graunke
> Signed-off-by: Brad Volkin
I still don't see any rationale for prohibiting LRM - there's zero
security benefit, and you can write to every other register with either
LRI
ug.cgi?id=76719
> Cc: Kenneth Graunke
> Signed-off-by: Brad Volkin
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 9 +
> drivers/gpu/drm/i915/i915_reg.h| 8
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915
1 - 100 of 279 matches
Mail list logo
