Here's a new release, featuring updated i915_drm.h for gen7 transform feedback, and intel_decode.c as a library API instead of being copied around between our various driver components.
Chris Wilson (2): intel: Reset vma list upon purge tests/gem_flink: Check for MASTER before proceeding
Eric Anholt (18): intel: Import intel_decode.c from intel-gpu-tools. intel: Make intel_chipset handle devid directly. intel: intel: Add IS_GEN[567] macros. intel: Reformat intel_decode.c from intel-gpu-tools using Lindent. intel: Minor style tweaks after Lindent. intel: Get intel_decode.c minimally building. intel: Fix Wsigned-compare warnings (soon to be enabled). intel: Fix a ton of signed vs unsigned and const char *warnings intel: Add printflike warnings for instr_out. intel: Fix printf format warnings for intel_decode. intel: Remove c99ish variable declarations. intel: Turn on normal warnings for intel_decode.c build. intel: Disable unused decode_logic_op(). intel: Add an interface for setting the output file for decode. intel: Add a regression test program for intel_decode.c. intel: Add regression tests for batch decode. intel: Update for new i915_drm.h defines. configure: Bump version for 2.4.30
Jesse Barnes (1): libdrm: update drm headers from kernel, including new overlay ioctls & structs
Johannes Obermayr (1): intel/intel_decode.c: Remove #include "intel_decode.h".
git tag: 2.4.30
http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.bz2 MD5: 9f57a68b2c0836b55ebcbc241f6ca175 libdrm-2.4.30.tar.bz2 SHA1: 5ba36a0bcbacbe67e6a2e0d5318ed9455da59bbc libdrm-2.4.30.tar.bz2 SHA256: cacea9c157ec824ad278a06f4910659b2f3ae69686518ece8d6967843cddcd56 libdrm-2.4.30.tar.bz2
http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.gz MD5: cd790fb761a83125eceb64162d7d5ce5 libdrm-2.4.30.tar.gz SHA1: 148936f0c0f83d016c584245493b975d42bd359a libdrm-2.4.30.tar.gz SHA256: a64e63a2af08bcab835e758048611cf61c7183dc7e829cad9dceba859245b4bc libdrm-2.4.30.tar.gz
This new libdrm fails 'make check' on tinderbox: http://tinderbox.x.org/builds/2012-01-07-0023/logs/libdrm/#check
On Jan 6, 2012, at 8:54 AM, Eric Anholt wrote:
Here's a new release, featuring updated i915_drm.h for gen7 transform feedback, and intel_decode.c as a library API instead of being copied around between our various driver components.
Chris Wilson (2): intel: Reset vma list upon purge tests/gem_flink: Check for MASTER before proceeding
Eric Anholt (18): intel: Import intel_decode.c from intel-gpu-tools. intel: Make intel_chipset handle devid directly. intel: intel: Add IS_GEN[567] macros. intel: Reformat intel_decode.c from intel-gpu-tools using Lindent. intel: Minor style tweaks after Lindent. intel: Get intel_decode.c minimally building. intel: Fix Wsigned-compare warnings (soon to be enabled). intel: Fix a ton of signed vs unsigned and const char *warnings intel: Add printflike warnings for instr_out. intel: Fix printf format warnings for intel_decode. intel: Remove c99ish variable declarations. intel: Turn on normal warnings for intel_decode.c build. intel: Disable unused decode_logic_op(). intel: Add an interface for setting the output file for decode. intel: Add a regression test program for intel_decode.c. intel: Add regression tests for batch decode. intel: Update for new i915_drm.h defines. configure: Bump version for 2.4.30
Jesse Barnes (1): libdrm: update drm headers from kernel, including new overlay ioctls & structs
Johannes Obermayr (1): intel/intel_decode.c: Remove #include "intel_decode.h".
git tag: 2.4.30
http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.bz2 MD5: 9f57a68b2c0836b55ebcbc241f6ca175 libdrm-2.4.30.tar.bz2 SHA1: 5ba36a0bcbacbe67e6a2e0d5318ed9455da59bbc libdrm-2.4.30.tar.bz2 SHA256: cacea9c157ec824ad278a06f4910659b2f3ae69686518ece8d6967843cddcd56 libdrm-2.4.30.tar.bz2
http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.gz MD5: cd790fb761a83125eceb64162d7d5ce5 libdrm-2.4.30.tar.gz SHA1: 148936f0c0f83d016c584245493b975d42bd359a libdrm-2.4.30.tar.gz SHA256: a64e63a2af08bcab835e758048611cf61c7183dc7e829cad9dceba859245b4bc libdrm-2.4.30.tar.gz
xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
On Sat, 07 Jan 2012 11:22:52 -0800, Jeremy Huddleston jeremyhu@apple.com wrote:
This new libdrm fails 'make check' on tinderbox: http://tinderbox.x.org/builds/2012-01-07-0023/logs/libdrm/#check
It make checks fine here, on 32 and 64. Not sure what's up.
Well that's a ppc box, so maybe endianness issues... ?
On Jan 7, 2012, at 6:49 PM, Eric Anholt wrote:
On Sat, 07 Jan 2012 11:22:52 -0800, Jeremy Huddleston jeremyhu@apple.com wrote:
This new libdrm fails 'make check' on tinderbox: http://tinderbox.x.org/builds/2012-01-07-0023/logs/libdrm/#check
It make checks fine here, on 32 and 64. Not sure what's up.
On Sun, 08 Jan 2012 00:48:56 -0800, Jeremy Huddleston jeremyhu@apple.com wrote:
Well that's a ppc box, so maybe endianness issues... ?
Oh, that's probably it. But I'd say it's more a bug that Intel libdrm is being built on ppc.
libdrm is still failing 'make check':
Linux/ppc - http://tinderbox.x.org/builds/2012-01-28-0007/logs/libdrm/#check Linux/ppc64 - http://tinderbox.x.org/builds/2012-01-28-0013/logs/libdrm/#check
I bisected it to the commit below (which added the failing tests). Are these tests broken? Can they please be disabled until they are working?
683855f65523c978562ead56f9d68f50ffdca1a2 is the first bad commit commit 683855f65523c978562ead56f9d68f50ffdca1a2 Author: Eric Anholt eric@anholt.net Date: Tue Jan 3 14:32:18 2012 -0800
intel: Add regression tests for batch decode.
The .batch was generated using the dump-a-batch branch of
git://people.freedesktop.org/~anholt/mesa
using glxgears on gen7 hardware, using INTEL_DEVID_OVERRIDE for non-gen7 (this means that offsets in the buffers for non-gen7 are 0!). The .ref was generated by:
./test_decode tests/gen7-3d.batch -dump.
The .sh exists because you can't supply arguments to tests using the simple automake tests driver. Something reasonable could be done using automake's parallel-tests driver (in fact, a previous version of the patch did that), but I was concerned that:
1) The parallel-tests driver is documented to be unstable -- they may change interfaces on us later. 2) The parallel-tests driver hides the output of tests in .log files scattered all over the tree, which was ugly and more painful to work with.
v2: Actually add the batch files, add a .gitignore for the *-new.txt files added after failures, and fix failure mode for undetected chipset name. Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch (v1)
:040000 040000 0154ee50d82d218ae87cacbb4fd7dbc45bc1e0cb de793dcf57aa48470928f754c6f5dbb4a123253f M intel
$ git bisect log git bisect start # good: [7fd1678110b78d9324723a54dfd5049496b9e3cf] configure: Bump version for 2.4.29 git bisect good 7fd1678110b78d9324723a54dfd5049496b9e3cf # bad: [b643b0713aefdc0611e47654e88263b53b0de6f5] intel: Add minimal decode for remaining gen7 packets in use. git bisect bad b643b0713aefdc0611e47654e88263b53b0de6f5 # bad: [683855f65523c978562ead56f9d68f50ffdca1a2] intel: Add regression tests for batch decode. git bisect bad 683855f65523c978562ead56f9d68f50ffdca1a2 # skip: [07768babb81bf8b9b993c41e7dca1e011fd6bd69] intel: Fix Wsigned-compare warnings (soon to be enabled). git bisect skip 07768babb81bf8b9b993c41e7dca1e011fd6bd69 # good: [a9dd34a7ee9d03d357e15f045ab85a12f6f6e4b8] intel/intel_decode.c: Remove #include "intel_decode.h". git bisect good a9dd34a7ee9d03d357e15f045ab85a12f6f6e4b8 # good: [ccbc40340b7b472939a90ae8afc0a82b358ce189] intel: Add a regression test program for intel_decode.c. git bisect good ccbc40340b7b472939a90ae8afc0a82b358ce189
On Jan 7, 2012, at 11:22, Jeremy Huddleston wrote:
This new libdrm fails 'make check' on tinderbox: http://tinderbox.x.org/builds/2012-01-07-0023/logs/libdrm/#check
On Jan 6, 2012, at 8:54 AM, Eric Anholt wrote:
Here's a new release, featuring updated i915_drm.h for gen7 transform feedback, and intel_decode.c as a library API instead of being copied around between our various driver components.
Chris Wilson (2): intel: Reset vma list upon purge tests/gem_flink: Check for MASTER before proceeding
Eric Anholt (18): intel: Import intel_decode.c from intel-gpu-tools. intel: Make intel_chipset handle devid directly. intel: intel: Add IS_GEN[567] macros. intel: Reformat intel_decode.c from intel-gpu-tools using Lindent. intel: Minor style tweaks after Lindent. intel: Get intel_decode.c minimally building. intel: Fix Wsigned-compare warnings (soon to be enabled). intel: Fix a ton of signed vs unsigned and const char *warnings intel: Add printflike warnings for instr_out. intel: Fix printf format warnings for intel_decode. intel: Remove c99ish variable declarations. intel: Turn on normal warnings for intel_decode.c build. intel: Disable unused decode_logic_op(). intel: Add an interface for setting the output file for decode. intel: Add a regression test program for intel_decode.c. intel: Add regression tests for batch decode. intel: Update for new i915_drm.h defines. configure: Bump version for 2.4.30
Jesse Barnes (1): libdrm: update drm headers from kernel, including new overlay ioctls & structs
Johannes Obermayr (1): intel/intel_decode.c: Remove #include "intel_decode.h".
git tag: 2.4.30
http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.bz2 MD5: 9f57a68b2c0836b55ebcbc241f6ca175 libdrm-2.4.30.tar.bz2 SHA1: 5ba36a0bcbacbe67e6a2e0d5318ed9455da59bbc libdrm-2.4.30.tar.bz2 SHA256: cacea9c157ec824ad278a06f4910659b2f3ae69686518ece8d6967843cddcd56 libdrm-2.4.30.tar.bz2
http://dri.freedesktop.org/libdrm/libdrm-2.4.30.tar.gz MD5: cd790fb761a83125eceb64162d7d5ce5 libdrm-2.4.30.tar.gz SHA1: 148936f0c0f83d016c584245493b975d42bd359a libdrm-2.4.30.tar.gz SHA256: a64e63a2af08bcab835e758048611cf61c7183dc7e829cad9dceba859245b4bc libdrm-2.4.30.tar.gz
xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
On Sat, 28 Jan 2012 12:57:10 -0800, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
libdrm is still failing 'make check':
Linux/ppc - http://tinderbox.x.org/builds/2012-01-28-0007/logs/libdrm/#check Linux/ppc64 - http://tinderbox.x.org/builds/2012-01-28-0013/logs/libdrm/#check
I bisected it to the commit below (which added the failing tests). Are these tests broken? Can they please be disabled until they are working?
Not just the tests, but the whole intel DRM implementation should be disabled on non-intel architectures. I don't have any myself -- care to try it on your own? Or I could try to blindly write a patch for you to try.
Maybe I'm missing something here...
Shouldn't I be able to build and test support for Intel even if I've got an nVidia card in my box now? Or is this support for Intel CPUs rather than Intel GPUs?
On Jan 28, 2012, at 17:55, Eric Anholt wrote:
On Sat, 28 Jan 2012 12:57:10 -0800, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
libdrm is still failing 'make check':
Linux/ppc - http://tinderbox.x.org/builds/2012-01-28-0007/logs/libdrm/#check Linux/ppc64 - http://tinderbox.x.org/builds/2012-01-28-0013/logs/libdrm/#check
I bisected it to the commit below (which added the failing tests). Are these tests broken? Can they please be disabled until they are working?
Not just the tests, but the whole intel DRM implementation should be disabled on non-intel architectures. I don't have any myself -- care to try it on your own? Or I could try to blindly write a patch for you to try.
On Sun, Jan 29, 2012 at 04:30, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
Maybe I'm missing something here...
Shouldn't I be able to build and test support for Intel even if I've got an nVidia card in my box now? Or is this support for Intel CPUs rather than Intel GPUs?
The issue is that we pretty much assume that the code runs on a little-endian machine - which is the reason the tests are failing for you on ppc. I'm with Eric that the most sensible thing to do here is to disable building the intel libdrm (and runnning its test) entirely on anything not x86 or from intel. My autofu isn't really up to snuff for that though :( -Daniel
Ok, well I'll give it a shot then. I've dealt with enough autoconf to make a decent first pass.
On Jan 29, 2012, at 04:16, Daniel Vetter wrote:
On Sun, Jan 29, 2012 at 04:30, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
Maybe I'm missing something here...
Shouldn't I be able to build and test support for Intel even if I've got an nVidia card in my box now? Or is this support for Intel CPUs rather than Intel GPUs?
The issue is that we pretty much assume that the code runs on a little-endian machine - which is the reason the tests are failing for you on ppc. I'm with Eric that the most sensible thing to do here is to disable building the intel libdrm (and runnning its test) entirely on anything not x86 or from intel. My autofu isn't really up to snuff for that though :(
-Daniel
Daniel Vetter daniel.vetter@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Sat, 28 Jan 2012 19:30:39 -0800, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
Maybe I'm missing something here...
Shouldn't I be able to build and test support for Intel even if I've got an nVidia card in my box now? Or is this support for Intel CPUs rather than Intel GPUs?
Intel GPUs only exist on Intel CPUs (or bridge chipsets).
This fixes a failure in 'make check' found by the tinderbox when trying to build this code on Linux/ppc. This code is only designed to run on Intel platforms, so don't even bother building it if we're not in that set.
Found-by: Tinderbox Signed-off-by: Jeremy Huddleston jeremyhu@apple.com ---
It now causes the intel bits to not build on my Linux/ppc tinderbox, but I'd appreciate someone verifying that it does the right thing on intel boxes as well.
configure.ac | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac index 773167f..f5ebc1d 100644 --- a/configure.ac +++ b/configure.ac @@ -250,7 +250,10 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno"; then
else if test "x$INTEL" != "xno"; then - INTEL=yes + case $host_os in + i?86-*|x86_64-*) INTEL=yes ;; + *) INTEL=no ;; + esac fi if test "x$RADEON" != "xno"; then RADEON=yes
On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
This fixes a failure in 'make check' found by the tinderbox when trying to build this code on Linux/ppc. This code is only designed to run on Intel platforms, so don't even bother building it if we're not in that set.
Looks reasonable to me, except it should probably be checking $target_os (cross-compile target) rather than $host_os (cross compile build host).
On Jan 31, 2012, at 8:59 AM, Eric Anholt wrote:
On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
This fixes a failure in 'make check' found by the tinderbox when trying to build this code on Linux/ppc. This code is only designed to run on Intel platforms, so don't even bother building it if we're not in that set.
Looks reasonable to me, except it should probably be checking $target_os (cross-compile target) rather than $host_os (cross compile build host).
I think you are misunderstanding the variables (or perhaps you are following Mozilla's usage of the variables, which is wrong but internally consistent).
CBUILD - The platform of the machine being built on. CHOST - The platform that the delivered product will run on. CTARGET- The platform that the delivered product will generate code for.
CTARGET is only really relevant for toolchain packages.
eg. I want to build a gcc that builds mips code and runs on my intel box: CTARGET=mips-* CHOST=i686-*
If I want to do the building of that compiler on my ppc box: CBUILD=powerpc-* CTARGET=mips-* CHOST=i686-*
--Jeremy
On Tue, 31 Jan 2012 10:34:38 -0800, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
On Jan 31, 2012, at 8:59 AM, Eric Anholt wrote:
On Mon, 30 Jan 2012 15:25:20 -0800, Jeremy Huddleston jeremyhu@freedesktop.org wrote:
This fixes a failure in 'make check' found by the tinderbox when trying to build this code on Linux/ppc. This code is only designed to run on Intel platforms, so don't even bother building it if we're not in that set.
Looks reasonable to me, except it should probably be checking $target_os (cross-compile target) rather than $host_os (cross compile build host).
I think you are misunderstanding the variables (or perhaps you are following Mozilla's usage of the variables, which is wrong but internally consistent).
You're right. And that was with me looking up information on these variables before mailing last time. :(
On Mon, Jan 30, 2012 at 15:25:20 -0800, Jeremy Huddleston wrote:
This fixes a failure in 'make check' found by the tinderbox when trying to build this code on Linux/ppc. This code is only designed to run on Intel platforms, so don't even bother building it if we're not in that set.
Found-by: Tinderbox Signed-off-by: Jeremy Huddleston jeremyhu@apple.com
It now causes the intel bits to not build on my Linux/ppc tinderbox, but I'd appreciate someone verifying that it does the right thing on intel boxes as well.
configure.ac | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac index 773167f..f5ebc1d 100644 --- a/configure.ac +++ b/configure.ac @@ -250,7 +250,10 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno"; then
else if test "x$INTEL" != "xno"; then
INTEL=yes
case $host_os ini?86-*|x86_64-*) INTEL=yes ;;*) INTEL=no ;;esac fi
don't you want to check host_cpu rather than host_os?
Cheers, Julien
yeah, that's probably cleaner (I guess it'll avoid the -*), but it should have the same effect.
I'll make the change.
On Feb 1, 2012, at 12:43 PM, Julien Cristau wrote:
On Mon, Jan 30, 2012 at 15:25:20 -0800, Jeremy Huddleston wrote:
This fixes a failure in 'make check' found by the tinderbox when trying to build this code on Linux/ppc. This code is only designed to run on Intel platforms, so don't even bother building it if we're not in that set.
Found-by: Tinderbox Signed-off-by: Jeremy Huddleston jeremyhu@apple.com
It now causes the intel bits to not build on my Linux/ppc tinderbox, but I'd appreciate someone verifying that it does the right thing on intel boxes as well.
configure.ac | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac index 773167f..f5ebc1d 100644 --- a/configure.ac +++ b/configure.ac @@ -250,7 +250,10 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno"; then
else if test "x$INTEL" != "xno"; then
INTEL=yes
case $host_os ini?86-*|x86_64-*) INTEL=yes ;;*) INTEL=no ;;esac fidon't you want to check host_cpu rather than host_os?
Cheers, Julien
On Wed, Feb 1, 2012 at 13:01:58 -0800, Jeremy Huddleston wrote:
yeah, that's probably cleaner (I guess it'll avoid the -*), but it should have the same effect.
I get host_os=linux-gnu here afaict, so not really the same effect, no.
Cheers, Julien
On Feb 1, 2012, at 1:56 PM, Julien Cristau wrote:
On Wed, Feb 1, 2012 at 13:01:58 -0800, Jeremy Huddleston wrote:
yeah, that's probably cleaner (I guess it'll avoid the -*), but it should have the same effect.
I get host_os=linux-gnu here afaict, so not really the same effect, no.
Weird. I had powerpc-linux-gnu when I checked it earlier ... maybe my mind is playing tricks on me...
On 02/ 1/12 01:56 PM, Julien Cristau wrote:
On Wed, Feb 1, 2012 at 13:01:58 -0800, Jeremy Huddleston wrote:
yeah, that's probably cleaner (I guess it'll avoid the -*), but it should have the same effect.
I get host_os=linux-gnu here afaict, so not really the same effect, no.
Jeremy was probably thinking of $host, which has both the os & cpu in, but this was already fixed in libdrm git last night when people on IRC noticed that the Intel drm module stopped building on x86 systems.
commit 82c6938d232327233caac743a07639ac91bceb7e Author: Paul Berry stereotype441@gmail.com Date: Tue Jan 31 14:44:14 2012 -0800
intel: Fix build of Intel DRM on x86 systems
Commit efd6e81e inadvertently broke the build by looking for "i?86" or "x86_64" in $host_os. The correct variable to check is $host_cpu.
This was preventing libdrm_intel.so from being built.
Reviewed-by: Chad Versace chad.versace@linux.intel.com
diff --git a/configure.ac b/configure.ac index f5ebc1d..b59bc54 100644 --- a/configure.ac +++ b/configure.ac @@ -250,8 +250,8 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno"; then
else if test "x$INTEL" != "xno"; then - case $host_os in - i?86-*|x86_64-*) INTEL=yes ;; + case $host_cpu in + i?86|x86_64) INTEL=yes ;; *) INTEL=no ;; esac fi
dri-devel@lists.freedesktop.org
-
Alan Coopersmith -
Daniel Vetter -
Eric Anholt -
Jeremy Huddleston -
Jeremy Huddleston -
Julien Cristau