Can we use gcc's __sync_val_compare_and_swap to implement DRM_CAS? (If so, do we actually need the __sync_val version, or can we use __sync_bool?)
I just threw the patch together in two minutes, so I've got no idea if it's right, just looking for feedback. The purpose of this is to remove a lot of inline assembly that hasn't been touched since the file was added in 2004, including some awesome already-assembled SPARC instructions.
Apparently someone had this idea before me. Way before me, as this code already exists in the Itanium section, though commented out for some reason long forgotten.
I don't have any idea when gcc added this. I just said 4.0, but this must be wrong, given the previous paragraph.
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html --- xf86drm.h | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/xf86drm.h b/xf86drm.h index 9b89f56..1459b5a 100644 --- a/xf86drm.h +++ b/xf86drm.h @@ -333,7 +333,12 @@ typedef struct _drmSetVersion { #define DRM_LOCK_HELD 0x80000000U /**< Hardware lock is held */ #define DRM_LOCK_CONT 0x40000000U /**< Hardware lock is contended */
-#if defined(__GNUC__) && (__GNUC__ >= 2) +#if defined(__GNUC__) && (__GNUC__ >= 4) + +#define DRM_CAS(lock, old, new, __ret) \ + __ret = __sync_val_compare_and_swap(i&__drm_dummy_lock(lock), (old), (new)) != (old) + +#elif defined(__GNUC__) && (__GNUC__ >= 2) # if defined(__i386) || defined(__AMD64__) || defined(__x86_64__) || defined(__amd64__) /* Reflect changes here to drmP.h */ #define DRM_CAS(lock,old,new,__ret) \
On Don, 2010-10-28 at 19:59 -0400, Matt Turner wrote:
Can we use gcc's __sync_val_compare_and_swap to implement DRM_CAS? (If so, do we actually need the __sync_val version, or can we use __sync_bool?)
I just threw the patch together in two minutes, so I've got no idea if it's right, just looking for feedback. The purpose of this is to remove a lot of inline assembly that hasn't been touched since the file was added in 2004, including some awesome already-assembled SPARC instructions.
Given that DRM_CAS is part of a kernel<->userspace ABI and is only used for the DRI1 'hardware lock', I suspect this is more risky than it's worth. At the least though, it would need to be verified for each architecture which has a specific DRM_CAS implementation now that this change doesn't result in DRM_CAS always failing and the HW lock falling back to calling the slow path ioctl every time.
dri-devel@lists.freedesktop.org