On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes which
Fixes make check.
The symbols below were missing:
drm_intel_bufmgr_gem_can_disable_implicit_sync
drm_intel_gem_bo_disable_implicit_sync
drm_intel_gem_bo_enable_implicit_sync
drm_intel_gem_bo_fence_exec
Signed-off-by: Chad Versace
---
intel/intel-symbol-check | 4
1 file
pointer.
Reported-by: Chad Versace
Signed-off-by: Gustavo Padovan
Fixes: beaf5af48034 ("drm/fence: add ou
On Thu 26 Jan 2017, Chris Wilson wrote:
> On Wed, Jan 25, 2017 at 12:38:32PM -0800, Chad Versace wrote:
> > On Mon 14 Nov 2016, Chris Wilson wrote:
> > > Userspace is faced with a dilemma. The kernel requires implicit fencing
> > > to manage resource usage (we alwa
On Thu 26 Jan 2017, Chad Versace wrote:
> On Thu 26 Jan 2017, Chris Wilson wrote:
> > Since the workaround bo is used strictly as a write-only buffer, we need
> > only allocate one per screen and use the same one from all contexts.
> >
> > (The caveat here is duri
On Thu 26 Jan 2017, Chris Wilson wrote:
> On Thu, Jan 26, 2017 at 09:39:51AM -0800, Chad Versace wrote:
> > On Thu 26 Jan 2017, Chris Wilson wrote:
> > > Since the workaround bo is used strictly as a write-only buffer, we need
> > > only allocate one per screen an
on't fully understand the kernel's domain
tracking). If that does work, then it just would require a small hack to
brw_emit_pipe_control_write().
> Signed-off-by: Chris Wilson
> Cc: Kenneth Graunke
> Cc: Martin Peres
> Cc: Chad Versace
> Cc: Daniel Vetter
> ---
&
On Mon 14 Nov 2016, Chris Wilson wrote:
> Userspace is faced with a dilemma. The kernel requires implicit fencing
> to manage resource usage (we always must wait for the GPU to finish
> before releasing its PTE) and for third parties. However, userspace may
> wish to avoid this serialisation if it
e that explicit fencing through an
*explicit* knob. I believe the kernel should not interpret the presence
of an in fence fd in execbuffer as that knob. If it did, then using this
feature from GL/EGL userspace would be unwieldy.
In other words, I like this.
Patch 14 gets my
Acked-by: Chad Versace
Wilson
Squashed-fixes-from: Rafael Antognolli
Signed-off-by: Chad Versace
---
intel/intel_bufmgr.h | 6 ++
intel/intel_bufmgr_gem.c | 32 +++-
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index
From: Chris Wilson
The kernel allows implicit synchronisation to be disabled on individual
buffers. Use at your own risk.
Signed-off-by: Chris Wilson
---
intel/intel_bufmgr.h | 2 ++
intel/intel_bufmgr_gem.c | 32
2 files changed, 30 insertions(+), 4 delet
Generated with `make headers_install`
from tag 'chadv/test/i915-exec-fence-v03'
of .
TODO: Wait until header updates are in upstream kernel.
References:
http://git.kiwitree.net/cgit/~chadv/linux/tag/?h=chadv/test/i915-exec-fence-v03
Signed-off-by: Chad Versace
---
include/drm/i915_d
but don't grok them.
Chad Versace (1):
WAIT: headers: Update drm_i915.h
Chris Wilson (2):
intel: Allow the client to control implicit synchronisation
intel: Support passing of explicit fencing from execbuf
include/drm/i915_drm.h | 277 +++
On Tue 28 Jun 2016, John Harrison wrote:
> The latest set of patches (including changes from feedback about rsvd
> fields) never actually got posted to the mailing list due to the above issue
> with de-staging. I have just updated my FDO git account with them instead.
> The kernel patch is:
> http
On Mon 27 Jun 2016, Chris Wilson wrote:
> On Mon, Jun 27, 2016 at 01:18:59PM -0700, Chad Versace wrote:
> > On Mon 27 Jun 2016, Chad Versace wrote:
> > > Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an
> > > input and/or output fence fd, whose pres
On Mon 27 Jun 2016, Chad Versace wrote:
> Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an
> input and/or output fence fd, whose presence is controlled by flags.
> Also add I915_PARAM_HAS_FENCE_FD.
>
> Signed-off-by: Chad Versace
> ---
> include/uap
Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an
input and/or output fence fd, whose presence is controlled by flags.
Also add I915_PARAM_HAS_FENCE_FD.
Signed-off-by: Chad Versace
---
include/uapi/drm/i915_drm.h | 24 ++--
1 file changed, 22 insertions
gt;
> > > I'm pretty sure Mesa is the only repository where this lives.
> >
> > Yup
>
> Ping?
>
> I'm not sure why this didn't get at least an ACK from Intel, but I don't
> see any reason not to apply this fix.
> I don't h
On 10/23/2014 06:23 AM, Chris Wilson wrote:
> On Thu, Oct 23, 2014 at 12:56:46PM +0100, Chris Wilson wrote:
>> On Thu, Oct 23, 2014 at 04:03:56PM +0530, akash.g...@intel.com wrote:
>>> From: Akash Goel
>>>
>>
>>> This is for improving the CPU write operation performance, as with such
>>> mapping
On 10/30/2013 12:05 PM, Daniel Vetter wrote:
On Wed, Oct 30, 2013 at 7:11 PM, Ian Romanick wrote:
test coverage of the existing code _before_ starting a feature instead
of when the patches are ready for merging should help a lot, before
everyone is invested into patches already and mou
On 10/11/2013 03:51 PM, Chad Versace wrote:
On 10/11/2013 02:29 PM, Matt Turner wrote:
On Fri, Oct 11, 2013 at 2:24 PM, Daniel Vetter wrote:
On Fri, Oct 11, 2013 at 12:51:34PM -0700, Matt Turner wrote:
On Fri, Oct 11, 2013 at 12:40 AM, Daniel Vetter wrote:
On Fri, Oct 11, 2013 at 5:56 AM
On 10/11/2013 02:29 PM, Matt Turner wrote:
On Fri, Oct 11, 2013 at 2:24 PM, Daniel Vetter wrote:
On Fri, Oct 11, 2013 at 12:51:34PM -0700, Matt Turner wrote:
On Fri, Oct 11, 2013 at 12:40 AM, Daniel Vetter wrote:
On Fri, Oct 11, 2013 at 5:56 AM, Matt Turner wrote:
We were seriously *requir
he wrapper,
Reviewed-by: Chad Versace
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
like. It's
flexible enough.
Acked-by: Chad Versace
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ook comments (Daniel)
v3: Undid reset change introduced in last submission (Daniel)
Fixed up comments to address removal changes.
Thanks to Daniel Vetter for a majority of the parity error comments.
CC: Chad Versace
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_irq.c | 8 ---
On 07/16/2013 10:07 PM, Daniel Vetter wrote:
On Tue, Jul 16, 2013 at 04:41:13PM -0700, Ben Widawsky wrote:
Make the uevent strings part of the user API for people who wish to
write their own listeners.
CC: Chad Versace
Signed-off-by: Ben Widawsky
One thing I've toyed around with a b
On 07/11/2013 11:53 AM, Ben Widawsky wrote:
v2: Use the new param
CC: Chad Versace
CC: Bryan Bell
Signed-off-by: Ben Widawsky
---
tools/Makefile.am | 1 +
tools/intel_get_llc_size.c | 58 ++
2 files changed, 59 insertions(+)
create
am instead of reusing HAS_LLC param (Chris, Chad)
Fix unicode multiply symbol (Ben)
CC: Chad Versace
CC: Bryan Bell
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_
f the spec.
The excellent comments remain entirely copied from Chad's code.
I've tested this on two platforms, and it seems to perform how I want.
CC: Chad Versace
CC: Bryan Bell
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/
On 07/04/2013 11:46 AM, Ben Widawsky wrote:
On Thu, Jul 04, 2013 at 08:43:58PM +0200, Daniel Vetter wrote:
On Thu, Jul 4, 2013 at 8:40 PM, Ben Widawsky wrote:
On Thu, Jul 04, 2013 at 08:14:41PM +0200, Daniel Vetter wrote:
On Thu, Jul 04, 2013 at 11:02:07AM -0700, Ben Widawsky wrote:
To make
7;s fix this name in a standard and correct way.
Signed-off-by: Rodrigo Vivi
---
intel/intel_chipset.h | 53 ++-
1 file changed, 27 insertions(+), 26 deletions(-)
For patch 1,
Reviewed-by: Chad Versace
_
esa also uses the byt/baytrail names.
Yes. I know this is painful. Doing it now is the least painful way to do
this right (short of going back in time.)
disclaimer: only compile tested.
disclaimer2: I didn't fix pre-existing checkpatch issues.
CC: Kenneth Graunke
CC: Jesse Barnes
Signed-off-by: Chad Versace
---
intel/intel_chipset.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index b73fa0f..da2fbee 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -82,6 +82,7 @@
#define
I'm not coming to the office today. I have a cold.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 01/30/2012 11:14 AM, Eric Anholt wrote:
> On Mon, 30 Jan 2012 09:41:50 -0800, Chad Versace
> wrote:
>> If the pci_device's actual gen was > 4, then we stupidly set
>> bufmgr_gem->gen = 6.
>
> Might be worth a note to say that no behavior should change. S
If the pci_device's actual gen was > 4, then we stupidly set
bufmgr_gem->gen = 6.
Signed-off-by: Chad Versace
---
intel/intel_bufmgr_gem.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2b4fa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/16/2012 10:36 AM, Daniel Vetter wrote:
> On Mon, Jan 16, 2012 at 10:25:32AM -0800, Chad Versace wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 01/10/2012 04:47 AM, Daniel Vetter wrote:
>>>
Android.mk's are necessary.
>
> To address another concern of Dan's, this will not add another way to
> configure
> the Mesa build. Android handles the system's build configuration in a single
> location which is outside of Mesa.
>
> I'm aware t
OID definition for checks like fcntl.h
> header path
>>
>> - ajax
>
> --
> Sateesh
I want to see the C99 workarounds removed.
In Mesa we enabled -std=c99 in the Android build with this hack:
# Use C99.
ifeq ($(LOCAL_CC),)
ifeq ($(LOCAL_IS_HOST_MODULE),true)
LOCAL
ource
lists. So, by sharing the lists between the two build systems, we can
reduce the frequency at which modifications to the Linux build breaks the
Android build.
Signed-off-by: Chad Versace
---
Makefile.am |9 -
intel/Makefile.am |9 -
intel/sources.mk |
This enables libdrm.so and libdrm_intel.so to build on Android
IceCreamSandwich.
v2: Link libdrm_intel to libpciaccess.
Signed-off-by: Chad Versace
---
Android.mk | 52 +
intel/Android.mk | 57
On 12/28/2011 07:11 AM, Purushothaman, Vijay A wrote:
> You need libpciaccess in Android if you want to use intel-gpu-tools in
> Android. We have already ported these tools to work in Android.
>
> Thanks,
> Vijay
Vijay, please share the source for your Android ports of libpciaccess and
intel-gp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/28/2011 06:56 AM, Eugeni Dodonov wrote:
>
> On Dec 27, 2011 6:41 PM, "Eric Anholt" <mailto:e...@anholt.net>> wrote:
>>
>> On Fri, 23 Dec 2011 12:11:10 -0800, Chad Versace
>> mailto:chad.vers...@linu
This enables libdrm.so and libdrm_intel.so to build on Android
IceCreamSandwich.
Signed-off-by: Chad Versace
---
Android.mk | 52
intel/Android.mk | 49 +
2 files changed, 101
ource
lists. So, by sharing the lists between the two build systems, we can
reduce the frequency at which modifications to the Linux build breaks the
Android build.
Signed-off-by: Chad Versace
---
Makefile.am |9 -
intel/Makefile.am |8
intel/sources.mk |
The function uses libpciaccess, which is not present on Android. So, make
it a no-op that returns 0.
Signed-off-by: Chad Versace
---
intel/intel_bufmgr.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
index 905556f
From: Chad Versace
This series enables libdrm.so and libdrm_intel.so to build on Android
IceCreamSandwich.
Chad Versace (3):
intel: Disable drm_intel_probe_agp_aperture_size() on Android
libdrm,intel: Factor source file lists into sources.mk
libdrm,intel: Add Android makefiles
On 07/18/2011 01:20 AM, Paul Menzel wrote:
> Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace:
> There are alignment/white space issues above.
>
>> + unsigned stride = irb->region->pitch;\
>> + unsigned heigh
- In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
not tiled.
- In the stencil buffer's span functions, the tile's layout must be
decoded in software.
This commit mutually depends on the xf86-video-intel commit
dri: Do not tile stencil buffer
Autho
GTT is incapable of W fencing, so we allocate the stencil buffer with
I915_TILING_NONE and decode the tile's layout in software.
This commit mutually depends on the mesa commit:
intel: Fix stencil buffer to be W tiled
Author: Chad Versace
Date: Mon Jul 18 00:37:45 2011 -0700
CC:
Patch 1 v2:
- Change buffer height from ALIGN(height / 2, 64) to
ALIGN((height + 1) / 2, 64).
Patch 2 v2:
- Change buffer height from ALIGN(height / 2, 64) to
ALIGN((height + 1) / 2, 64).
- Change return type of intel_offset_S8 changed to intptr_t.
- Improve performance of Y_
On 07/18/2011 08:57 AM, Eric Anholt wrote:
> On Mon, 18 Jul 2011 00:55:03 -0700, Chad Versace wrote:
>> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
>> b/src/mesa/drivers/dri/intel/intel_fbo.c
>> index 1669af2..507cc33 100644
>> --- a/src/mesa/drivers/dri/int
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 Versace wrote:
>>>> Until now, the stencil buffer was allocated as a Y tiled buffer, because
>
On 07/18/2011 08:57 AM, Eric Anholt wrote:
> On Mon, 18 Jul 2011 00:55:03 -0700, Chad Versace wrote:
>> diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
>> b/src/mesa/drivers/dri/intel/intel_fbo.c
>> index 1669af2..507cc33 100644
>> --- a/src/mesa/drivers/dri/int
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
>> in several locations the PRM states that it is. However, it is actually
>> W tiled. From the PRM, 2011 S
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
>> in several locations the PRM states that it is. However, it is actually
>> W tiled. From the PRM, 2011 S
- In intel_verify_dri2_has_hiz(), verify that the stencil buffer is
not tiled.
- In the stencil buffer's span functions, the tile's layout must be
decoded in software.
This commit mutually depends on the xf86-video-intel commit
dri: Do not tile stencil buffer
Autho
GTT is incapable of W fencing, so we allocate the stencil buffer with
I915_TILING_NONE and decode the tile's layout in software.
This commit mutually depends on the mesa commit:
intel: Fix stencil buffer to be W tiled
Author: Chad Versace
Date: Mon Jul 18 00:37:45 2011 -0700
CC:
Chad Versace (2):
xf86-video-intel
dri: Do not tile stencil buffer
src/intel_dri.c | 16
mesa
intel: Fix stencil buffer to be W tiled
src/mesa/drivers/dri/intel/intel_clear.c |6 ++
src/mesa/drivers/dri/intel/intel_context.c |9
On Sun, 05 Jun 2011 10:10:39 -0700, Eric Anholt wrote:
> On Sat, 4 Jun 2011 17:06:31 -0700, Chad Versace wrote:
> > Before this commit, if a client were to request a stencil or hiz buffer,
> > then
> > I830DRI2CreateBuffer() allocated and returned an X-tiled b
its quirky pitch requirements.
CC: Eric Anholt
CC: Ian Romanick
CC: Kristian Høgsberg
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
configure.ac|1 +
src/intel_dri.c | 30 ++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/configure.a
ned-off-by: Chad Versace
---
src/intel_dri.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 48d0f56..4571d07 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -338,10 +338,20 @@ I830DRI2CreateBuffer(DrawablePtr drawable
... and bump version to 2.6.
CC: Eric Anholt
CC: Ian Romanick
CC: Kristian Høgsberg
Reviewed-by: Kenneth Graunke
Signed-off-by: Chad Versace
---
configure.ac |2 +-
dri2proto.txt |6 +-
dri2tokens.h |1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a
ou didn't fix the "we'll allocate a buffer
> for *anything*" behavior that made the compat path in Mesa strange this
> time around.
Eric, I've fixed the patch series according to your comments and resubmitted.
Chad Versace (2):
dri: Do not create DRI2 buffers for unreco
On Sun, 05 Jun 2011 01:53:29 -0700, Kenneth Graunke
wrote:
> On 06/04/2011 05:06 PM, Chad Versace wrote:
> > ... and bump version to 2.6.
> >
> > Signed-off-by: Chad Versace
> > ---
> > configure.ac |2 +-
> > dri2proto.txt |6 +-
> >
... and bump version to 2.6.
Signed-off-by: Chad Versace
---
configure.ac |2 +-
dri2proto.txt |6 +-
dri2tokens.h |1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 297be0e..d671f5a 100644
--- a/configure.ac
+++ b
() correctly returns a Y-tiled buffer and handles
the stencil buffer as a special case due its quirky pitch requirements.
This shouldn't break older Mesa versions, because they never query (via
DRI2GetBuffersWithFormat) for the drawable's DRI2BufferStencil.
Signed-off-by: Chad Versace
These patches belong to my effort to enable hiz and separate stencil for IVB.
Patch 1 belongs to dri2proto.
Patch 2 belongs to xf86-video-intel.
There is a related patch series on the mesa-dev list that uses this
functionality. See the thread with subject:
i965: Implement hiz and separate st
68 matches
Mail list logo
