Causes an oops in the current kernel.
---
tests/Makefile.am | 2 ++
tests/Makefile.sources | 1 +
tests/vc4_lookup_fail.c | 81 +
3 files changed, 84 insertions(+)
create mode 100644 tests/vc4_lookup_fail.c
diff --git a/tests/Makefile.am
Daniel Stone <dan...@fooishbar.org> writes:
> Hi,
>
> On 3 February 2016 at 21:41, Eric Anholt <e...@anholt.net> wrote:
>> + ret = ioctl(fd, DRM_IOCTL_VC4_WAIT_BO, );
>> + igt_assert(ret == -1 && errno == EINVAL);
>
> A
Signed-off-by: Eric Anholt <e...@anholt.net>
---
lib/Makefile.sources | 2 +
lib/igt_vc4.c| 106 +++
lib/igt_vc4.h| 29 ++
3 files changed, 137 insertions(+)
create mode 100644 lib/igt_vc4.c
create mode 1006
create-bo-0 fails on the current kernel, and it's something I want to
fix.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
tests/Makefile.am | 2 ++
tests/Makefile.sources | 1 +
tests/vc4_create_bo.c | 91 ++
3 files chang
The pad subtest fails currently.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
tests/Makefile.am | 2 ++
tests/Makefile.sources | 1 +
tests/vc4_wait_bo.c| 93 ++
3 files changed, 96 insertions(+)
create mode 100644
Signed-off-by: Eric Anholt <e...@anholt.net>
---
lib/igt_vc4.c | 20
lib/igt_vc4.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/lib/igt_vc4.c b/lib/igt_vc4.c
index 62e1345..15804e9 100644
--- a/lib/igt_vc4.c
+++ b/lib/igt_vc4.c
@@ -25,6 +25,7 @@
#i
These caught an unexpected bug with clear colors (we'd get the last
executed clear's color in our new BO), while failing to catch the bug
I'd been hoping to find all along.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
tests/vc4_wait_bo.c | 41 +
Signed-off-by: Eric Anholt <e...@anholt.net>
---
tests/Makefile.am | 6 +
tests/Makefile.sources | 4 +++
tests/vc4_wait_seqno.c | 69 ++
3 files changed, 79 insertions(+)
create mode 100644 tests/vc4_wait_seqno.c
diff --git a
Signed-off-by: Eric Anholt <e...@anholt.net>
---
lib/drmtest.c | 16 ++--
lib/drmtest.h | 1 +
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 2896af0..7b2227f 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -100,6 +
Signed-off-by: Eric Anholt <e...@anholt.net>
---
lib/igt_vc4.c | 21 +++--
lib/igt_vc4.h | 1 +
tests/vc4_wait_bo.c | 10 ++
3 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/lib/igt_vc4.c b/lib/igt_vc4.c
index 15804e9..0233f2b 100644
---
Signed-off-by: Eric Anholt <e...@anholt.net>
---
configure.ac | 12
1 file changed, 12 insertions(+)
diff --git a/configure.ac b/configure.ac
index ecbfacd..cfbcbf3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -149,6 +149,18 @@ if test "x$NOUVEAU" = xyes; then
fi
It's autodetected if its dependencies are present, but it doesn't
build for ARM, nor am I interested in it for now.
Signed-off-by: Eric Anholt <e...@anholt.net>
---
configure.ac | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
Daniel has suggested that I put vc4 testing into igt, since it's got
the piglit integration and KMS coverage already. This gets the ccore
building so that I can start writing tests.
---
lib/igt_gt.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index
Daniel Vetter <daniel.vet...@ffwll.ch> writes:
> Again since the drm core takes care of event unlinking/disarming this
> is now just needless code.
>
> v2: Fixup misplaced hunk.
>
> Cc: Eric Anholt <e...@anholt.net>
> Acked-by: Daniel Stone <dani...@collab
-sync_flip,
valid, x_off, y_off))
{
Seem reasonable? If you wanted to squash this in, then this is:
Reviewed-by: Eric Anholt e...@anholt.net
(So's patch 1/2, regardless).
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel
Keith Packard kei...@keithp.com writes:
Eric Anholt e...@anholt.net writes:
This change appears to be unrelated, and possibly harmful (if X has
dropped the last ref to the BO, but it's still the scanout buffer, a new
allocation would now reuse the BO and scribble on scanout until the next
Keith Packard kei...@keithp.com writes:
Eric Anholt e...@anholt.net writes:
Keith Packard kei...@keithp.com writes:
I don't see anything indicating that this code path is only used by
glamor.
True. It's a fix for DRI3 for either UXA or none. Mesa allocates a
single page for a 1x1 texture
as long as it still calls
intel_glamor_flush(). If it did, it gets:
Reviewed-by: Eric Anholt e...@anholt.net
even before we sort out the rest of the series.
pgpFn0KaDE2O6.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx
Keith Packard kei...@keithp.com writes:
I spent the day just cleaning up this patch series and testing. I
think it's ready for others to use and review. I've been running it on
two machines for a couple of days now and it's been solid.
Patches 2, 4 are:
Reviewed-by: Eric Anholt e
Keith Packard kei...@keithp.com writes:
Make sure the pitch and tiling are correct.
Make sure there's a BO we can get at.
I thought we couldn't change these parameters, but now I can't find what
prevents them from changing. Can you cite sources?
pgpAYiuAwpzYm.pgp
Description: PGP signature
Keith Packard kei...@keithp.com writes:
I don't see anything indicating that this code path is only used by
glamor.
---
src/uxa/intel_uxa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/uxa/intel_uxa.c b/src/uxa/intel_uxa.c
index b396188..717754f 100644
---
Keith Packard kei...@keithp.com writes:
This eliminates the stubs in intel_glamor.h and replaces them with
ifdefs instead.
I don't feel strongly about this either way -- ifdefs are more
traditional userland style, while stubs are more kernel style.
Acked-by: Eric Anholt e...@anholt.net
Keith Packard kei...@keithp.com writes:
This adds glamor support back into the driver, but instad of going
through UXA, this uses it directly instead.
This is hard to read with the conditionalizing all of the UXA code in
the same commit as adding the glamor code. Then there are a bunch of
Keith Packard kei...@keithp.com writes:
Makes UXA no longer include calls to glamor acceleration functions.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/uxa/Makefile.am| 9 --
src/uxa/intel_dri.c| 60 +
src/uxa/intel_driver.c | 1 -
src/uxa/intel_uxa.c
Keith Packard kei...@keithp.com writes:
GetScratchPixmapHeader should only be used for local memory pixmaps,
as used by PutImage and friends. That's because when you free the
scratch pixmap header, it doesn't actually free the pixmap; instead,
it gets stuffed in pScreen-pScratchPixmap and any
三月！ sunnyma...@qq.com writes:
Hello! I'm developing some openCL application with Beignet in Ubuntu
14.04 x64 Desktop upon Bay Trail E3825. And I found that reading data
from GPU memory through whatever drm_intel gem_bo_map or
drm_intel_gem_bo_get subdata cost about 0.002 ~ 0.003 second to
arun.siluv...@linux.intel.com writes:
From: Siluvery, Arun arun.siluv...@intel.com
This patch adds support to have gem objects of variable size.
The size of the gem object obj-size is always constant and this fact
is tightly coupled in the driver; this implementation allows to vary
its
Chris Wilson ch...@chris-wilson.co.uk writes:
On Wed, May 07, 2014 at 10:44:23PM -0700, Jamey Sharp wrote:
On Wed, May 07, 2014 at 04:55:18PM +0100, Chris Wilson wrote:
On Mon, May 05, 2014 at 11:05:07PM -0700, Jamey Sharp wrote:
UXA was reporting page-flip completion as soon as the flip
Chris Wilson ch...@chris-wilson.co.uk writes:
On Thu, May 08, 2014 at 08:54:52AM -0700, Eric Anholt wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
On Wed, May 07, 2014 at 10:44:23PM -0700, Jamey Sharp wrote:
On Wed, May 07, 2014 at 04:55:18PM +0100, Chris Wilson wrote:
On Mon
Gupta, Sourab sourab.gu...@intel.com writes:
On Tue, 2014-05-06 at 17:56 +, Eric Anholt wrote:
sourab.gu...@intel.com writes:
From: Sourab Gupta sourab.gu...@intel.com
This patch is in continuation of and is dependent on earlier patch
series to 'reduce the time for which device
sourab.gu...@intel.com writes:
From: Sourab Gupta sourab.gu...@intel.com
This patch is in continuation of and is dependent on earlier patch
series to 'reduce the time for which device mutex is kept locked'.
(http://lists.freedesktop.org/archives/intel-gfx/2014-May/044596.html)
One of
Paulo Zanoni przan...@gmail.com writes:
From: Paulo Zanoni paulo.r.zan...@intel.com
Hi
We always talk about how intel_display.c is a giant file and how we would like
to reduce it, so this is my attempt. Currently the file has 12090 lines, and
after my patch series it has 8850 lines.
I
fbpict.h has been an installed header since 2008, shortly after uxa
landed. This fixes compiler warnings when other headers happen to
include fbpict.h.
---
src/uxa/uxa-priv.h | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/src/uxa/uxa-priv.h
Returning an undefined value meant we might get sw cursors.
---
src/uxa/intel_display.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index 39d8507..23eb2c7 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
We should link against the server's copy, insted of using the external
library.
---
configure.ac | 6 --
src/uxa/intel_glamor.c | 14 +-
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index ce4822f..8bbb3b0 100644
---
Goel, Akash akash.g...@intel.com writes:
What happens when we GTT-mapped write a batchbuffer that had
previously been silently made RO by the kernel? Does the CPU take a
fault? We tested this particular case, doing the relocation inside
the Batch buffer, which is mapped to GTT as read-only,
akash.g...@intel.com writes:
From: Akash Goel akash.g...@intel.com
This adds support for using the write-enable bit in the GTT entry for VLV.
This is handled via a read-only flag in the GEM buffer object which
is then used to check if the write-enable bit has to be set or not
when writing
the kernel code for hsw. Thanks.
Reviewed-by: Eric Anholt e...@anholt.net
Note that userspace doesn't currently set MOCS other than the L3 bit.
I'm hoping we end up not having to, since we don't have a WT option in
MOCS other than just listen to the PTEs.
pgpTNk1ROtEYr.pgp
Description: PGP signature
transparent. The
context id to be passed to the kernel could easily be public just like
the gem handle in a BO is public. I would lean slightly toward that.
But I don't feel strongly either way, so these two are:
Reviewed-by: Eric Anholt e...@anholt.net
pgpNMaTtYx36c.pgp
Description: PGP
Ben Widawsky benjamin.widaw...@intel.com writes:
From: Damien Lespiau damien.lesp...@intel.com
The command now takes a 48bits address and is thus 1 byte longer.
I think you mean 1 dword
Other than that, patches 2-5 are
Reviewed-by: Eric Anholt e...@anholt.net
(patch 1, I don't know
Daniel Vetter dan...@ffwll.ch writes:
Hi Ben
So first things first: I rather like what the code looks like overall at
the end. I've done a light read-through (by far not a full review) and
besides a few bikesheds (all mentioned by mail already) the big thing is
the 1:1 context:ppgtt address
Rodrigo Vivi rodrigo.v...@gmail.com writes:
Rendering buffers that need full GT power can request full power through
this I915_EXEC_GT_FULL flag. If the default is the power saving with half
slices off it executes LRIs to immediately enable all slices.
How is userspace supposed to decide that
Daniel Vetter dan...@ffwll.ch writes:
On Thu, Oct 3, 2013 at 12:03 AM, Francisco Jerez curroje...@riseup.net
wrote:
+ case I915_PARAM_HAS_ATOMICS:
+ value = 1;
+ break;
Generally when we do kernel fixes for gpu hangs like that we don't add
parameters
Rinat Ibragimov ibragimovri...@mail.ru writes:
Понедельник, 26 августа 2013, 16:22 -07:00 от Eric Anholt e...@anholt.net:
Rinat Ibragimov ibragimovri...@mail.ru writes:
Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt
e...@anholt.net:
Ибрагимов Ринат ibragimovri...@mail.ru
Ибрагимов Ринат ibragimovri...@mail.ru writes:
libvdpau uses second DRI driver name to determine which VDPAU driver
to use. This patch will allow libvdpau choose libvdpau_i965.so on systems
with Intel GPUs, libvdpau_nvidia.so on those with nVidia ones, and so on.
I'm experimenting now with
Rinat Ibragimov ibragimovri...@mail.ru writes:
Понедельник, 26 августа 2013, 13:40 -07:00 от Eric Anholt e...@anholt.net:
Ибрагимов Ринат ibragimovri...@mail.ru writes:
libvdpau uses second DRI driver name to determine which VDPAU driver
to use. This patch will allow libvdpau choose
---
intel/intel_bufmgr_gem.c | 91 +++-
1 file changed, 43 insertions(+), 48 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 3c73068..b06c99a 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@
There is a very tiny change (-120 bytes) in compiled code size as a
result.
---
intel/intel_bufmgr_gem.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b72a30b..ee73857 100644
---
Saves another 4 bytes on a drm_intel_bo.
---
intel/intel_bufmgr_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index f068df6..5e087bc 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -174,11
It comes in to us as a u32, and goes to the kernel as a u32, so
storing as a long in between is silly.
---
intel/intel_bufmgr_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index b06c99a..f068df6 100644
---
---
intel/intel_bufmgr_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 5e087bc..b72a30b 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -200,7 +200,8 @@ struct _drm_intel_bo_gem {
Daniel Vetter dan...@ffwll.ch writes:
On Wed, May 8, 2013 at 6:39 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, May 08, 2013 at 06:11:19PM +0200, Daniel Vetter wrote:
On Wed, May 08, 2013 at 04:33:09PM +0100, Chris Wilson wrote:
Bugzilla:
Daniel Vetter dan...@ffwll.ch writes:
On Mon, Apr 8, 2013 at 7:40 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Apr 08, 2013 at 07:18:11PM +0200, Daniel Vetter wrote:
On Tue, Feb 12, 2013 at 02:17:22PM +, Chris Wilson wrote:
By exporting the ability to map user address and
Daniel Vetter daniel.vet...@ffwll.ch writes:
It accidentally used the cmd id for the gen7 command and had an
outdated lenght field. Spotted while trying to make sense of an ivb
error_state from mesa 7.11 ...
Reviewed-by: Eric Anholt e...@anholt.net
pgpFNtB_upuPa.pgp
Description: PGP
patrik.r.jakobs...@gmail.com
Confirmed in the 945 and 845 specs.
Reviewed-by: Eric Anholt e...@anholt.net
pgpAuBMtEMvY_.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
Carl Worth cwo...@cworth.org writes:
The driver is not functional at this depth, so tell the user as much and
bail out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31375
Yeah, we shouldn't be supporting 8bpp.
Reviewed-by: Eric Anholt e...@anholt.net
pgpX1BLFGjTWh.pgp
this? Are there
more commands available in the BLT ring than we thought, or have we just
not been testing apps that use blits?
Reviewed-by: Eric Anholt e...@anholt.net
pgp9gh4sIYOFM.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
at offset 0 - causing EINVAL as we
legimately try to render using the stolen fb.
We've never triggered this check in practice, as far as I know, so I'm
happy to see it go.
Reviewed-by: Eric Anholt e...@anholt.net
pgpYPmBoQ3ATR.pgp
Description: PGP signature
The compiler isn't noticing that localDst only diverges from pDst when
the _copy variables have also been set.
---
uxa/uxa-render.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/uxa/uxa-render.c b/uxa/uxa-render.c
index 4463dc2..d783ea2 100644
--- a/uxa/uxa-render.c
+++
---
configure.ac |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index d92269f..92c77f5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -113,7 +113,7 @@ AC_ARG_ENABLE(udev,
if test x$UDEV != xno; then
PKG_CHECK_MODULES(UDEV,
Shuts up a bunch of warnings with xorg's shared warning flags, and
should give us more informative warnings in our code.
---
src/intel.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel.h b/src/intel.h
index d394750..53ce33c 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -553,6
The server interfaces take a non-const GCOps, because it expects you
to be able to modify them.
---
uxa/uxa-accel.c |2 +-
uxa/uxa-priv.h |2 +-
uxa/uxa.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c
index
---
src/intel_dri.c | 54 +++---
1 file changed, 23 insertions(+), 31 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 17d9d50..4c0827d 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -547,6 +547,23 @@
Saves 200b of code at -O2. I noticed this while fixing up the warning
in HEAD~1.
---
uxa/uxa-render.c | 79 +++---
1 file changed, 28 insertions(+), 51 deletions(-)
diff --git a/uxa/uxa-render.c b/uxa/uxa-render.c
index d783ea2..3678f6a 100644
Fixes another gcc warning.
---
src/intel_module.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel_module.c b/src/intel_module.c
index ef62667..06d2ee7 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -111,7 +111,7 @@ static const struct
Richard Yao r...@cs.stonybrook.edu writes:
From: David Shao davs...@gmail.com
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Are you really unable to get the same errnos in your port of the kernel
modules? Having
Chris Wilson ch...@chris-wilson.co.uk writes:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Wouldn't we be able to get rid of the whole eb hash table if we just
made the idr be protected by a proper mutex that we could hold across
the relocation process? Seems like that would be way
Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk writes:
According to intel_gpu_top tool, GPU load is roughly at 40%, apart from the
Framebuffer Compression metric which is maxed out, if that is one is at all
valid.
Often a bit is not actually hooked up to anything, in which case it will
be
Damien Lespiau damien.lesp...@gmail.com writes:
The goal here is to make dmesg output with the full verbosity a bit easier to
parse by a human. The script will transform:
Couldn't a little bit of preprocessor in the kernel ioctl definitions
give us decent names right in the dmesg?
Ville Syrjälä ville.syrj...@linux.intel.com writes:
On Tue, Oct 30, 2012 at 01:33:47PM -0500, Jesse Barnes wrote:
The hw supports async flips through the render ring, so why not expose it?
It gives us one more tear me harder option we can use in the DDX and
for other cases where simply
Frederic Plourde frederic.plou...@collabora.co.uk writes:
From: Tomeu Vizoso tomeu.viz...@collabora.com
When i915 driver decides to fallback to software, the texture's Map
gets replaced by its Buffer attribute, which is NULL because the
texture hasn't been allocated by swrast yet.
The
Jesse Barnes jbar...@virtuousgeek.org writes:
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
So, these days if you go to render to a buffer that's been flipped from,
your rendering gets stalled (since the buffer may still be scanned out
when the rendering starts happening), which is the
ville.syrj...@linux.intel.com writes:
From: Ville Syrjälä ville.syrj...@linux.intel.com
As per Chris Wilson's suggestion make
i915_gem_execbuffer_wait_for_flips() go away.
This was used to stall the GPU ring while there are pending
page flips involving the relevant BO. Ie. while the BO is
Chris Wilson ch...@chris-wilson.co.uk writes:
With the introduction of per-process GTT space, the hardware designers
thought it wise to also limit the ability to write to MMIO space to only
a secure batch buffer. The ability to rewrite registers is the only
way to program the hardware to
Jesse Barnes jbar...@virtuousgeek.org writes:
On Fri, 12 Oct 2012 11:34:08 -0700
Eric Anholt e...@anholt.net wrote:
Jesse Barnes jbar...@virtuousgeek.org writes:
On Tue, 09 Oct 2012 13:05:54 -0700
Eric Anholt e...@anholt.net wrote:
On my new MBA with danvet's drm-intel-next-queued
Jesse Barnes jbar...@virtuousgeek.org writes:
On Tue, 09 Oct 2012 13:05:54 -0700
Eric Anholt e...@anholt.net wrote:
On my new MBA with danvet's drm-intel-next-queued, I'm not getting
working RPS. vblank_mode=0 glxgears never ups the frequency, and
vblank_mode=0 openarena only makes it up
On my new MBA with danvet's drm-intel-next-queued, I'm not getting
working RPS. vblank_mode=0 glxgears never ups the frequency, and
vblank_mode=0 openarena only makes it up to 500mhz. Reverting
1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c gets the machine to responsive
RPS: fully on while the GPU is
Daniel Vetter dan...@ffwll.ch writes:
On Sun, Oct 07, 2012 at 08:38:07AM +0200, Mario Kleiner wrote:
Hi,
a series of three patches to improve the dri2 swap scheduling
and timestamping for the current intel ddx.
The first one enables proper OML_sync_control timestamping
while
Imre Deak imre.d...@intel.com writes:
This is needed to make applications depending on vblank/page flip
timestamps independent of time ajdustments.
I've tested these with an updated intel-gpu-test/flip_test and will send
the update for that once there's no objection about this patchset.
Kenneth Graunke kenn...@whitecape.org writes:
Reviewed-by: Eric Anholt e...@anholt.net
pgpynlVfLMSOQ.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Ben Widawsky b...@bwidawsk.net writes:
On 2012-08-02 11:29, Eric Anholt wrote:
Yikes, who spelled caching wrong?
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Yeah, would be nice to get that fixed in the kernel before we have to
cringe forever.
pgpR6HO5ph125.pgp
Description: PGP signature
It warns about totally sensible things done in intel_decode.c. I've
never seen this warn do anything useful, and apparently I was the one
to introduce it when I added the giant pile of warning flags back in
2008.
---
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Olivier Galibert galib...@pobox.com writes:
On Mon, Jul 30, 2012 at 10:30:57AM -0700, Eric Anholt wrote:
I'm perfectly fine with the VUE containing slots for both when the app
has gone out of its way to ask for deprecated two-sided color
rendering.
Are you also ok with recompiler
somewhere else.
Fixes reproducible failures with GL_EXT_timer_query usage in apitrace,
and I also expect it to fix the intermittent OQ issues on snb that
danvet's been working on.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48019
Signed-off-by: Eric Anholt e...@anholt.net
Reviewed-by: Chris
Olivier Galibert galib...@pobox.com writes:
On Tue, Jul 17, 2012 at 07:37:43AM -0700, Paul Berry wrote:
If possible, I would still like to think of a way to address this situation
that (a) doesn't require modifying both fragment shader back-ends and the
SF program, and (b) helps all Mesa
with cworth, I'm
pretty sure this will fix his reproducible GL_EXT_timer_query
failures, and hopefully the intermittent OQ issues on snb that
danvet's been working on.
I have not tested it yet, but hopefully when cworth gets home he will.
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915
drm_i915_gem_context_create create;
- drm_i915_getparam_t gp;
drm_intel_context *context = NULL;
- int tmp = 0, ret;
+ int ret;
Oops, I never sent out my copy of this patch.
Reviewed-by: Eric Anholt e...@anholt.net
pgpMW0W7H6vTB.pgp
Description: PGP signature
the urb offset for each. But
this does look like the minimal fix.
Reviewed-by: Eric Anholt e...@anholt.net
pgp5F8dGu9BYv.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
Olivier Galibert galib...@pobox.com writes:
Previous code only selected two side in pure fixed-function setups.
This version also activates it when needed with shaders programs.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_sf.c |2 +-
1 file
Olivier Galibert galib...@pobox.com writes:
The program keys are updated accordingly, but the values are not used
yet.
Signed-off-by: Olivier Galibert galib...@pobox.com
---
src/mesa/drivers/dri/i965/brw_clip.c| 90
++-
Daniel Vetter daniel.vet...@ffwll.ch writes:
We don't yet use this, but now that we start to look into putting that
l3$ we better set the associated flush bit, too.
Also add the only other missing PIPE_CONTROL bit #define.
Reviewed-by: Eric Anholt e...@anholt.net
pgpmuUosTUjO0.pgp
Fixes failures in transform feedback on gen7 because our SOL_RESET
flag was setting the transform feedback offsets in the old context
(occasionally happened to be ours) instead of the new context.
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |8
Olivier Galibert galib...@pobox.com writes:
Shaders, piglit test ones in particular, may write only to one of
gl_FrontColor/gl_BackColor. The standard is unclear on whether the
behaviour is defined in that case, but it seems reasonable to support
it.
The choice done there to pick up
Chris Wilson ch...@chris-wilson.co.uk writes:
Enabling context support increases SwapBuffers latency by about 20%
(measured on an i7-3720qm). We can offset that loss slightly by enabling
faster caching for the contexts. As they are not backed by any
particular cache (such as the sampler or
Chris Wilson ch...@chris-wilson.co.uk writes:
On Mon, 18 Jun 2012 10:35:54 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, May 04, 2012 at 06:58:59PM -0700, Ben Widawsky wrote:
I'm seeing about a 5% FPS improvement across various benchmarks on my
IVB i3. Rumor has it that the higher end
0x30
Is 0x2f some other outstanding ioctl?
Other than that,
Reviewed-by: Eric Anholt e...@anholt.net
Note: we have requests both by Arjan and by Valve for the functionality
that this patch will allow.
pgpaSxAYjLYft.pgp
Description: PGP signature
Ben Widawsky b...@bwidawsk.net writes:
The interface's immediate purpose is to do synchronous timestamp queries
as required by GL_TIMESTAMP. The GPU has a register for reading the
timestamp but because that would normally require root access, the
IOCTL can provide this service.
Currently
workaround), simply disable the ring.
v2: Add a message to inform the user about the limited capabilities of
their pre-production hardware.
Where by performance will be degraded we mean GL won't work. :)
Still, better than just trying to blindly continue on.
Reviewed-by: Eric Anholt e...@anholt.net
Chris Wilson ch...@chris-wilson.co.uk writes:
It never quite worked despite the numerous workarounds, yet I still see
people trying to use this hardware and filing bug reports. As we no
longer even try to implement the workarounds, since 6a233c78878
(drm/i915/ringbuffer: kill snb blt
On Tue, 12 Jun 2012 12:35:37 +0200, Olivier Galibert galib...@pobox.com wrote:
Hi guys,
I'm playing with my gm45, and trying to understand the inter-shader
register allocation and referencing aspects. From what I see, the vs
and clipper follow the brw_vue_map to know where data is. The
101 - 200 of 511 matches
Mail list logo
