Hi,
On 16.3.2023 10.50, Tvrtko Ursulin wrote:
[ 11.674183] i915 :00:02.0: PXP init-arb-session-15 failed due
to BIOS/SOC:0x101a:ERR_PLATFORM_CONFIG
...
Alan - is this expected during normal operation on some parts, or it's
something truly unexpected/unexplained? If the former then I
Hi,
Tested the patch with Ubuntu 22.04 desktop + Linux 6.2-rc3 (drm-tip)
kernel, on TGL-H HW.
With it, this log spam has disappeared:
[ 8691.608933] i915 :00:02.0: [drm] PXP firmware failed arb session
init request ret=[0x101f]
[
: https://gitlab.freedesktop.org/drm/intel/-/issues/430
Co-developed-by: Chris Wilson
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
Cc: Eero Tamminen
Cc: Tvrtko Ursulin
Cc: Rodrigo Vivi
Cc: Daniel Vetter
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Rodrigo Vivi
-u 4 -n 4800 -async 4 -hw
(Chris, MediaSDK build installs sample_multi_transcode to
share/mfx/samples/ directory.)
- Eero
On 19.12.2019 18.45, Chris Wilson wrote:
References: https://gitlab.freedesktop.org/drm/intel/issues/846
Cc: Imre Deak
Cc: Eero Tamminen
---
drivers/gpu/drm/
n I had to fix the MOCS target cache
to really say PTE rather than LLC+eLLC.
Caveat: I've not benchmarked any real workloads. IIRC Eero did
benchmark an earlier version, but that didn't have the PTE vs.
LLC+eLLC MOCS fix so it wasn't actually doing the right thing
most likely.
Cc: Eero Tamminen
Sig
Hi,
On 11.2.2019 11.49, Tvrtko Ursulin wrote:
On 08/02/2019 13:58, Eero Tamminen wrote:
On 8.2.2019 14.03, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Two new output modes are added: listing of text data to standard out (-l
on the command line), and dumping of JSON formatted records (-J
t;: "%"
},
"Video/1": {
"busy": 0.00,
"sema": 0.00,
"wait": 0.00,
"unit": "%"
Hi,
On 14.04.2018 07:01, Srinivas Pandruvada wrote:
Hi Francisco,
[...]
Are you no longer interested in improving those aspects of the non-
HWP
governor? Is it that you're planning to delete it and move back to a
generic cpufreq governor for non-HWP platforms in the near future?
Yes that
Hi,
On 04.04.2018 15:42, Tvrtko Ursulin wrote:
On 04/04/2018 13:15, Eero Tamminen wrote:
I've now tested v5 with old Ubuntu kernel on KBL, and with latest
drm-tip kernel on SNB, HSW, BYT, BSW and BDW GT & GT3.
Generic test results
* Tool works on all of them
* The
latest git versions of Mesa, libxcb, X server
and few other things, and adding this to X server config:
---
Section "ServerFlags"
Option "Debug" "dmabuf_capable"
EndSection
---
On 03.04.2018 20:18, Tvrtko Ursulin wro
Hi,
On 03.04.2018 12:36, Tvrtko Ursulin wrote:
On 29/03/2018 15:30, Eero Tamminen wrote:
I tested this on HSW GT2, BYT, BDW GT3, SKL GT2 and KBL GT3e,
with Ubuntu 16.04 and 17.10, using Ubuntu default kernels (4.4 to 4.13)
and latest drm-tip build (4.16.0-rc7).
General comments
asserts. (Rinat Ibragimov)
* Continuously adapt to terminal size. (Rinat Ibgragimov)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Cc: Petri Latvala <petri.la
Hi,
On 04.05.2017 11:53, Tvrtko Ursulin wrote:
On 04/05/2017 09:35, Arkadiusz Hiler wrote:
On Thu, Apr 27, 2017 at 05:23:16PM +0100, Chris Wilson wrote:
But what is being counter suggested is that their is no reason for these
mocs entries. If the sdk is just using mocs registers without first
Hi,
On 14.03.2017 12:48, Eero Tamminen wrote:
On 11.03.2017 03:14, 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 is obviously not what the user of the API wanted.
Eric left
Hi,
On 11.03.2017 03:14, 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 is obviously not what the user of the API wanted.
Eric left a comment indicating a valid concern: if the CPU
Hi,
On 27.04.2016 17:53, Chris Wilson wrote:
On Wed, Apr 27, 2016 at 04:25:09PM +0300, Eero Tamminen wrote:
[...]
Daniel, Chris, did you have some concrete example in mind where 3D
driver would require CPU to snoop GPU?
Not mesa, but X can do concurrent rendering to a Pixmap whilst also
advertent CPU
snooping due to incorrect MOCS config
Hi,
On 26.04.2016 17:30, Daniel Vetter wrote:
On Tue, Apr 26, 2016 at 05:26:43PM +0300, Eero Tamminen wrote:
[...]
What this kernel ABI (index entry #2) has been agreed & documented to
provide?
I thought this entry is supposed to replace the writ
Hi,
On 26.04.2016 17:30, Daniel Vetter wrote:
On Tue, Apr 26, 2016 at 05:26:43PM +0300, Eero Tamminen wrote:
[...]
What this kernel ABI (index entry #2) has been agreed & documented to
provide?
I thought this entry is supposed to replace the writeback LLC/eLLC cache
MOCS setting
Hi,
On 26.04.2016 16:23, Chris Wilson wrote:
On Tue, Apr 26, 2016 at 04:17:55PM +0300, Imre Deak wrote:
On ti, 2016-04-26 at 13:57 +0100, Chris Wilson wrote:
On Tue, Apr 26, 2016 at 03:44:22PM +0300, Imre Deak wrote:
Setting a write-back cache policy in the MOCS entry definition also
implies
Hi,
On 12/07/2015 07:38 PM, Jesse Barnes wrote:
[...]
Still wishing we had a good way to benchmark these types of changes
across a range of workloads. Eero, have you guys looked at turbo stuff
at all yet?
Except for this, not really:
https://jira01.devtools.intel.com/browse/LCK-2271
Hi,
Attached patch fixes typo in intel_lid.man.
- Eero
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may
21 matches
Mail list logo
