On 4/15/21 8:59 AM, Matthew Auld wrote:
> Add a note about the two-step process.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: dri-de...@lists.fr
On 08/24/2016 12:42 PM, Chris Wilson wrote:
> From about kernel 4.9, GTT mmaps are virtually unlimited. A new
> parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the
> feature so query it and use it to avoid limiting tiled allocations to
> only fit within the mappable aperture.
>
> Sig
Based on light reading, patches 1, 5, 6, 7, 8, 10, and 11 are
Reviewed-by: Ian Romanick
I sent a comment on patch 9. I'll try to look at the others in the next
few days... assuming nobody beats me to it.
I'm also going to send some similar Mesa patches that I'll CC you on.
O
On 03/05/2015 08:20 AM, Damien Lespiau wrote:
> Time to switch over all the IS_GENX() macros to the new device object.
> Nothing more than a mechanical search & replace here.
Hmm... why not just do the comparisons directly? The macros seem
superfluous.
> Signed-off-by: Damien Lespiau
> ---
> i
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
>
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
> intel/intel
Short version:
- Khronos face-to-face
- BYT performance work
Longer version:
Yet another Khronos face-to-face meeting. This was a special meeting
just for the gl_common working group to hammer out details of XGL (still
need a name!) so that we can at least have a chance of having a
provisional
From: Ian Romanick
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick
Reported-by: Zhenyu Wang
Cc: Damien Lespiau
Cc: Daniel Vetter
---
intel/intel_bufmgr_gem.c | 2 +-
1 file
From: Ian Romanick
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kernel work.
v3: Fix compile fai
rebased on top of reworked context hang stats
>> DRM_RENDER_ALLOW for ioctl
>>
>> v9: use DEFAULT_CONTEXT_ID. Improve comments for ioctl struct members
>>
>> Signed-off-by: Mika Kuoppala
>> Cc: Ian Romanick
>> Cc: Chris Wilson
>> Cc: Daniel Vet
From: Ian Romanick
The drm_intel_context structure is, wisely, opaque. However, libdrm
users may want to know the hardware context ID associated with the
structure.
Signed-off-by: Ian Romanick
Cc: Ben Widawsky
---
intel/intel_bufmgr.h | 1 +
intel/intel_bufmgr_gem.c | 6 ++
2 files
From: Ian Romanick
Previously GCC was squaking about:
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_map_unsynchronized':
intel_bufmgr_gem.c:1325:20: warning: unused variable 'bo_gem'
[-Wunused-variable]
Wrapping with VG(); replaced that warning with:
intel_bufmg
On 11/07/2013 10:32 PM, Daniel Vetter wrote:
> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie wrote:
>> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
>>> On Tue, Oct 29, 2013 at 11:29 PM, Ian Romanick wrote:
>>>> On 10/27/2013 05:30 AM, Daniel Vetter wrote:
&g
On 11/08/2013 11:00 AM, Dave Airlie wrote:
> On Sat, Nov 9, 2013 at 3:21 AM, Ian Romanick wrote:
>> On 11/07/2013 10:32 PM, Daniel Vetter wrote:
>>> On Fri, Nov 8, 2013 at 6:48 AM, Dave Airlie wrote:
>>>> On Wed, Oct 30, 2013 at 6:21 PM, Daniel Vetter wrote:
>&
On 10/30/2013 09:00 AM, Daniel Vetter wrote:
> [This is cross-posted to the public intel-gfx mailing list at
> http://lists.freedesktop.org/archives/intel-gfx/2013-October/035268.html
> I'll also present a quick overview of this at Gavin's kernel PDT next
> week.]
>
> Hi all,
>
> So in the past h
d process
>
> v6: ctx=0 needs CAP_SYS_ADMIN for batch_* counters (Chris Wilson)
>
> v7: context hang stats never returns NULL
>
> v8: rebased on top of reworked context hang stats
> DRM_RENDER_ALLOW for ioctl
>
> v9: use DEFAULT_CONTEXT_ID. Improve comments for ioctl
On 10/27/2013 05:30 AM, Daniel Vetter wrote:
> On Fri, Oct 25, 2013 at 06:42:35PM -0700, Ian Romanick wrote:
>> Since the Mesa merge window is closing soon, I'm finally getting back on
>> this. I've pushed a rebase of my old Mesa branch to my fd.o repo
>>
>>
xt handled inside i915_gem_contest_get_hang_stats
>
> v5: reset_count only for priviledged process
>
> v6: ctx=0 needs CAP_SYS_ADMIN for batch_* counters (Chris Wilson)
>
> v7: context hang stats never returns NULL
>
> Signed-off-by: Mika Kuoppala
> Cc: Ian Romanic
the defined macros (defines).
Signed-off-by: Sedat Dilek
This should get Chris's ok before committing, but
Reviewed-by: Ian Romanick
---
include/drm/i915_drm.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/drm/i915_drm.h b/includ
On 03/19/2013 05:58 AM, Mika Kuoppala wrote:
Ian Romanick writes:
On 03/14/2013 08:52 AM, Mika Kuoppala wrote:
This ioctl returns context reset status for specified context.
Signed-off-by: Mika Kuoppala
CC: i...@freedesktop.org
---
drivers/gpu/drm/i915/i915_dma.c |1 +
drivers/gpu
On 03/14/2013 08:52 AM, Mika Kuoppala wrote:
This ioctl returns context reset status for specified context.
Signed-off-by: Mika Kuoppala
CC: i...@freedesktop.org
---
drivers/gpu/drm/i915/i915_dma.c |1 +
drivers/gpu/drm/i915/i915_drv.c | 61 +++
dri
On 03/14/2013 08:52 AM, Mika Kuoppala wrote:
To count context losses, add struct ctx_reset_state for
both i915_hw_context and drm_i915_file_private.
drm_i915_file_private is used when there is no context.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_dma.c |4 +++-
d
On 02/28/2013 03:14 AM, Chris Wilson wrote:
On Wed, Feb 27, 2013 at 05:15:08PM -0800, Ian Romanick wrote:
On 02/27/2013 01:13 AM, Chris Wilson wrote:
On Tue, Feb 26, 2013 at 05:47:12PM -0800, Ian Romanick wrote:
On 02/26/2013 03:05 AM, Mika Kuoppala wrote:
For arb-robustness, every context
On 02/27/2013 01:13 AM, Chris Wilson wrote:
On Tue, Feb 26, 2013 at 05:47:12PM -0800, Ian Romanick wrote:
On 02/26/2013 03:05 AM, Mika Kuoppala wrote:
For arb-robustness, every context needs to have it's own
reset state tracking. Default context will be handled in a identical
way as t
On 02/26/2013 05:47 PM, Ian Romanick wrote:
On 02/26/2013 03:05 AM, Mika Kuoppala wrote:
For arb-robustness, every context needs to have it's own
reset state tracking. Default context will be handled in a identical
way as the no-context case in further down in the patch set.
For no-context
On 02/26/2013 03:05 AM, Mika Kuoppala wrote:
For arb-robustness, every context needs to have it's own
reset state tracking. Default context will be handled in a identical
way as the no-context case in further down in the patch set.
For no-context case, the reset state will be stored in
the file_p
On 07/18/2012 09:55 AM, Daniel Vetter wrote:
On Wed, Jul 18, 2012 at 09:23:46AM -0700, Ian Romanick wrote:
On 07/18/2012 02:20 AM, Daniel Vetter wrote:
- The "all contexts in a share group need to receive a reset notification"
wording is irking me a bit because we currently only
On 07/18/2012 02:20 AM, Daniel Vetter wrote:
On Tue, Jul 17, 2012 at 03:16:19PM -0700, Ian Romanick wrote:
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky
bits of the extension that are causing some gri
On 07/17/2012 03:16 PM, Ian Romanick wrote:
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky bits
of the extension that are causing some grief in designing the kernel /
user interface. I think I've set
I'm getting ready to implement the reset notification part of
GL_ARB_robustness in the i965 driver. There are a bunch of quirky bits
of the extension that are causing some grief in designing the kernel /
user interface. I think I've settled on an interface that should meet
all of the requirem
lude all of the
information from this e-mail and the image showing the corruption.
> -Ursprüngliche Nachricht-
> Von: "Ian Romanick"
> Gesendet: Jul 19, 2011 11:08:14 PM
> An: "Nicolas Kalkhof"
> Betreff: Re: [Intel-gfx] gen6 (SNB) depthbuffer issue with Open
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/19/2011 01:21 PM, Nicolas Kalkhof wrote:
> Hi all,
>
> ok I've nailed the issue down to 3.0.0-rc7 and 3.0.0-rc7-git1. I suspect that
> the changes made in
> drivers/gpu/drm/i915/i915_dma.c are the cause of the problem.
>
> http://www.kernel.or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/19/2011 07:58 AM, Nicolas Kalkhof wrote:
> Hi there,
>
> I've experienced a strange depth buffer issue recently with OpenGL games
> (see attached screenshots). It seems that the depth buffer fails on some
> pixels. This problem was introduced so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2011 01:52 PM, Terumichi Sadahiro wrote:
> I can't find any description about 915GME (not 915GM) in
> intellinuxgraphics.org at all.
> Does this device have so little demand for, or is there any problem?
There are a lot of different variatio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 02:24 PM, Chad Versace wrote:
> On 07/18/2011 02:02 PM, Ian Romanick wrote:
>> On 07/18/2011 01:54 PM, Chad Versace wrote:
>>> On 07/18/2011 11:49 AM, Ian Romanick wrote:
>>>> On 07/18/2011 12:55 AM, Chad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 01:54 PM, Chad Versace wrote:
> On 07/18/2011 11:49 AM, Ian Romanick wrote:
>> On 07/18/2011 12:55 AM, Chad Versace wrote:
>>> Until now, the stencil buffer was allocated as a Y tiled buffer, because
>>> i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 12:28 PM, Chad Versace wrote:
> On 07/18/2011 11:45 AM, Ian Romanick wrote:
>> On 07/18/2011 12:55 AM, Chad Versace wrote:
>>> Until now, the stencil buffer was allocated as a Y tiled buffer, because
>>> i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 12:55 AM, Chad Versace wrote:
> Until now, the stencil buffer was allocated as a Y tiled buffer, because
> in several locations the PRM states that it is. However, it is actually
> W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/18/2011 12:55 AM, Chad Versace wrote:
> Until now, the stencil buffer was allocated as a Y tiled buffer, because
> in several locations the PRM states that it is. However, it is actually
> W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/18/2011 06:21 PM, Jesse Barnes wrote:
> Looks like I didn't merge Ben's RPS work queue stuff correctly with the
> new IRQ split code (diff was sparse enough that git didn't complain).
> This should prevent null derefs on ILK+ due to the missing w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/2011 01:24 AM, Zou, Nanhai wrote:
> Hi Ken,
> URB allocation on gen6 is different than previous gens.
> On previous gen, there is a total size urb for many stages of VS GS CLIP SF.
> So driver has to decide how much urb to allocate for e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2011 10:55 AM, Eric Anholt wrote:
> Here's an idea for an SNB performance improvement from the specs. It
> says that on GT2 you should be able to use 80 threads if "WIZ Hashing
> Disable in GT_MODE register enabled". On my system (supposedl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/29/2010 06:06 AM, Clurado cl wrote:
> Hi all , after a month of discussing , debugging and ... i still have
> problem with OpenGL ES1 on Intel GM855 Hardware . i confiused about GL
> ES 1 requirements , so please let me know , is GM855 support Op
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/29/2010 12:52 AM, Zhenyu Wang wrote:
> Looks the culprit for recent piglit regression on sandybridge
> that caused hang is bisected to
Could you be more specific about the regression? The commit message
mentions two tests that regress with thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note: I'm sending this reply to mesa-...@lists.freedesktop.org instead
of the old mailing list.
Maxim Levitsky wrote:
> On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote:
> Corbin Simpson wrote:
>>>> Curious. Admitte
:34 +0300, Maxim Levitsky wrote:
>> > On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
>>
>> Bisected this to
>>
>> 73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
>> commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
>> Author: Ian Romanick >
46 matches
Mail list logo
