Bug#769518: Fwd: [Bug 86281] brw_meta_fast_clear (brw=brw@entry=0x7fffd4097a08, fb=fb@entry=0x7fffd40fa900, buffers=buffers@entry=2, partial_clear=partial_clear@entry=false)
Control: tags -1 confirmed upstream Not marking as patch, but this is a work-around: -- Forwarded message -- Comment # 39 on bug 86281 from Martin Peres This patch should be a good workaround: http://cgit.freedesktop.org/~ickle/mesa/commit/?h=brw-batch&id=e2a696a4cd93c2dbe445243de48ed478fbdb8009 I will test it tonight on my home machine and see if I can reproduce it. The patch may make the screen flicker for a frame instead of crashing. The actual problem is a race condition of DRI2 that is not trivial to fix.
Processed: Fwd: [Bug 86281] brw_meta_fast_clear (brw=brw@entry=0x7fffd4097a08, fb=fb@entry=0x7fffd40fa900, buffers=buffers@entry=2, partial_clear=partial_clear@entry=false)
Processing control commands: > tags -1 confirmed upstream Bug #769518 [libgl1-mesa-dri] libgl1-mesa-dri: Failed to open BO for returned DRI2 buffer (1680x1050, dri2 back buffer, named 18) Added tag(s) upstream and confirmed. -- 769518: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769518 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
[RFC] Embed the mesa version in the library/binary name
Hello all, My name is Emil and I'm the person breaking^w fixing mesa's build amongst others. A while back I had this idea of renaming the libraries provided by mesa to include the actual version number. Prior to doing anything "crazy" I've decided to seek your feedback. * What The idea is to rename (ideally) all of the versioned libraries. Unversioned ones such as radeonsi_dri.so will remain as is. Note: the soname and symlinks will stay to avoid breaking compatibility. * How While I haven't fully decided on the exact approach I'm thinking of something like: libGL.so.1.0.0 -> libGL.so.11.0 or libGL.so.110.1 or libGL.so.11.01 Other suggestions and ideas are welcome but please keep the version to X.Y * Why A number of reasons: - The binary driver by Nvidia has been using this approach for years. - It provides quick and easy feedback in traces - In most cases, one can easily establish if the distro provided library is overwritten. - Allows multiple binaries to coexist, making the dynamic switching between libGL.so.110.1, libGL.so.11.2.0 (mesa), libGL.so.352.14 (nvidia) libGL.so.XX.Y (another vendor) a little bit easier. - OpenBSD, Solaris(?) use sunos 4 style versioning -> .so.major.minor How does this sound, do you foresee any pros/cons with the above proposal ? Any and all input is greatly appreciated, but please try to keep your replies technical and constructive. If there are any concerns wrt the required updates (of the build/packaging recipes) I'm willing to help out. As I'm not sure how many of you follow mesa-dev, would you be OK if I CC you in distro related~ish topics. Some (not so crazy) examples: - libEGL.so has additional dependency (via libdl) of X - OpenCL only works with render node devices, kernel vY or later is required - Mesa's new library libfoo.so should be shipped with libbar.so Thanks Emil
libdrm: Changes to 'upstream-unstable'
.gitignore |2
Makefile.am |6
Makefile.sources|5
amdgpu/Makefile.am | 57 +
amdgpu/amdgpu-symbol-check | 51 +
amdgpu/amdgpu.h | 1178 ++
amdgpu/amdgpu_bo.c | 705 +++
amdgpu/amdgpu_cs.c | 372
amdgpu/amdgpu_device.c | 274 ++
amdgpu/amdgpu_gpu_info.c| 310 ++
amdgpu/amdgpu_internal.h| 190
amdgpu/amdgpu_vamgr.c | 288 ++
amdgpu/libdrm_amdgpu.pc.in | 10
amdgpu/util_hash.c | 387
amdgpu/util_hash.h | 107 ++
amdgpu/util_hash_table.c| 262 +
amdgpu/util_hash_table.h| 73 +
configure.ac| 48 +
freedreno/Makefile.sources |3
freedreno/freedreno_bo.c|6
freedreno/freedreno_priv.h |2
freedreno/kgsl/kgsl_bo.c|1
freedreno/kgsl/kgsl_pipe.c |2
freedreno/list.h| 137 ---
freedreno/msm/msm_bo.c |1
include/drm/amdgpu_drm.h| 645 ++
intel/intel_bufmgr.h|8
intel/intel_bufmgr_gem.c| 414 -
intel/test_decode.c |2
libkms/libkms.h |4
libkms/linux.c |4
man/Makefile.am | 11
omap/omap_drm.c |4
radeon/r600_pci_ids.h |1
tests/Makefile.am | 12
tests/amdgpu/Makefile.am| 29
tests/amdgpu/amdgpu_test.c | 222 +
tests/amdgpu/amdgpu_test.h | 236 +
tests/amdgpu/basic_tests.c | 838 ++
tests/amdgpu/bo_tests.c | 181
tests/amdgpu/cs_tests.c | 387
tests/amdgpu/frame.h| 1949
tests/amdgpu/uvd_messages.h | 813 ++
tests/amdgpu/vce_ib.h | 318 +++
tests/amdgpu/vce_tests.c| 489 +++
tests/kmstest/main.c|1
tests/modeprint/modeprint.c |4
tests/name_from_fd.c|2
tests/radeon/Makefile.am|1
tests/radeon/list.h | 137 ---
tests/radeon/rbo.h |2
util_double_list.h | 137 +++
util_math.h | 33
xf86drm.c | 28
xf86drm.h | 11
xf86drmMode.c | 30
xf86drmMode.h |4
57 files changed, 10725 insertions(+), 709 deletions(-)
New commits:
commit f045da45fee94a7179cced09a20b691c5167cef4
Author: Marek Olšák
Date: Fri Aug 14 14:19:29 2015 +0200
Bump version for release
diff --git a/configure.ac b/configure.ac
index 81e0f80..e2a2f16 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
AC_PREREQ([2.63])
AC_INIT([libdrm],
-[2.4.62],
+[2.4.63],
[https://bugs.freedesktop.org/enter_bug.cgi?product=DRI],
[libdrm])
commit 15350568ccae525899aeb963f1cb66287e876e63
Author: Emil Velikov
Date: Fri Aug 7 17:29:11 2015 +0100
amdgpu: add symbols check test
Signed-off-by: Emil Velikov
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
index 82e78c7..ed97803 100644
--- a/amdgpu/Makefile.am
+++ b/amdgpu/Makefile.am
@@ -52,3 +52,6 @@ libdrm_amdgpuinclude_HEADERS = \
pkgconfigdir = @pkgconfigdir@
pkgconfig_DATA = libdrm_amdgpu.pc
+
+TESTS = amdgpu-symbol-check
+EXTRA_DIST = $(TESTS)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
new file mode 100755
index 000..9a0b36c
--- /dev/null
+++ b/amdgpu/amdgpu-symbol-check
@@ -0,0 +1,51 @@
+#!/bin/bash
+
+# The following symbols (past the first five) are taken from the public
headers.
+# A list of the latter should be available
Makefile.am/libdrm_amdgpuinclude_HEADERS
+
+FUNCS=$(nm -D --format=bsd --defined-only ${1-.libs/libdrm_amdgpu.so} | awk
'{print $3}' | while read func; do
+( grep -q "^$func$" || echo $func ) <
Date: Fri Aug 7 17:09:35 2015 +0100
amdgpu: hide the final internal functions from global namespace
Thus the only symbols that we export are the ones officially provided by
the API.
Signed-off-by: Emil Velikov
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
Reviewed-by: Jammy Zhou
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index aacb42c..7607f2c 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -53,7 +53,7 @@ static void amdgpu_close_kms_handle(amdgpu_device_handle dev,
drmIoctl(dev->fd, DRM_IOCTL_GEM_CLOSE, &args);
}
-void amdgpu_bo_free_internal(amdgpu_bo_handle bo)
+drm_private void amdgpu_bo_free_internal(amdgpu_bo_handle bo)
{
/* Remove the buffer from the hash tables. */
pthread_mutex_lock(&bo->dev->bo_table_mutex);
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index fd28bd9..ea35326 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -290,7 +290,7 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
*
*
libdrm: Changes to 'debian-unstable'
.gitignore |2 Makefile.am|6 Makefile.sources |5 amdgpu/Makefile.am | 57 amdgpu/amdgpu-symbol-check | 51 amdgpu/amdgpu.h| 1178 +++ amdgpu/amdgpu_bo.c | 705 amdgpu/amdgpu_cs.c | 372 ++ amdgpu/amdgpu_device.c | 274 + amdgpu/amdgpu_gpu_info.c | 310 ++ amdgpu/amdgpu_internal.h | 190 + amdgpu/amdgpu_vamgr.c | 288 + amdgpu/libdrm_amdgpu.pc.in | 10 amdgpu/util_hash.c | 387 ++ amdgpu/util_hash.h | 107 amdgpu/util_hash_table.c | 262 + amdgpu/util_hash_table.h | 73 configure.ac | 46 debian/changelog |8 debian/control | 32 debian/libdrm-amdgpu1.install |1 debian/libdrm-amdgpu1.symbols | 35 debian/patches/Fix-headers-inclusion-in-xf86drmMode.c.diff | 39 debian/patches/series |1 debian/rules |4 freedreno/Makefile.sources |3 freedreno/freedreno_bo.c |6 freedreno/freedreno_priv.h |2 freedreno/kgsl/kgsl_bo.c |1 freedreno/kgsl/kgsl_pipe.c |2 freedreno/list.h | 137 freedreno/msm/msm_bo.c |1 include/drm/amdgpu_drm.h | 645 intel/intel_bufmgr.h |8 intel/intel_bufmgr_gem.c | 414 -- intel/test_decode.c|2 libkms/libkms.h|4 libkms/linux.c |4 man/Makefile.am| 11 omap/omap_drm.c|4 radeon/r600_pci_ids.h |1 tests/Makefile.am | 12 tests/amdgpu/Makefile.am | 29 tests/amdgpu/amdgpu_test.c | 222 + tests/amdgpu/amdgpu_test.h | 236 + tests/amdgpu/basic_tests.c | 838 + tests/amdgpu/bo_tests.c| 181 + tests/amdgpu/cs_tests.c| 387 ++ tests/amdgpu/frame.h | 1949 + tests/amdgpu/uvd_messages.h| 813 + tests/amdgpu/vce_ib.h | 318 ++ tests/amdgpu/vce_tests.c | 489 +++ tests/kmstest/main.c |1 tests/modeprint/modeprint.c|4 tests/name_from_fd.c |2 tests/radeon/Makefile.am |1 tests/radeon/list.h| 137 tests/radeon/rbo.h |2 util_double_list.h | 137 util_math.h| 33 xf86drm.c | 28 xf86drm.h | 11 xf86drmMode.c | 30 xf86drmMode.h |4 64 files changed, 10804 insertions(+), 748 deletions(-) New commits: commit d89c15de45d69133ad8b2f5c438c96e54a742155 Author: Robert Hooker Date: Fri Aug 14 13:43:14 2015 -0400 Update changelog diff --git a/debian/changelog b/debian/changelog index 45e4cb5..9bd4434 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,7 @@ libdrm (2.4.63-1) UNRELEASED; urgency=medium * New upstream release. - Drop Fix-headers-inclusion-in-xf86drmMode.c.diff, upstream. + * Add new libdrm-amdgpu1 package. -- Robert Hooker Fri, 14 Aug 2015 13:15:14 -0400 commit
Re: [RFC] Embed the mesa version in the library/binary name
On Aug 14, 2015 6:21 PM, "Emil Velikov" wrote: > > Hello all, Hi, > > My name is Emil and I'm the person breaking^w fixing mesa's build > amongst others. Yes, we know :D > > A while back I had this idea of renaming the libraries provided by > mesa to include the actual version number. Prior to doing anything > "crazy" I've decided to seek your feedback. > > > * What > The idea is to rename (ideally) all of the versioned libraries. > Unversioned ones such as radeonsi_dri.so will remain as is. > > Note: the soname and symlinks will stay to avoid breaking compatibility. > > > * How > While I haven't fully decided on the exact approach I'm thinking of > something like: > libGL.so.1.0.0 -> libGL.so.11.0 or libGL.so.110.1 or libGL.so.11.01 I'd like to see 11.0 for 11.0, 11.1 for 11.1 and etc. > > Other suggestions and ideas are welcome but please keep the version to X.Y > > > * Why > A number of reasons: > - The binary driver by Nvidia has been using this approach for years. > - It provides quick and easy feedback in traces > - In most cases, one can easily establish if the distro provided > library is overwritten. > - Allows multiple binaries to coexist, making the dynamic switching > between libGL.so.110.1, libGL.so.11.2.0 (mesa), libGL.so.352.14 > (nvidia) libGL.so.XX.Y (another vendor) a little bit easier. > - OpenBSD, Solaris(?) use sunos 4 style versioning -> .so.major.minor > > > How does this sound, do you foresee any pros/cons with the above > proposal ? Any and all input is greatly appreciated, but please try to > keep your replies technical and constructive. I'm fully agree with proposal, but one question. How much libs/programs links against libGL or other libs? I mean how much programs we will rebuild every release? > > If there are any concerns wrt the required updates (of the > build/packaging recipes) I'm willing to help out. > > > As I'm not sure how many of you follow mesa-dev, would you be OK if I > CC you in distro related~ish topics. > Some (not so crazy) examples: > - libEGL.so has additional dependency (via libdl) of X > - OpenCL only works with render node devices, kernel vY or later is required > - Mesa's new library libfoo.so should be shipped with libbar.so I would be happy to be CCed. > > > Thanks > Emil
Re: [RFC] Embed the mesa version in the library/binary name
On Aug 14 2015 or thereabouts, Igor Gnatenko wrote: > On Aug 14, 2015 6:21 PM, "Emil Velikov" wrote: > > > > Hello all, > Hi, > > > > My name is Emil and I'm the person breaking^w fixing mesa's build > > amongst others. > Yes, we know :D > > > > A while back I had this idea of renaming the libraries provided by > > mesa to include the actual version number. Prior to doing anything > > "crazy" I've decided to seek your feedback. > > > > > > * What > > The idea is to rename (ideally) all of the versioned libraries. > > Unversioned ones such as radeonsi_dri.so will remain as is. > > > > Note: the soname and symlinks will stay to avoid breaking compatibility. > > > > > > * How > > While I haven't fully decided on the exact approach I'm thinking of > > something like: > > libGL.so.1.0.0 -> libGL.so.11.0 or libGL.so.110.1 or libGL.so.11.01 > I'd like to see 11.0 for 11.0, 11.1 for 11.1 and etc. Adam probably knows better, but I thought libGL.so/.1/.1.2.0 as part of the linux/unix GL ABI? So not really sure that it is something we can actually change. That said, with the libOpenGL stuff we could probably do something better. BR, -R > > > > Other suggestions and ideas are welcome but please keep the version to X.Y > > > > > > * Why > > A number of reasons: > > - The binary driver by Nvidia has been using this approach for years. > > - It provides quick and easy feedback in traces > > - In most cases, one can easily establish if the distro provided > > library is overwritten. > > - Allows multiple binaries to coexist, making the dynamic switching > > between libGL.so.110.1, libGL.so.11.2.0 (mesa), libGL.so.352.14 > > (nvidia) libGL.so.XX.Y (another vendor) a little bit easier. > > - OpenBSD, Solaris(?) use sunos 4 style versioning -> .so.major.minor > > > > > > How does this sound, do you foresee any pros/cons with the above > > proposal ? Any and all input is greatly appreciated, but please try to > > keep your replies technical and constructive. > I'm fully agree with proposal, but one question. How much libs/programs > links against libGL or other libs? I mean how much programs we will rebuild > every release? > > > > If there are any concerns wrt the required updates (of the > > build/packaging recipes) I'm willing to help out. > > > > > > As I'm not sure how many of you follow mesa-dev, would you be OK if I > > CC you in distro related~ish topics. > > Some (not so crazy) examples: > > - libEGL.so has additional dependency (via libdl) of X > > - OpenCL only works with render node devices, kernel vY or later is > required > > - Mesa's new library libfoo.so should be shipped with libbar.so > I would be happy to be CCed. > > > > > > Thanks > > Emil
Re: [RFC] Embed the mesa version in the library/binary name
On 14 August 2015 at 20:47, Rob Clark wrote: > On Aug 14 2015 or thereabouts, Igor Gnatenko wrote: >> On Aug 14, 2015 6:21 PM, "Emil Velikov" wrote: >> > >> > Hello all, >> Hi, >> > >> > My name is Emil and I'm the person breaking^w fixing mesa's build >> > amongst others. >> Yes, we know :D >> > >> > A while back I had this idea of renaming the libraries provided by >> > mesa to include the actual version number. Prior to doing anything >> > "crazy" I've decided to seek your feedback. >> > >> > >> > * What >> > The idea is to rename (ideally) all of the versioned libraries. >> > Unversioned ones such as radeonsi_dri.so will remain as is. >> > >> > Note: the soname and symlinks will stay to avoid breaking compatibility. >> > >> > >> > * How >> > While I haven't fully decided on the exact approach I'm thinking of >> > something like: >> > libGL.so.1.0.0 -> libGL.so.11.0 or libGL.so.110.1 or libGL.so.11.01 >> I'd like to see 11.0 for 11.0, 11.1 for 11.1 and etc. > > Adam probably knows better, but I thought libGL.so/.1/ These files are symlinks to the actual library and will not be renamed. >.1.2.0 as part of > the linux/unix GL ABI? So not really sure that it is something we can > actually change. > I'm fairly confident it's not part of the ABI. I've been through the documentation five+ times, solely looking for it and did not see any hints, let alone explicit statement. Not to mention that nvidia has been using this approach since dawn of time. Even their oldest legacy driver 71.x (one supporting Geforce 256) uses it. > That said, with the libOpenGL stuff we could probably do something > better. > That does not prevent us from doing minor tweaks :) Cheers, Emil
Re: [RFC] Embed the mesa version in the library/binary name
On 14 August 2015 at 18:52, Igor Gnatenko wrote: > I'm fully agree with proposal, but one question. How much libs/programs > links against libGL or other libs? I mean how much programs we will rebuild > every release? The libGL.so and libGL.so.1 (and equivalents for other libraries) will not be renamed. Thus nothing will need to be rebuild, as everything is (and will be) using the original libGL.so.1 soname. Hmm guess I should have included this example in the original email :) $ ls -la /usr/lib/libGL*.so* libGLESv1_CM.so -> libGLESv1_CM.so.11.1 libGLESv1_CM.so.1 -> libGLESv1_CM.so.11.1 libGLESv1_CM.so.11.1 libGLESv2.so -> libGLESv2.so.11.1 libGLESv2.so.2 -> libGLESv2.so.11.1 libGLESv2.so.11.1 libGL.so -> libGL.so.11.1 libGL.so.1 -> libGL.so.11.1 libGL.so.11.1 > I would be happy to be CCed. Great, thanks. -Emil
Re: [RFC] Embed the mesa version in the library/binary name
On Aug 14 2015 or thereabouts, Emil Velikov wrote: > On 14 August 2015 at 20:47, Rob Clark wrote: > > On Aug 14 2015 or thereabouts, Igor Gnatenko wrote: > >> On Aug 14, 2015 6:21 PM, "Emil Velikov" wrote: > >> > > >> > Hello all, > >> Hi, > >> > > >> > My name is Emil and I'm the person breaking^w fixing mesa's build > >> > amongst others. > >> Yes, we know :D > >> > > >> > A while back I had this idea of renaming the libraries provided by > >> > mesa to include the actual version number. Prior to doing anything > >> > "crazy" I've decided to seek your feedback. > >> > > >> > > >> > * What > >> > The idea is to rename (ideally) all of the versioned libraries. > >> > Unversioned ones such as radeonsi_dri.so will remain as is. > >> > > >> > Note: the soname and symlinks will stay to avoid breaking compatibility. > >> > > >> > > >> > * How > >> > While I haven't fully decided on the exact approach I'm thinking of > >> > something like: > >> > libGL.so.1.0.0 -> libGL.so.11.0 or libGL.so.110.1 or libGL.so.11.01 > >> I'd like to see 11.0 for 11.0, 11.1 for 11.1 and etc. > > > > Adam probably knows better, but I thought libGL.so/.1/ > These files are symlinks to the actual library and will not be renamed. > > >.1.2.0 as part of > > the linux/unix GL ABI? So not really sure that it is something we can > > actually change. > > > I'm fairly confident it's not part of the ABI. I've been through the > documentation five+ times, solely looking for it and did not see any > hints, let alone explicit statement. Not to mention that nvidia has > been using this approach since dawn of time. Even their oldest legacy > driver 71.x (one supporting Geforce 256) uses it. Ok, if it is just a matter of adding symlinks, and apps can still link against libGL.so or libGL.so.1 or whatever, it seems fine. And I guess if nv is doing it, then it is probably not non-compliant. Anyways, I'm defn not the expert in such things, but I think there is some expectation that apps can link against a driver agnostic shared lib path an expect things to work with other drivers.. (ofc having an icd seems like it would be a good thing, so hopefully libOpenGL actually happens some day) BR, -R > > > That said, with the libOpenGL stuff we could probably do something > > better. > > > That does not prevent us from doing minor tweaks :) > > Cheers, > Emil
