Re: [Mesa-dev] [PATCH] loader/dri3: Overhaul dri3_update_num_back

2016-08-19 Thread Keith Packard
Michel Dänzer  writes:

> From: Michel Dänzer 
>
> Always use 3 buffers when flipping. With only 2 buffers, we have to wait
> for a flip to complete (which takes non-0 time even with asynchronous
> flips) before we can start working on the next frame. We were previously
> only using 2 buffers for flipping if the X server supports asynchronous
> flips, even when we're not using asynchronous flips. This could result
> in bad performance (the referenced bug report is an extreme case, where
> the inter-frame stalls were preventing the GPU from reaching its maximum
> clocks).

Makes sense to me.

-- 
-keith


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver

2013-11-03 Thread Keith Packard
Kristian Høgsberg  writes:

> I sent a reply to the sourceforge addresses in the original emails,
> but I didn't see it show up in the archives.  Trying again with the
> freedesktop addresses.

(sorry for having an ancient shell script with sourceforge addresses in
it)

>> +typedef uint32_t *
>> +(*__DRIdri3Stamp)(__DRIdrawable *drawable);
>
> This looks OK, as long as it's not tied into the xcb special_event
> semantics.  From the way it's used, it looks like a loader can just
> increment this uint32_t when it needs to invalidate the buffer.  Still
> seems like an odd API - a invalidate function would be simpler, but
> I'm guessing it's limited by what you can do if you receive the
> special event in a different thread.

Yeah, I definitely do not want a callback function here. The API was
actually designed from the DRI2 side, not the xcb side as DRI2 has this
uint32_t already sitting there that just needed poking.

> With those changes, we can reuse __DRIimage for DRI3 which makes a lot
> of sense.  The GBM and Wayland backends already use __DRIimage for
> color buffers, but convert them to __DRI2buffer to be able to pass
> them into the DRI driver.  Being able to pass a __DRIimage into the
> driver in getBuffers will simplify those backends, and it should be
> fairly simple to port them to the dri3 driver interface.

Ok, so the first step would be to convert drivers from __DRI2buffer to
__DRIimage, at which point it should be trivial to use __DRIimage to
support DRI3? Or should I just take my existing __DRI3buffer code and
change that into a __DRIimage API and leave the __DRI2buffer code around
in the driver to support DRI2?

I'm game for either approach, but fixing the drivers to export a single
API that can support all of the window systems sure seems like a better
long-term plan...

-- 
keith.pack...@intel.com


pgpM5RRhzkvZt.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 5/8] dri/common: Add functions mapping MESA_FORMAT_* <-> __DRI_IMAGE_FORMAT_*

2013-11-04 Thread Keith Packard
Jordan Justen  writes:


> After patch 6, this will add SARGB8, right? So, maybe add this to the
> commit message, or separate out adding SARGB8 into a separate commit?

I added the SARGB8 define in patch 4; is there some other separation you
think would be warranted?

Oh, just so everyone knows -- krh and I chatted for a while this morning
and decided that this whole __DRI_IMAGE_FORMAT_* stuff is just a bad
idea and we should remove it all and just use __DRI_IMAGE_FOURCC_*
everywhere. I didn't want to mix that change up with this series though.

> Patches 1-6: Reviewed-by: Jordan Justen 

Thanks!

-- 
keith.pack...@intel.com


pgpCR_HrrMlX4.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader

2013-11-05 Thread Keith Packard
Keith Packard  writes:

> This sequence first adds a a couple of new DRIimage extensions to the
> dri/common, dri/i915 and dri/i965 directories which define a
> loader-independent API for managing window system operations.
>
> The last patch adds a new DRI3000 loader using those new interfaces.

I've figured out that I can also re-use dri2CreateNewScreen2 for the
image driver bits, as long as I change that function to also look up the
image loader. That means there are *no* new dri_util functions needed.

To recap, the changes needed to support using the DRIimageExtension
interfaces for allocating buffers from the driver in the loader are:

DRIimageDriverExtension

A proper subset of DRIdri2DriverExtension, which uses
the same five functions involved in creating new objects:

   /* Common DRI functions, shared with DRI2 */
   __DRIcreateNewScreen2createNewScreen2;
   __DRIcreateNewDrawable   createNewDrawable;
   __DRIcreateNewContextcreateNewContext;
   __DRIcreateContextAttribscreateContextAttribs;
   __DRIgetAPIMask  getAPIMask;

DRIimageLoaderExtension

Contains just two functions, one to allocate buffers and one to
copy the fake front to the real front when flushing stuff.

   /**
* Allocate color buffers.
*
* \param driDrawable
* \param width  Width of allocated buffers
* \param height Height of allocated buffers
* \param format one of __DRI_IMAGE_FORMAT_*
* \param stamp  Address of variable to be updated when
*   getBuffers must be called again
* \param loaderPrivate  The loaderPrivate for driDrawable
* \param buffer_maskSet of buffers to allocate
* \param buffersReturned buffers
*/
   int (*getBuffers)(__DRIdrawable *driDrawable,
 int *width, int *height,
 unsigned int format,
 uint32_t *stamp,
 void *loaderPrivate,
 uint32_t buffer_mask,
 struct __DRIimageList *buffers);

/**
 * Flush pending front-buffer rendering
 *
 * Any rendering that has been performed to the
 * fake front will be flushed to the front
 *
 * \param driDrawableDrawable whose front-buffer is to be 
flushed
 * \param loaderPrivate  Loader's private data that was previously 
passed
 *   into 
__DRIdri2ExtensionRec::createNewDrawable
 */
void (*flushFrontBuffer)(__DRIdrawable *driDrawable, void 
*loaderPrivate);

Each driver will need to have a path to use the image loader to get
color buffers using the DRIimageLoaderExtension getBuffers function.

-- 
keith.pack...@intel.com


pgpDlPww2zSWI.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 0/8] Add DRIimage-based DRI3/Present loader

2013-11-05 Thread Keith Packard
Eric Anholt  writes:

> It seems like we could just stick these things in __DRI_CORE as opposed
> to having another new extension to look up.

Having the driver expose this new extension is how I tell that the
driver is going to actually call the __DRIimage-based loader; the
alternative to a new extension would be to stick a flag in the
__DRI_CORE structure.

> The downside I see there is
> bugs in the server, which have patches at xserver-driinterface-versions
> of my tree.  (Unfortunately, I'm having a hard time building the server
> currently, so no testing yet).  Having a new extension whose name has
> nothing to do with the functions in it seems really weird.

It defines the interface to a driver which will be using the image
loader to allocate color buffers if available. The fact that the image
loader and DRI2 loader can both share the same driver interface is a
happy coincidence.

-- 
keith.pack...@intel.com


pgpUsRp469s5n.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] Add DRM_MODE_PAGE_FLIP_ASYNC define

2013-11-06 Thread Keith Packard
This exposes the kernel API for performing asynchronous flips

Signed-off-by: Keith Packard 
---

 include/drm/drm.h  | 1 +
 include/drm/drm_mode.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 725bf51..f0b4c16 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -797,6 +797,7 @@ struct drm_event_vblank {
 #define DRM_CAP_DUMB_PREFER_SHADOW 0x4
 #define DRM_CAP_PRIME 0x5
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
+#define DRM_CAP_ASYNC_PAGE_FLIP 0x7
 
 #define DRM_PRIME_CAP_IMPORT 0x1
 #define DRM_PRIME_CAP_EXPORT 0x2
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index c1bb1a3..76fd76b 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -425,7 +425,8 @@ struct drm_mode_crtc_lut {
 };
 
 #define DRM_MODE_PAGE_FLIP_EVENT 0x01
-#define DRM_MODE_PAGE_FLIP_FLAGS DRM_MODE_PAGE_FLIP_EVENT
+#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
+#define DRM_MODE_PAGE_FLIP_FLAGS 
(DRM_MODE_PAGE_FLIP_EVENT|DRM_MODE_PAGE_FLIP_ASYNC)
 
 /*
  * Request a page flip on the specified crtc.
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Add DRM_MODE_PAGE_FLIP_ASYNC define

2013-11-06 Thread Keith Packard
Eric Anholt  writes:

> Keith Packard  writes:
>
>> This exposes the kernel API for performing asynchronous flips
>>
>> Signed-off-by: Keith Packard 
>
> Reviewed-by: Eric Anholt 

I've pushed this to master.

-- 
keith.pack...@intel.com


pgprKBc6E8y8b.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] Don't use libudev for glx/dri3

2013-11-17 Thread Keith Packard
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.

Signed-off-by: Keith Packard 
---
 configure.ac  |   5 +--
 src/glx/dri3_common.c | 106 +++---
 2 files changed, 94 insertions(+), 17 deletions(-)

diff --git a/configure.ac b/configure.ac
index 63c2973..10e9e0f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -821,7 +821,6 @@ xyesno)
 GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
 PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
 PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >= 
$PRESENTPROTO_REQUIRED])
-PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED])
 fi
 
 # find the DRI deps for libGL
@@ -835,8 +834,8 @@ xyesno)
 
 PKG_CHECK_MODULES([DRIGL], [$dri_modules])
 GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV $dri_modules"
-X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS"
-GL_LIB_DEPS="$DRIGL_LIBS $LIBUDEV_LIBS"
+X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
+GL_LIB_DEPS="$DRIGL_LIBS"
 
 # need DRM libs, $PTHREAD_LIBS, etc.
 GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
index c758f96..01c9d09 100644
--- a/src/glx/dri3_common.c
+++ b/src/glx/dri3_common.c
@@ -72,22 +72,41 @@
 #include "dri3_priv.h"
 
 #define DRIVER_MAP_DRI3_ONLY
+
 #include "pci_ids/pci_id_driver_map.h"
 
+static dev_t
+dri3_rdev_from_fd(int fd)
+{
+   struct stat buf;
+
+   if (fstat(fd, &buf) < 0) {
+  ErrorMessageF("DRI3: failed to stat fd %d", fd);
+  return 0;
+   }
+   return buf.st_rdev;
+}
+
+/*
+ * There are multiple udev library versions, and they aren't polite about
+ * symbols, so just avoid using it until some glorious future when the udev
+ * developers figure out how to not break things
+ */
+
+#define USE_UDEV 0
+#if USE_UDEV
 #include 
 
 static struct udev_device *
 dri3_udev_device_new_from_fd(struct udev *udev, int fd)
 {
struct udev_device *device;
-   struct stat buf;
+   dev_t rdev = dri3_rdev_from_fd(fd);
 
-   if (fstat(fd, &buf) < 0) {
-  ErrorMessageF("DRI3: failed to stat fd %d", fd);
+   if (rdev == 0)
   return NULL;
-   }
 
-   device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
+   device = udev_device_new_from_devnum(udev, 'c', rdev);
if (device == NULL) {
   ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
   return NULL;
@@ -96,19 +115,20 @@ dri3_udev_device_new_from_fd(struct udev *udev, int fd)
return device;
 }
 
-char *
-dri3_get_driver_for_fd(int fd)
+static int
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
 {
struct udev *udev;
struct udev_device *device, *parent;
const char *pci_id;
-   char *driver = NULL;
-   int vendor_id, chip_id, i, j;
+   int ret = 0;
 
udev = udev_new();
+   if (!udev)
+  goto no_udev;
device = dri3_udev_device_new_from_fd(udev, fd);
if (device == NULL)
-  return NULL;
+  goto no_dev;
 
parent = udev_device_get_parent(device);
if (parent == NULL) {
@@ -118,10 +138,71 @@ dri3_get_driver_for_fd(int fd)
 
pci_id = udev_device_get_property_value(parent, "PCI_ID");
if (pci_id == NULL ||
-   sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
+   sscanf(pci_id, "%x:%x", vendorp, chipp) != 2) {
   ErrorMessageF("DRI3: malformed or no PCI ID");
   goto out;
}
+   ret = 1;
+
+out:
+   udev_device_unref(device);
+no_dev:
+   udev_unref(udev);
+no_udev:
+   return ret;
+}
+#else
+
+#define SYS_PATH_MAX256
+
+static int
+dri3_read_hex(dev_t rdev, char *entry, int *value)
+{
+   char path[SYS_PATH_MAX];
+   FILE *f;
+   int  r;
+
+   snprintf(path, sizeof (path), "/sys/dev/char/%u:%u/device/%s",
+major(rdev), minor(rdev), entry);
+
+   printf ("path %s\n", path);
+
+   f = fopen(path,"r");
+   if (f == NULL)
+  return 0;
+
+   r = fscanf(f, "0x%x\n", value);
+   fclose(f);
+   if (r != 1)
+  return 0;
+   return 1;
+}
+
+static int
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
+{
+   dev_trdev = dri3_rdev_from_fd(fd);
+   
+   if (!rdev)
+  return 0;
+
+   if (!dri3_read_hex(rdev, "vendor", vendorp))
+  return 0;
+   if (!dri3_read_hex(rdev, "device", chipp))
+  return 0;
+   return 1;
+}
+
+#endif
+
+char *
+dri3_get_driver_for_fd(int fd)
+{
+   char *driver = NULL;
+   int vendor_id, chip_id, i, j;
+
+   if (!dri3_get_pci_id_from_fd(fd, &vendor_id, &chip_id))
+  return NULL;
 
for (i = 0; driver_map[i].driver; i++) {
   if (v

[Mesa-dev] [PATCH] Don't use libudev for glx/dri3

2013-11-17 Thread Keith Packard
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.

Signed-off-by: Keith Packard 
---

Sorry for the patch spam; I hadn't rebased in a while and there was a
configure.ac conflict. Here's a version which should apply cleanly to master.

 configure.ac  |   8 
 src/glx/dri3_common.c | 104 +++---
 2 files changed, 90 insertions(+), 22 deletions(-)

diff --git a/configure.ac b/configure.ac
index fb16338..656d9d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -821,9 +821,6 @@ xyesno)
 PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
 GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
 if test x"$enable_dri3" = xyes; then
-if test x"$have_libudev" != xyes; then
-  AC_MSG_ERROR([DRI3 requires libudev >= $LIBUDEV_REQUIRED])
-fi
 PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
 PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >= 
$PRESENTPROTO_REQUIRED])
 fi
@@ -847,11 +844,6 @@ xyesno)
 X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
 GL_LIB_DEPS="$DRIGL_LIBS"
 
-if test x"$enable_dri3$have_libudev" = xyesyes; then
-X11_INCLUDES="$X11_INCLUDES $LIBUDEV_CFLAGS"
-GL_LIB_DEPS="$GL_LIB_DEPS $LIBUDEV_LIBS"
-fi
-
 # need DRM libs, $PTHREAD_LIBS, etc.
 GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
 GL_PC_LIB_PRIV="-lm $PTHREAD_LIBS $DLOPEN_LIBS"
diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
index c758f96..7330d79 100644
--- a/src/glx/dri3_common.c
+++ b/src/glx/dri3_common.c
@@ -72,22 +72,41 @@
 #include "dri3_priv.h"
 
 #define DRIVER_MAP_DRI3_ONLY
+
 #include "pci_ids/pci_id_driver_map.h"
 
+static dev_t
+dri3_rdev_from_fd(int fd)
+{
+   struct stat buf;
+
+   if (fstat(fd, &buf) < 0) {
+  ErrorMessageF("DRI3: failed to stat fd %d", fd);
+  return 0;
+   }
+   return buf.st_rdev;
+}
+
+/*
+ * There are multiple udev library versions, and they aren't polite about
+ * symbols, so just avoid using it until some glorious future when the udev
+ * developers figure out how to not break things
+ */
+
+#define USE_UDEV 0
+#if USE_UDEV
 #include 
 
 static struct udev_device *
 dri3_udev_device_new_from_fd(struct udev *udev, int fd)
 {
struct udev_device *device;
-   struct stat buf;
+   dev_t rdev = dri3_rdev_from_fd(fd);
 
-   if (fstat(fd, &buf) < 0) {
-  ErrorMessageF("DRI3: failed to stat fd %d", fd);
+   if (rdev == 0)
   return NULL;
-   }
 
-   device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
+   device = udev_device_new_from_devnum(udev, 'c', rdev);
if (device == NULL) {
   ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
   return NULL;
@@ -96,19 +115,20 @@ dri3_udev_device_new_from_fd(struct udev *udev, int fd)
return device;
 }
 
-char *
-dri3_get_driver_for_fd(int fd)
+static int
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
 {
struct udev *udev;
struct udev_device *device, *parent;
const char *pci_id;
-   char *driver = NULL;
-   int vendor_id, chip_id, i, j;
+   int ret = 0;
 
udev = udev_new();
+   if (!udev)
+  goto no_udev;
device = dri3_udev_device_new_from_fd(udev, fd);
if (device == NULL)
-  return NULL;
+  goto no_dev;
 
parent = udev_device_get_parent(device);
if (parent == NULL) {
@@ -118,10 +138,69 @@ dri3_get_driver_for_fd(int fd)
 
pci_id = udev_device_get_property_value(parent, "PCI_ID");
if (pci_id == NULL ||
-   sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
+   sscanf(pci_id, "%x:%x", vendorp, chipp) != 2) {
   ErrorMessageF("DRI3: malformed or no PCI ID");
   goto out;
}
+   ret = 1;
+
+out:
+   udev_device_unref(device);
+no_dev:
+   udev_unref(udev);
+no_udev:
+   return ret;
+}
+#else
+
+#define SYS_PATH_MAX256
+
+static int
+dri3_read_hex(dev_t rdev, char *entry, int *value)
+{
+   char path[SYS_PATH_MAX];
+   FILE *f;
+   int  r;
+
+   snprintf(path, sizeof (path), "/sys/dev/char/%u:%u/device/%s",
+major(rdev), minor(rdev), entry);
+
+   f = fopen(path,"r");
+   if (f == NULL)
+  return 0;
+
+   r = fscanf(f, "0x%x\n", value);
+   fclose(f);
+   if (r != 1)
+  return 0;
+   return 1;
+}
+
+static int
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
+{
+   dev_trdev = dri3_rdev_from_fd(fd);
+   
+   if (!rdev)
+  return 0;
+
+   if (!dri3_read_hex(rdev, "vendor", vendorp))
+  return 0;
+   if (!dri3_read_hex(rdev, &qu

Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3

2013-11-17 Thread Keith Packard
Emil Velikov  writes:

> On 18/11/13 01:08, Keith Packard wrote:
>> libudev doesn't have a stable API/ABI, and if the application wants to use 
>> one
>> version, we'd best not load another into libGL.
>> 
>> Signed-off-by: Keith Packard 
>> ---
>> 
> Hi Keith,
>
> Firstly, I would like to apologise for the rather daft questions.
>
> With that said, looking through your patch I've noticed that (most of)
> your int functions are returning 0 or failure and 1 on success. Were
> those functions meant to return boolean/bool?

Sure, but I was too lazy to figure out which kind of bool belongs in
that part of mesa...

-- 
keith.pack...@intel.com


pgp_KzKJl3SAh.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3

2013-11-17 Thread Keith Packard
Kenneth Graunke  writes:

> For non-API facing stuff, you can just use stdbool.h's
> bool/true/false.

tnx. I pushed that to my dri3 branch. Btw, that branch also has some
gallium support for __DRIimageDriverExtension. I don't have any hardware
to test with, so it's surely broken in some major ways, but it might
show where the hooks need to be.

-- 
keith.pack...@intel.com


pgpyS5ZwTrb9t.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3

2013-11-18 Thread Keith Packard
Emil Velikov  writes:

> On 18/11/13 01:08, Keith Packard wrote:
>> libudev doesn't have a stable API/ABI, and if the application wants to use 
>> one
>> version, we'd best not load another into libGL.
>> 
>> Signed-off-by: Keith Packard 
>> ---
>> 
> Hi Keith,
>
> Did you had the chance to look at src/gallium/targets/egl-static/egl.c?
> It has a different implementation of drm_fd_get_pci_id, whenever udev is
> not available.

Yeah, it's ugly in a different way from the udev technique...

> AFAICS it goes back to the kernel via the relevant ioctl to retrieve the
> deviceid/chipid. Currently all but nouveau provide such information. I'm
> thinking that this approach might be more reasonable for those concerned
> with portability of the udev bits (think on *BSD).

I'd encourage some kind of standard IOCTL from DRM that returns the
PCI-ID of the underlying device, rather than relying on the level of
kludge present in either the udev (or my fake udev) method or the
non-udev path in the egl code...

> I'm not nitpicking, just thought you might find this interesting.

Definitely interesting; it's almost what we want -- the kernel knows the
information, there just isn't a clean way of getting it (and no way at
all for some devices).

-- 
keith.pack...@intel.com


pgpHiOs5jRUMR.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3

2013-11-19 Thread Keith Packard
Eric Anholt  writes:

> Keith Packard  writes:
>
>> libudev doesn't have a stable API/ABI, and if the application wants to use 
>> one
>> version, we'd best not load another into libGL.
>>
>> Signed-off-by: Keith Packard 
>
> This looks so simple it's definitely worth dropping udev, but I'd like
> to see the udev code actually dropped instead of #if 0ed.

It's either that or make it a config option, in case libudev is useful
on some other system someday?

-- 
keith.pack...@intel.com


pgpwnupJNE3h4.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-11-21 Thread Keith Packard
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
__IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.

I'll refrain from comments on whether I think having two separate sets of
format defines in dri_interface.h is a good idea or not...

Signed-off-by: Keith Packard 
---

This gets iceweasel running with the GL compositor enabled.

 include/GL/internal/dri_interface.h  | 1 +
 src/glx/dri3_glx.c   | 1 +
 src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
 src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
 4 files changed, 8 insertions(+)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index b012570..a4387c4 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1034,6 +1034,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_FOURCC_XRGB0x34325258
 #define __DRI_IMAGE_FOURCC_ABGR0x34324241
 #define __DRI_IMAGE_FOURCC_XBGR0x34324258
+#define __DRI_IMAGE_FOURCC_SARGB0x83324258
 #define __DRI_IMAGE_FOURCC_YUV410  0x39565559
 #define __DRI_IMAGE_FOURCC_YUV411  0x31315559
 #define __DRI_IMAGE_FOURCC_YUV420  0x32315559
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b047cc8..5861317 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -890,6 +890,7 @@ image_format_to_fourcc(int format)
 
/* Convert from __DRI_IMAGE_FORMAT to __DRI_IMAGE_FOURCC (sigh) */
switch (format) {
+   case __DRI_IMAGE_FORMAT_SARGB8: return __DRI_IMAGE_FOURCC_SARGB;
case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index 7f1fc6b..2dd2bc7 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -184,6 +184,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
+   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index e44d0f6..cf8c3e2 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -220,6 +220,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
+   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
 
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] gallium: Use base.stamp for all drawable invalidation checks.

2013-11-21 Thread Keith Packard
Upper levels of the stack use base.stamp to tell when a drawable needs to be
revalidated, but the dri state tracker was using dPriv->lastStamp. Those two,
along with dri2.stamp, all get simultaneously incremented when a dri2
invalidate event was delivered, and so end up containing precisely the same
value.

This patch doesn't change the fact that there are three variables, rather it
switches all of the tests to use only base.stamp, which is functionally
equivalent to the previous code.

Then, it passes base.stamp to the image loader getBuffers function so that the
one which is checked will get updated by the XCB special event queue used by 
DRI3.

Signed-off-by: Keith Packard 
---

This patch makes sure that drawables get invalidated when the window
changes size or when SwapBuffers is called; dri3 has only a single
location to smite when things change, so we need to make sure the
upper levels all share that location.

This should permit the elimination of the dri2.stamp and lastStamp
variables, which would be a nice further cleanup.

 src/gallium/state_trackers/dri/common/dri_drawable.c | 4 ++--
 src/gallium/state_trackers/dri/drm/dri2.c| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c 
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index f255108..734bca2 100644
--- a/src/gallium/state_trackers/dri/common/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
@@ -73,7 +73,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
 * checked.
 */
do {
-  lastStamp = drawable->dPriv->lastStamp;
+  lastStamp = drawable->base.stamp;
   new_stamp = (drawable->texture_stamp != lastStamp);
 
   if (new_stamp || new_mask || screen->broken_invalidate) {
@@ -91,7 +91,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
  drawable->texture_stamp = lastStamp;
  drawable->texture_mask = statt_mask;
   }
-   } while (lastStamp != drawable->dPriv->lastStamp);
+   } while (lastStamp != drawable->base.stamp);
 
if (!out)
   return TRUE;
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 6a56cd4..c7e4151 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -545,7 +545,7 @@ dri_image_allocate_textures(struct dri_context *ctx,
 
(*sPriv->image.loader->getBuffers) (dPriv,
image_format,
-   &dPriv->dri2.stamp,
+   (uint32_t *) &drawable->base.stamp,
dPriv->loaderPrivate,
buffer_mask,
&images);
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] dri3: Prepare for API change in libxshmfence

2013-11-21 Thread Keith Packard
libxshmfence foolishly advertises the type of a fence as 'int32_t *', which
works when the fence is a linux futex. However, that library is going to
change the exported datatype to 'struct xshmfence *', which will provide some
nice typechecking. Anticipate the change by just using 'void *' in mesa, which
works with both the int32_t* and struct xshmfence* versions.

Signed-off-by: Keith Packard 
---

libxshmfence will also be providing a HAVE_STRUCT_XSHMFENCE define, so
we could actually check for that and use struct xshmfence when
available. Just using 'void *' avoids a bunch of clutter, but if
people think they'd rather have extra type checking, I can do the
other version instead.

 src/glx/dri3_glx.c  | 4 ++--
 src/glx/dri3_priv.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 5861317..239d58b 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -676,7 +676,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
xcb_connection_t *c = XGetXCBConnection(dpy);
xcb_pixmap_t pixmap;
xcb_sync_fence_t sync_fence;
-   int32_t *shm_fence;
+   void *shm_fence;
int buffer_fd, fence_fd;
int stride;
 
@@ -922,7 +922,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
struct dri3_screen   *psc;
xcb_connection_t *c;
xcb_sync_fence_t sync_fence;
-   int32_t  *shm_fence;
+   void *shm_fence;
int  fence_fd;
__DRIimage   *image_planar;
int  stride, offset;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index c892800..0d21e67 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -87,7 +87,7 @@ struct dri3_buffer {
 */
 
uint32_t sync_fence; /* XID of X SyncFence object */
-   int32_t  *shm_fence; /* pointer to xshmfence object */
+   void *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
void *driverPrivate;
 
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] dri3: Free resources when drawable is destroyed.

2013-11-21 Thread Keith Packard
Always nice to clean up after ourselves.

Signed-off-by: Keith Packard 
---

Ok, so not having this in the dri3 code led to a bit of extra memory
usage in apps and the X server.

 src/glx/dri3_glx.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 239d58b..669f0bb 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -266,13 +266,25 @@ dri3_create_context(struct glx_screen *base,
 }
 
 static void
+dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer 
*buffer);
+
+static void
 dri3_destroy_drawable(__GLXDRIdrawable *base)
 {
struct dri3_screen *psc = (struct dri3_screen *) base->psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
+   xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+   int i;
 
(*psc->core->destroyDrawable) (pdraw->driDrawable);
 
+   for (i = 0; i < DRI3_NUM_BUFFERS; i++) {
+  if (pdraw->buffers[i])
+ dri3_free_render_buffer(pdraw, pdraw->buffers[i]);
+   }
+
+   if (pdraw->special_event)
+  xcb_unregister_for_special_event(c, pdraw->special_event);
free(pdraw);
 }
 
@@ -736,6 +748,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   fence_fd);
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = true;
buffer->sync_fence = sync_fence;
buffer->shm_fence = shm_fence;
buffer->width = width;
@@ -769,7 +782,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw, struct 
dri3_buffer *buffer)
struct dri3_screen   *psc = (struct dri3_screen *) pdraw->base.psc;
xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
 
-   xcb_free_pixmap(c, buffer->pixmap);
+   if (buffer->own_pixmap)
+  xcb_free_pixmap(c, buffer->pixmap);
xcb_sync_destroy_fence(c, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
(*psc->image->destroyImage)(buffer->image);
@@ -988,6 +1002,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
   goto no_image;
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = false;
buffer->width = bp_reply->width;
buffer->height = bp_reply->height;
buffer->buffer_type = buffer_type;
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] v2: dri3: Free resources when drawable is destroyed.

2013-11-21 Thread Keith Packard
Always nice to clean up after ourselves.

Signed-off-by: Keith Packard 
---

v2: Include changes to dri3_priv.h as well

 src/glx/dri3_glx.c  | 17 -
 src/glx/dri3_priv.h |  5 -
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 239d58b..669f0bb 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -266,13 +266,25 @@ dri3_create_context(struct glx_screen *base,
 }
 
 static void
+dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer 
*buffer);
+
+static void
 dri3_destroy_drawable(__GLXDRIdrawable *base)
 {
struct dri3_screen *psc = (struct dri3_screen *) base->psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
+   xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+   int i;
 
(*psc->core->destroyDrawable) (pdraw->driDrawable);
 
+   for (i = 0; i < DRI3_NUM_BUFFERS; i++) {
+  if (pdraw->buffers[i])
+ dri3_free_render_buffer(pdraw, pdraw->buffers[i]);
+   }
+
+   if (pdraw->special_event)
+  xcb_unregister_for_special_event(c, pdraw->special_event);
free(pdraw);
 }
 
@@ -736,6 +748,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   fence_fd);
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = true;
buffer->sync_fence = sync_fence;
buffer->shm_fence = shm_fence;
buffer->width = width;
@@ -769,7 +782,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw, struct 
dri3_buffer *buffer)
struct dri3_screen   *psc = (struct dri3_screen *) pdraw->base.psc;
xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
 
-   xcb_free_pixmap(c, buffer->pixmap);
+   if (buffer->own_pixmap)
+  xcb_free_pixmap(c, buffer->pixmap);
xcb_sync_destroy_fence(c, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
(*psc->image->destroyImage)(buffer->image);
@@ -988,6 +1002,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
   goto no_image;
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = false;
buffer->width = bp_reply->width;
buffer->height = bp_reply->height;
buffer->buffer_type = buffer_type;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 0d21e67..05f66cf 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -89,6 +89,7 @@ struct dri3_buffer {
uint32_t sync_fence; /* XID of X SyncFence object */
void *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
+   GLbooleanown_pixmap; /* We allocated the pixmap ID, free on destroy 
*/
void *driverPrivate;
 
uint32_t size;
@@ -171,6 +172,8 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
   return DRI3_FRONT_ID;
 }
 
+#define DRI3_NUM_BUFFERS(1 + DRI3_MAX_BACK)
+
 struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
@@ -194,7 +197,7 @@ struct dri3_drawable {
uint64_t previous_time;
unsigned frames;
 
-   struct dri3_buffer *buffers[1 + DRI3_MAX_BACK];
+   struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
int depth;
 
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] present: Send GLX_BufferSwapComplete events from present extension

2013-11-21 Thread Keith Packard
This allows GL to support the GLX_INTEL_swap_event extension

Signed-off-by: Keith Packard 
---

This is the X server side; the mesa patch will be sent shortly (it's tiny)

 glx/Makefile.am |  3 ++-
 glx/glxcmds.c   | 69 +
 glx/glxdri2.c   | 26 +--
 glx/glxext.c|  3 +++
 glx/glxserver.h |  9 +++
 present/present.h   |  9 +++
 present/present_event.c | 10 +++
 7 files changed, 109 insertions(+), 20 deletions(-)

diff --git a/glx/Makefile.am b/glx/Makefile.am
index 5f28e87..44d3a7d 100644
--- a/glx/Makefile.am
+++ b/glx/Makefile.am
@@ -20,7 +20,8 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/hw/xfree86/os-support/bus \
-I$(top_srcdir)/hw/xfree86/common \
-I$(top_srcdir)/hw/xfree86/dri \
-   -I$(top_srcdir)/mi
+   -I$(top_srcdir)/mi \
+   -I$(top_srcdir)/present
 
 if DRI2_AIGLX
 AM_CPPFLAGS += -I$(top_srcdir)/hw/xfree86/dri2
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index efa4aec..2c5de70 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -2468,3 +2468,72 @@ __glXDisp_ClientInfo(__GLXclientState * cl, GLbyte * pc)
 
 return Success;
 }
+
+#include 
+
+void
+__glXsendSwapEvent(__GLXdrawable *drawable, int type, CARD64 ust,
+   CARD64 msc, CARD32 sbc)
+{
+ClientPtr client = clients[CLIENT_ID(drawable->drawId)];
+
+xGLXBufferSwapComplete2 wire =  {
+.type = __glXEventBase + GLX_BufferSwapComplete
+};
+
+if (!client)
+return;
+
+if (!(drawable->eventMask & GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
+return;
+
+wire.event_type = type;
+wire.drawable = drawable->drawId;
+wire.ust_hi = ust >> 32;
+wire.ust_lo = ust & 0x;
+wire.msc_hi = msc >> 32;
+wire.msc_lo = msc & 0x;
+wire.sbc = sbc;
+
+WriteEventsToClient(client, 1, (xEvent *) &wire);
+}
+
+#if PRESENT
+static void
+__glXpresentCompleteNotify(WindowPtr window, CARD8 present_mode, CARD32 serial,
+   uint64_t ust, uint64_t msc)
+{
+__GLXdrawable *drawable;
+int error;
+int glx_type;
+int rc;
+
+rc = dixLookupResourceByType((pointer *) &drawable, window->drawable.id,
+ __glXDrawableRes, serverClient, 
DixGetAttrAccess);
+
+if (rc != Success)
+return;
+
+switch(present_mode) {
+case PresentCompleteModeFlip:
+glx_type = GLX_FLIP_COMPLETE_INTEL;
+break;
+case PresentCompleteModeCopy:
+glx_type = GLX_BLIT_COMPLETE_INTEL;
+break;
+default:
+glx_type = 0;
+break;
+}
+
+__glXsendSwapEvent(drawable, glx_type, ust, msc, serial);
+}
+
+#include 
+
+void
+__glXregisterPresentCompleteNotify(void)
+{
+present_register_complete_notify(__glXpresentCompleteNotify);
+}
+#endif
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 1d74c8f..9d3f3c3 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -177,36 +177,24 @@ __glXdriSwapEvent(ClientPtr client, void *data, int type, 
CARD64 ust,
   CARD64 msc, CARD32 sbc)
 {
 __GLXdrawable *drawable = data;
-xGLXBufferSwapComplete2 wire =  {
-.type = __glXEventBase + GLX_BufferSwapComplete
-};
-
-if (!(drawable->eventMask & GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
-return;
-
+int glx_type;
 switch (type) {
 case DRI2_EXCHANGE_COMPLETE:
-wire.event_type = GLX_EXCHANGE_COMPLETE_INTEL;
+glx_type = GLX_EXCHANGE_COMPLETE_INTEL;
 break;
 case DRI2_BLIT_COMPLETE:
-wire.event_type = GLX_BLIT_COMPLETE_INTEL;
+glx_type = GLX_BLIT_COMPLETE_INTEL;
 break;
 case DRI2_FLIP_COMPLETE:
-wire.event_type = GLX_FLIP_COMPLETE_INTEL;
+glx_type = GLX_FLIP_COMPLETE_INTEL;
 break;
 default:
 /* unknown swap completion type */
-wire.event_type = 0;
+glx_type = 0;
 break;
 }
-wire.drawable = drawable->drawId;
-wire.ust_hi = ust >> 32;
-wire.ust_lo = ust & 0x;
-wire.msc_hi = msc >> 32;
-wire.msc_lo = msc & 0x;
-wire.sbc = sbc;
-
-WriteEventsToClient(client, 1, (xEvent *) &wire);
+
+__glXsendSwapEvent(drawable, glx_type, ust, msc, sbc);
 }
 
 /*
diff --git a/glx/glxext.c b/glx/glxext.c
index 3a7de28..601d08a 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -399,6 +399,9 @@ GlxExtensionInit(void)
 
 __glXErrorBase = extEntry->errorBase;
 __glXEventBase = extEntry->eventBase;
+#if PRESENT
+__glXregisterPresentCompleteNotify();
+#endif
 }
 
 //
diff --git a/glx/glxserver.h b/glx/glxserver.h
index 5e29abb..f862b63 100644
--- a/glx/glxserver.h
+++ b/glx/glxserver.h
@@ -120,6 +120,15 @@ void glxResumeClients(void);
 void __glXsetGetProcAddress(void (*(*ge

[Mesa-dev] [PATCH] dri3: Support GLX_INTEL_swap_event

2013-11-21 Thread Keith Packard
The easy part is turning on the extension, now that the X server has a patch
to send the events.

The only trick was making sure the Present extension reliably provided the
right 'sbc' count back in the event, and that's done by making sure the sbc
count is always the same as the sequence number that we send in the
PresentPixmap requests, and that's done by using the same variable for both
roles.

Signed-off-by: Keith Packard 
---

This passes the piglet glx-swap-event test.

 src/glx/dri3_glx.c  | 27 ++-
 src/glx/dri3_priv.h |  3 +--
 2 files changed, 7 insertions(+), 23 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 669f0bb..a7bf318 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -423,7 +423,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 
*ust = priv->ust;
*msc = priv->msc;
-   *sbc = priv->sbc;
+   *sbc = priv->present_count;
 
return 1;
 }
@@ -450,7 +450,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
 
-   while (priv->sbc < target_sbc) {
+   while (priv->present_count < target_sbc) {
   sleep(1);
}
return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
@@ -1282,7 +1282,8 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
   /* Compute when we want the frame shown by taking the last known 
successful
* MSC and adding in a swap interval for each outstanding swap request
*/
-  ++priv->present_request_serial;
+  ++priv->present_count;
+  priv->present_request_serial = (uint32_t) priv->present_count;
   if (target_msc == 0)
  target_msc = priv->msc + priv->swap_interval * 
(priv->present_request_serial - priv->present_event_serial);
 
@@ -1302,7 +1303,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
  target_msc,
  divisor,
  remainder, 0, NULL);
-  ret = ++priv->sbc;
+  ret = priv->present_count;
 
   /* If there's a fake front, then copy the source back buffer
* to the fake front to keep it up to date. This needs
@@ -1494,23 +1495,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct 
glx_display * priv,
__glXEnableDirectExtension(&psc->base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_SGI_make_current_read");
-
-   /*
-* GLX_INTEL_swap_event is broken on the server side, where it's
-* currently unconditionally enabled. This completely breaks
-* systems running on drivers which don't support that extension.
-* There's no way to test for its presence on this side, so instead
-* of disabling it unconditionally, just disable it for drivers
-* which are known to not support it, or for DDX drivers supporting
-* only an older (pre-ScheduleSwap) version of DRI2.
-*
-* This is a hack which is required until:
-* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
-* is merged and updated xserver makes it's way into distros:
-*/
-//   if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) {
-//  __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
-//   }
+   __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
 
mask = psc->image_driver->getAPIMask(psc->driScreen);
 
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 05f66cf..cdf986d 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -183,11 +183,10 @@ struct dri3_drawable {
uint8_t have_fake_front;
uint8_t is_pixmap;
 
+   uint64_t present_count;
uint32_t present_request_serial;
uint32_t present_event_serial;
 
-   uint64_t sbc;
-
uint64_t ust, msc;
 
/* For WaitMSC */
-- 
1.8.4.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-11-22 Thread Keith Packard
Daniel Vetter  writes:

> Hm, where do we have the canonical source for all these fourcc codes? I'm
> asking since we have our own copy in the kernel as drm_fourcc.h, and that
> one is part of the userspace ABI since we use it to pass around
> framebuffer formats and format lists.

I think it's the kernel? I really don't know, as the whole notion of
fourcc codes seems crazy to me...

Feel free to steal this code and stick it in the kernel if you like.

> Just afraid to create long-term maintainance madness here with the
> kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely
> we'll ever accept srgb for framebuffers though.

Would suck to collide with something we do want though.

-- 
keith.pack...@intel.com


pgpf4F9vCQb7I.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use

2013-11-22 Thread Keith Packard
If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.

Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.

Signed-off-by: Keith Packard 
---

This one took a while to find -- multiple bo_gem structs pointing at
the same gem handle would either cause the object to be destroyed
before we were done using it, or we'd end up sending the same
gem_handle for multiple buffers.

This looks a lot like the named object handling stuff, as one would
expect.

 intel/intel_bufmgr_gem.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index df6fcec..2897bb2 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -112,6 +112,7 @@ typedef struct _drm_intel_bufmgr_gem {
 
drmMMListHead named;
drmMMListHead vma_cache;
+drmMMListHead prime;
int vma_count, vma_open, vma_max;
 
uint64_t gtt_size;
@@ -2451,8 +2452,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
*bufmgr, int prime_fd, int s
uint32_t handle;
drm_intel_bo_gem *bo_gem;
struct drm_i915_gem_get_tiling get_tiling;
+   drmMMListHead *list;
 
ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, &handle);
+
+   /*
+* See if the kernel has already returned this buffer to us. Just as
+* for named buffers, we must not create two bo's pointing at the same
+* kernel object
+*/
+   for (list = bufmgr_gem->prime.next;
+list != &bufmgr_gem->prime;
+list = list->next) {
+   bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
+   if (bo_gem->gem_handle == handle) {
+   drm_intel_gem_bo_reference(&bo_gem->bo);
+   return &bo_gem->bo;
+   }
+   }
+
if (ret) {
  fprintf(stderr,"ret is %d %d\n", ret, errno);
return NULL;
@@ -2487,8 +2505,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
*bufmgr, int prime_fd, int s
bo_gem->has_error = false;
bo_gem->reusable = false;
 
-   DRMINITLISTHEAD(&bo_gem->name_list);
DRMINITLISTHEAD(&bo_gem->vma_list);
+   DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->prime);
 
VG_CLEAR(get_tiling);
get_tiling.handle = bo_gem->gem_handle;
@@ -3301,5 +3319,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
DRMINITLISTHEAD(&bufmgr_gem->vma_cache);
bufmgr_gem->vma_max = -1; /* unlimited by default */
 
+   DRMINITLISTHEAD(&bufmgr_gem->prime);
+
return &bufmgr_gem->bufmgr;
 }
-- 
1.8.4.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 0/2] Minor __DRIimage fixes for i965

2013-11-22 Thread Keith Packard
While debugging the libdrm duplicate buffer object adventure, I managed to
temporarily understand object lifetimes in the __DRIimage getBuffers path, and
also to compare that to the DRI2 getBuffers path. Here are a couple of small
fixes.

I haven't looked at the i915 code, but I suspect the first one, and parts of
the second one would apply.

 [PATCH 1/2] i965: Correct check for re-bound buffer in

The code was attempting to avoid re-creating the miptree when the loader
handed back the same bufffer we already had, but it was confused about how to
tell -- turns out the object actually shared between the loader and the driver
is the BO, not the region. And so, we compare BO pointers to see if the image
buffer needs to have a new miptree.

 [PATCH 2/2] i965: Set fast color clear mcs_state on newly allocated

Here's a chunk of code that was just missing from the __DRIimage path as a
result of rebasing across some new driver additions.

Both of these fixes are candidates for 10.0 as they affect the __DRIimage
paths now used by Wayland.

-keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] i965: Correct check for re-bound buffer in intel_update_image_buffer

2013-11-22 Thread Keith Packard
The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.

Signed-off-by: Keith Packard 
---
 src/mesa/drivers/dri/i965/brw_context.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index bee98e3..64ff855 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1339,10 +1339,21 @@ intel_update_image_buffer(struct brw_context *intel,
 
unsigned num_samples = rb->Base.Base.NumSamples;
 
-   if (rb->mt &&
-   rb->mt->region &&
-   rb->mt->region == region)
-  return;
+   /* Check and see if we're already bound to the right
+* buffer object
+*/
+   if (num_samples == 0) {
+   if (rb->mt &&
+   rb->mt->region &&
+   rb->mt->region->bo == region->bo)
+  return;
+   } else {
+   if (rb->mt &&
+   rb->mt->singlesample_mt &&
+   rb->mt->singlesample_mt->region &&
+   rb->mt->singlesample_mt->region->bo == region->bo)
+  return;
+   }
 
intel_miptree_release(&rb->mt);
rb->mt = intel_miptree_create_for_image_buffer(intel,
-- 
1.8.4.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] i965: Set fast color clear mcs_state on newly allocated image miptrees

2013-11-22 Thread Keith Packard
Just copying code from the dri2 path to set up the fast color clear state.

This also removes a couple of bogus intel_region_reference calls.

Signed-off-by: Keith Packard 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 884ddef..ca78f32 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -762,7 +762,13 @@ intel_miptree_create_for_image_buffer(struct brw_context 
*intel,
if (!singlesample_mt)
   return NULL;
 
-   intel_region_reference(&singlesample_mt->region, region);
+   /* If this miptree is capable of supporting fast color clears, set
+* mcs_state appropriately to ensure that fast clears will occur.
+* Allocation of the MCS miptree will be deferred until the first fast
+* clear actually occurs.
+*/
+   if (intel_is_non_msrt_mcs_buffer_supported(intel, singlesample_mt))
+  singlesample_mt->mcs_state = INTEL_MCS_STATE_RESOLVED;
 
if (num_samples == 0)
   return singlesample_mt;
@@ -780,8 +786,6 @@ intel_miptree_create_for_image_buffer(struct brw_context 
*intel,
multisample_mt->singlesample_mt = singlesample_mt;
multisample_mt->need_downsample = false;
 
-   intel_region_reference(&multisample_mt->region, region);
-
if (intel->is_front_buffer_rendering && buffer_type == 
__DRI_IMAGE_BUFFER_FRONT) {
   intel_miptree_upsample(intel, multisample_mt);
}
-- 
1.8.4.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [Intel-gfx] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-11-22 Thread Keith Packard
Kristian Høgsberg  writes:

> I already explained to Keith why we use different sets of format codes
> in the DRI interface, but it's always fun to slam other peoples code.

As we discussed, my complaint isn't so much about __DRI_IMAGE_FOURCC,
but the fact that the __DRIimage interfaces use *both*
__DRI_IMAGE_FOURCC and __DRI_IMAGE_FORMAT at different times.

Ok, here's a fine thing we can actually fix -- the pattern that mesa
uses all over the place in converting formats looks like this (not to
pick on anyone, it's repeated everywhere, this is just the first one I
found in gbm_dri.c):

static uint32_t
gbm_dri_to_gbm_format(uint32_t dri_format)
{
   uint32_t ret = 0;

   switch (dri_format) {
   case __DRI_IMAGE_FORMAT_RGB565:
  ret = GBM_FORMAT_RGB565;
  break;
   case __DRI_IMAGE_FORMAT_XRGB:
  ret = GBM_FORMAT_XRGB;
  break;
   case __DRI_IMAGE_FORMAT_ARGB:
  ret = GBM_FORMAT_ARGB;
  break;
   case __DRI_IMAGE_FORMAT_ABGR:
  ret = GBM_FORMAT_ABGR;
  break;
   default:
  ret = 0;
  break;
   }

   return ret;
}

The problem here is that any unknown incoming formats get translated to
garbage (0) outgoing. With fourcc codes, there is the slight advantage
that 0 is never a legal value, but it sure would be nice to print a
warning or even abort if you get a format code you don't understand as
there's no way 0 is ever going to do what you want.

Anyone have a preference? Abort? Print an error? Silently continue to do
the wrong thing?

-- 
keith.pack...@intel.com


pgpmBS_oO7m0p.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [Intel-gfx] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-11-22 Thread Keith Packard
Ville Syrjälä  writes:

> What is this format anyway? -ENODOCS

Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)

> If its just an srgb version of ARGB, then I wouldn't really want it
> in drm_fourcc.h. I expect colorspacy stuff will be handled by various
> crtc/plane properties in the kernel so we don't need to encode that
> stuff into the fb format.

It's not any different from splitting YUV codes from RGB codes; a
different color encoding with the same bitfields. And, for mesa, it's
necessary to differentiate between ARGB and SARGB within the same format
code given how the API is structured. So, we have choices:

 1) Let Mesa define it's own fourcc codes and risk future accidental
collisions
 
 2) Rewrite piles of mesa code to split out the color encoding from the
bitfield information and pass it separately.

 3) Add "reasonable" format codes like this to the kernel fourcc list.

-- 
keith.pack...@intel.com


pgpyYJXhOW5b4.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] glx/dri3: Use four buffers until X driver supports async flips

2014-07-02 Thread Keith Packard
A driver which doesn't have async flip support will queue up flips without any
way to replace them afterwards. This means we've got a scanout buffer pinned
as soon as we schedule a flip and so we need another buffer to keep from
stalling.

When vblank_mode=0, if there are only three buffers we do:

current scanout buffer = 0 at MSC 0

Render frame 1 to buffer 1
PresentPixmap for buffer 1 at MSC 1

This is sitting down in the kernel waiting for vblank to
become the next scanout buffer

Render frame 2 to buffer 2
PresentPixmap for buffer 2 at MSC 1

This cannot be displayed at MSC 1 because the
kernel doesn't have any way to replace buffer 1 as the pending
scanout buffer. So, best case this will get displayed at MSC 2.

Now we block after this, waiting for one of the three buffers to become idle.
We can't use buffer 0 because it is the scanout buffer. We can't use buffer 1
because it's sitting in the kernel waiting to become the next scanout buffer
and we can't use buffer 2 because that's the most recent frame which will
become the next scanout buffer if the application doesn't manage to generate
another complete frame by MSC 2.

With four buffers, we get:

current scanout buffer = 0 at MSC 0

Render frame 1 to buffer 1
PresentPixmap for buffer 1 at MSC 1

This is sitting down in the kernel waiting for vblank to
become the next scanout buffer

Render frame 2 to buffer 2
PresentPixmap for buffer 2 at MSC 1

This cannot be displayed at MSC 1 because the
kernel doesn't have any way to replace buffer 1 as the pending
scanout buffer. So, best case this will get displayed at MSC
2. The X server will queue this swap until buffer 1 becomes
the scanout buffer.

Render frame 3 to buffer 3
PresentPixmap for buffer 3 at MSC 1

As soon as the X server sees this, it will replace the pending
buffer 2 swap with this swap and release buffer 2 back to the
application

Render frame 4 to buffer 2
PresentPixmap for buffer 2 at MSC 1

Now we're in a steady state, flipping between buffer 2 and 3
waiting for one of them to be queued to the kernel.

...

current scanout buffer = 1 at MSC 1

Now buffer 0 is free and (e.g.) buffer 2 is queued in
the kernel to be the scanout buffer at MSC 2

Render frames, flipping between buffer 0 and 3

When the system can replace a queued buffer, and we update Present to take
advantage of that, we can use three buffers and get:

current scanout buffer = 0 at MSC 0

Render frame 1 to buffer 1
PresentPixmap for buffer 1 at MSC 1

This is sitting waiting for vblank to become the next scanout
buffer

Render frame 2 to buffer 2
PresentPixmap for buffer 2 at MSC 1

Queue this for display at MSC 1
1. There are three possible results:

  1) We're still before MSC 1. Buffer 1 is released,
 buffer 2 is queued waiting for MSC 1.

  2) We're now after MSC 1. Buffer 0 was released at MSC 1.
 Buffer 1 is the current scanout buffer.

 a) If the user asked for a tearing update, we swap
scanout from buffer 1 to buffer 2 and release buffer
1.

 b) If the user asked for non-tearing update, we
queue buffer 2 for the MSC 2.

In all three cases, we have a buffer released (call it 'n'),
ready to receive the next frame.

Render frame 3 to buffer n
PresentPixmap for buffer n

If we're still before MSC 1, then we'll ask to present at MSC
1. Otherwise, we'll ask to present at MSC 2.

Present already does this if the driver offers async flips, however it does
this by waiting for the right vblank event and sending an async flip right at
that point.

I've hacked the intel driver to offer this, but I get tearing at the top of
the screen. I think this is because flips are always done from within the
ring, and so the latency between the vblank event and the async flip happening
can cause tearing at the top of the screen.

That's why I'm keying the need for the extra buffer on the lack of 2D
driver support for async flips.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  | 20 +++-
 src/glx/dri3_priv.h |  6 +-
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri

Re: [Mesa-dev] [PATCH] intel: Track known prime buffers for re-use

2013-11-25 Thread Keith Packard
Daniel Vetter  writes:

> Yeah, it unfortunately took a few rounds of kernel fixes and other
> haggling to get the semantics right on this one. The kernel atm promises
> to userspace (minus one big in a racy corner case no one should care
> about, still need to fix that one) that it'll return the same gem handle
> if userspace already has one for the underlying object.

That's definitely something we want it to do -- returning different
handles to the same object would result in madness. We just need to deal with 
the
userspace consequences.

> We need that to make sure userspace doesn't submit the same bo in execbuf
> multiple times and then upsets the kernel - we'll reject such batches as
> userspace bugs.

Oh, I'm well aware of that; you can imagine the adventures I had trying
to debug this...

>> -DRMINITLISTHEAD(&bo_gem->name_list);
>>  DRMINITLISTHEAD(&bo_gem->vma_list);
>> +DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->prime);
>
> Won't this result in us having fun when a buffer is both imported from a
> prime buffer and then also used with legacy flink? Or is this something
> the X server won't support?

Well, the whole point of prime-based FD buffer passing is to *not* use
flink, of course. However, you could use both DRI2 and DRI3 on
the same pixmap (presumably through different APIs).

Ok, I just tried to create a completely separate prime list for this,
and I think that's wrong. If the question is whether the kernel might
return the same object from two calls, then we'd best actually keep a
single list and look things up for both APIs there. *and*, I think we
need to do the flink->gem handle conversion and then look in the list
again to see if that gem handle was already returned from another flink
or prime fd.

> The second one is about exporting: With flink names we also add the name
> to the lookup list in drm_intel_gem_bo_flink. I think we should do the
> same for exported prime buffers just as a precaution - the kernel will
> return the (existing) gem name also for a prime buffer that has been
> exported by yourself. I guess that would imply insane userspace, but
> better safe than sorry.

yeah, that would seem like crazy user-space behaviour, but user space
often seems insane.

Thanks for your review; replacement patch to follow shortly.

-- 
keith.pack...@intel.com


pgpfCvqKcIVq9.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use

2013-11-25 Thread Keith Packard
If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.

Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.

Also checks for prime buffers in the flink case.

Signed-off-by: Keith Packard 
---
 intel/intel_bufmgr_gem.c | 50 +---
 1 file changed, 43 insertions(+), 7 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index df6fcec..2b7fe07 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -149,6 +149,8 @@ struct _drm_intel_bo_gem {
 
/**
 * Kenel-assigned global name for this object
+ *
+ * List contains both flink named and prime fd'd objects
 */
unsigned int global_name;
drmMMListHead name_list;
@@ -862,10 +864,6 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr,
}
}
 
-   bo_gem = calloc(1, sizeof(*bo_gem));
-   if (!bo_gem)
-   return NULL;
-
VG_CLEAR(open_arg);
open_arg.name = handle;
ret = drmIoctl(bufmgr_gem->fd,
@@ -874,9 +872,26 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr,
if (ret != 0) {
DBG("Couldn't reference %s handle 0x%08x: %s\n",
name, handle, strerror(errno));
-   free(bo_gem);
return NULL;
}
+/* Now see if someone has used a prime handle to get this
+ * object from the kernel before by looking through the list
+ * again for a matching gem_handle
+ */
+   for (list = bufmgr_gem->named.next;
+list != &bufmgr_gem->named;
+list = list->next) {
+   bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
+   if (bo_gem->gem_handle == open_arg.handle) {
+   drm_intel_gem_bo_reference(&bo_gem->bo);
+   return &bo_gem->bo;
+   }
+   }
+
+   bo_gem = calloc(1, sizeof(*bo_gem));
+   if (!bo_gem)
+   return NULL;
+
bo_gem->bo.size = open_arg.size;
bo_gem->bo.offset = 0;
bo_gem->bo.virtual = NULL;
@@ -2451,8 +2466,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
*bufmgr, int prime_fd, int s
uint32_t handle;
drm_intel_bo_gem *bo_gem;
struct drm_i915_gem_get_tiling get_tiling;
+   drmMMListHead *list;
 
ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, &handle);
+
+   /*
+* See if the kernel has already returned this buffer to us. Just as
+* for named buffers, we must not create two bo's pointing at the same
+* kernel object
+*/
+   for (list = bufmgr_gem->named.next;
+list != &bufmgr_gem->named;
+list = list->next) {
+   bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
+   if (bo_gem->gem_handle == handle) {
+   drm_intel_gem_bo_reference(&bo_gem->bo);
+   return &bo_gem->bo;
+   }
+   }
+
if (ret) {
  fprintf(stderr,"ret is %d %d\n", ret, errno);
return NULL;
@@ -2487,8 +2519,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr 
*bufmgr, int prime_fd, int s
bo_gem->has_error = false;
bo_gem->reusable = false;
 
-   DRMINITLISTHEAD(&bo_gem->name_list);
DRMINITLISTHEAD(&bo_gem->vma_list);
+   DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
 
VG_CLEAR(get_tiling);
get_tiling.handle = bo_gem->gem_handle;
@@ -2513,6 +2545,9 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int 
*prime_fd)
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
 
+if (DRMLISTEMPTY(&bo_gem->name_list))
+DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
+
if (drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
   DRM_CLOEXEC, prime_fd) != 0)
return -errno;
@@ -2542,7 +2577,8 @@ drm_intel_gem_bo_flink(drm_intel_bo *bo, uint32_t * name)
bo_gem->global_name = flink.name;
bo_gem->reusable = false;
 
-   DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
+if (DRMLISTEMPTY(&bo_gem->name_list))
+DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
}
 
*name = bo_gem->global_name;
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] dri3: Support GLX_INTEL_swap_event

2013-11-25 Thread Keith Packard
Eric Anholt  writes:

> I'd prefer to see sbc stay with its current name, since that's its name
> in the specs we're trying to implement (GLX_OML_sync_control,
> GLX_INTEL_swap_event).  If you drop the rename from the patch,
>
> Reviewed-by: Eric Anholt 

Sounds good.

> I read that as "SBC is incremented when the PresentComplete comes in"
> not "SBC is incremented when we generate the Present request".
> Otherwise glXWaitForSbcOML doesn't make much sense. (in the "e.g." I'm
> assuming they're talking a hardware register for pageflipping that
> immediately starts scanning out the new stuff, not our fancy new
> automatically double buffered ones that you have to push hard on to get
> an immediate pageflip mode)

Oh, that's almost sensible. And nicely eliminates the silly sleep(1)
loop. New patches coming shortly.

-- 
keith.pack...@intel.com


pgppjA6dKRi9F.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] present: Send GLX_BufferSwapComplete events from present extension

2013-11-25 Thread Keith Packard
Eric Anholt  writes:

> There's a minor behavior change that the event now gets sent to the
> drawable owner rather than the caller of DRI2SwapBuffers.

Yeah, probably not ideal, especially when the GLX drawable is created
using the window XID (as is the case for some older GLX clients). I
don't have the original client at the time the event is generated, but I
think I can go back and stick it in; will require tracking when the
client exits, of course.

> I don't expect it to matter in practice (I expect that the
> swap-requesting client using this GLX extension is also the
> drawable-creating one), and either choice seems wrong compared to "send
> the event to everyone listening for the event on this drawable".  That
> would be a separate change, anyway.

I think the original behaviour, sending the event to the client who sent
the PresentPixmap request is the only sane plan, and only a bit more
complicated than sending it to the drawable owner.

I'll cook up an alternate patch and send that along; we can then compare
the two approaches at least.

-- 
keith.pack...@intel.com


pgphrF2sBXa1F.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/4] dri3: Clean up struct dri3_drawable

2013-11-25 Thread Keith Packard
Move the depth field up with width and height.

Remove unused previous_time and frames fields.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_priv.h | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 05f66cf..34c67a6 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -177,7 +177,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
 struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
-   int width, height;
+   int width, height, depth;
int swap_interval;
uint8_t have_back;
uint8_t have_fake_front;
@@ -193,13 +193,9 @@ struct dri3_drawable {
/* For WaitMSC */
uint32_t present_msc_request_serial;
uint32_t present_msc_event_serial;
-   
-   uint64_t previous_time;
-   unsigned frames;
 
struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
-   int depth;
 
uint32_t *stamp;
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/4] dri3: Track full 64-bit SBC numbers, instead of just 32-bits

2013-11-25 Thread Keith Packard
Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number that
we use to pass the SBC value from request to event.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  | 34 +-
 src/glx/dri3_priv.h | 16 +---
 2 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 669f0bb..c0915f2 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -364,10 +364,17 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
xcb_present_generic_event_
case XCB_PRESENT_COMPLETE_NOTIFY: {
   xcb_present_complete_notify_event_t *ce = (void *) ge;
 
-  if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP)
- priv->present_event_serial = ce->serial;
-  else
- priv->present_msc_event_serial = ce->serial;
+  /* Compute the processed SBC number from the received 32-bit serial 
number merged
+   * with the upper 32-bits of the sent 64-bit serial number while 
checking for
+   * wrap
+   */
+  if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
+ priv->recv_sbc = (priv->send_sbc & 0xLL) | ce->serial;
+ if (priv->recv_sbc > priv->send_sbc)
+priv->recv_sbc -= 0x1;
+  } else {
+ priv->recv_msc_serial = ce->serial;
+  }
   priv->ust = ce->ust;
   priv->msc = ce->msc;
   break;
@@ -398,12 +405,13 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
+   uint32_t msc_serial;
 
/* Ask for the an event for the target MSC */
-   ++priv->present_msc_request_serial;
+   msc_serial = ++priv->send_msc_serial;
xcb_present_notify_msc(c,
   priv->base.xDrawable,
-  priv->present_msc_request_serial,
+  msc_serial,
   target_msc,
   divisor,
   remainder);
@@ -412,7 +420,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 
/* Wait for the event */
if (priv->special_event) {
-  while (priv->present_msc_request_serial != 
priv->present_msc_event_serial) {
+  while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
  ev = xcb_wait_for_special_event(c, priv->special_event);
  if (!ev)
 break;
@@ -423,7 +431,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 
*ust = priv->ust;
*msc = priv->msc;
-   *sbc = priv->sbc;
+   *sbc = priv->recv_sbc;
 
return 1;
 }
@@ -450,7 +458,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
 
-   while (priv->sbc < target_sbc) {
+   while (priv->send_sbc < target_sbc) {
   sleep(1);
}
return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
@@ -1282,15 +1290,15 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
   /* Compute when we want the frame shown by taking the last known 
successful
* MSC and adding in a swap interval for each outstanding swap request
*/
-  ++priv->present_request_serial;
+  ++priv->send_sbc;
   if (target_msc == 0)
- target_msc = priv->msc + priv->swap_interval * 
(priv->present_request_serial - priv->present_event_serial);
+ target_msc = priv->msc + priv->swap_interval * (priv->send_sbc - 
priv->recv_sbc);
 
   priv->buffers[buf_id]->busy = 1;
   xcb_present_pixmap(c,
  priv->base.xDrawable,
  priv->buffers[buf_id]->pixmap,
- priv->present_request_serial,
+ (uint32_t) priv->send_sbc,
  0,/* valid */
  0,/* update */
  0,/* x_off */
@@ -1302,7 +1310,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
  target_msc,
  divisor,
  remainder, 0, NULL);
-  ret = ++priv->sbc;
+  ret = (int64_t) priv->send_sbc;
 
   /* If there's a fake front, then copy the source back buffer
* to the fake front to keep it up to date. This needs
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 34c67a6..f1fec3c 100644
--- 

[Mesa-dev] [PATCH 3/4] dri3: Fix dri3_wait_for_sbc to wait for completion of requested SBC

2013-11-25 Thread Keith Packard
Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC
had been completed, which means to wait until the PresentCompleteNotify event
for that SBC had been received.

This replaces the simple sleep(1) loop (which was bogus) with a loop that just
checks to see if we've seen the specified SBC value come back in a
PresentCompleteNotify event yet.

The change is a bit larger than that as I've broken out a piece of common code
to wait for and process a single Present event for the target drawable.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 55 ++
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index c0915f2..da3f08b 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -397,14 +397,33 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
xcb_present_generic_event_
free(ge);
 }
 
+static bool
+dri3_wait_for_event(__GLXDRIdrawable *pdraw)
+{
+   xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
+   struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+   xcb_generic_event_t *ev;
+   xcb_present_generic_event_t *ge;
+
+   ev = xcb_wait_for_special_event(c, priv->special_event);
+   if (!ev)
+  return false;
+   ge = (void *) ev;
+   dri3_handle_present_event(priv, ge);
+   return true;
+}
+
+/** dri3_wait_for_msc
+ *
+ * Get the X server to send an event when the target msc/divisor/remainder is
+ * reached.
+ */
 static int
 dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
   int64_t remainder, int64_t *ust, int64_t *msc, int64_t *sbc)
 {
xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
-   xcb_generic_event_t *ev;
-   xcb_present_generic_event_t *ge;
uint32_t msc_serial;
 
/* Ask for the an event for the target MSC */
@@ -421,11 +440,8 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
/* Wait for the event */
if (priv->special_event) {
   while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
- ev = xcb_wait_for_special_event(c, priv->special_event);
- if (!ev)
-break;
- ge = (void *) ev;
- dri3_handle_present_event(priv, ge);
+ if (!dri3_wait_for_event(pdraw))
+return 0;
   }
}
 
@@ -436,6 +452,11 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
return 1;
 }
 
+/** dri3_drawable_get_msc
+ *
+ * Return the current UST/MSC/SBC triplet by asking the server
+ * for an event
+ */
 static int
 dri3_drawable_get_msc(struct glx_screen *psc, __GLXDRIdrawable *pdraw,
   int64_t *ust, int64_t *msc, int64_t *sbc)
@@ -445,12 +466,9 @@ dri3_drawable_get_msc(struct glx_screen *psc, 
__GLXDRIdrawable *pdraw,
 
 /** dri3_wait_for_sbc
  *
- * Wait for the swap buffer count to increase. The only way this
- * can happen is if some other thread is doing swap buffers as
- * we no longer share swap buffer counts with other processes.
- *
- * I'm not sure this is actually useful as such, and so this
- * implementation is a kludge that just polls once a second
+ * Wait for the completed swap buffer count to reach the specified
+ * target. Presumably the application knows that this will be reached with
+ * outstanding complete events, or we're going to be here awhile.
  */
 static int
 dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t target_sbc, int64_t *ust,
@@ -458,10 +476,15 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
 
-   while (priv->send_sbc < target_sbc) {
-  sleep(1);
+   while (priv->recv_sbc < target_sbc) {
+  if (!dri3_wait_for_event(pdraw))
+ return 0;
}
-   return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
+
+   *ust = priv->ust;
+   *msc = priv->msc;
+   *sbc = priv->recv_sbc;
+   return 1;
 }
 
 /**
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 4/4] dri3: Enable GLX_INTEL_swap_event

2013-11-25 Thread Keith Packard
Now that we're tracking SBC values correctly, and the X server has the ability
to send the GLX swap events from a PresentPixmap request, enable this extension.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index da3f08b..aa5dd21 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1525,23 +1525,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct 
glx_display * priv,
__glXEnableDirectExtension(&psc->base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_SGI_make_current_read");
-
-   /*
-* GLX_INTEL_swap_event is broken on the server side, where it's
-* currently unconditionally enabled. This completely breaks
-* systems running on drivers which don't support that extension.
-* There's no way to test for its presence on this side, so instead
-* of disabling it unconditionally, just disable it for drivers
-* which are known to not support it, or for DDX drivers supporting
-* only an older (pre-ScheduleSwap) version of DRI2.
-*
-* This is a hack which is required until:
-* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
-* is merged and updated xserver makes it's way into distros:
-*/
-//   if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) {
-//  __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
-//   }
+   __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
 
mask = psc->image_driver->getAPIMask(psc->driScreen);
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 0/4] Clean up dri3 SBC handling, enable GLX_INTEL_swap_event

2013-11-25 Thread Keith Packard
I've split the GLX_INTEL_swap_event enabling patch into four bits -- the first
three just fix the existing code to track SBC values correctly and to fix
wait_for_sbc. The fourth is the trivial patch to actually turn on the new
extension; all of the hard work for that is actually dealt with in the X
server.

 [PATCH 1/4] dri3: Clean up struct dri3_drawable

Trivial struct member cleanup -- a couple of unused fields, and one oddly
placed field.

 [PATCH 2/4] dri3: Track full 64-bit SBC numbers, instead of just

This switches all of the internal SBC tracking to use 64-bit values. I use
uint64_t because I don't trust compilers with signed integer comparisons that
may wrap any more.

 [PATCH 3/4] dri3: Fix dri3_wait_for_sbc to wait for completion of

This one makes wait_for_sbc actually wait for the completion of the specified
swap, rather than the queuing of that value. Makes *far* more sense this way.

 [PATCH 4/4] dri3: Enable GLX_INTEL_swap_event

The trivial patch that just adds the extension to the list.

-keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] intel: Track known prime buffers for re-use

2013-11-26 Thread Keith Packard
Daniel Vetter  writes:

> The kernel actually doesn't bother with this, i.e. an open on an flink
> name will always create a new handle. Given that it was a major pita to
> get the prime reimporting going (due to a pile of funny lifetime issues
> around reference loops and some assorted locking fun) I'm not volunteering
> to fix this ;-) And I also think that a piece of userspace which both
> flink-opens and prime imports on the same buffer gets both pieces.

That seems pretty dangerous to me -- you'll end up with aliases to the
same buffer this way if user space isn't careful.

I bet you check duplicate buffer usage by pointer and not ID though,
which means user space will get errors when this happens. That's not
terrible, but it isn't great either as there's this nasty call to
exit(1) when the execbuffers fails...

> Otoh this can't hurt either, so if you want to stick with this hunk maybe
> add a small comment saying that the kernel lies. Or just remove it. Either
> way:

Not being able to test it is a bit sub-optimal; the duplicate handle
case for prime was well tested by the time I submitted that patch...

> Reviewed-by: Daniel Vetter 

thanks.

> Aside: I think drm is the only subsystem that goes out of it's way to
> ensure a unique relationship between dmabuf and other handles and
> underlying objects. If you throw v4l into the mix (e.g. by building a
> gstreamer pipe that feeds into an egl image or so) I expect some fun to
> happen. Otoh no open-source v4l driver for intel socs, so lalala ;-)

Some kind of standard of conduct is clearly needed here - not letting
user space know they've got aliasing going on is pretty mean.

-- 
keith.pack...@intel.com


pgplDH2IGYe13.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC PATCH] dri megadriver_stub: provide compatibility with older DRI loader

2013-12-06 Thread Keith Packard
Jordan Justen  writes:

>> We find the driver foo's name by using the dladdr function
>> which gives the path of the dynamic library's name that
>> was being loaded.

That sounds like all kinds of win for existing X servers. Thanks for
doing it up in style, so that a megadrivers build can actually work for
all chips in the megadriver.

(as a style issue, I probably would have computed the driver name from
the dli_fname value directly and then copied it out into new storage, or
directly into get_extensions_name, but that's just me, so you should
feel free to ignore it :-)

>> +   /* Make sure the patch ends with _dri.so */
>> +   name_len = strlen(driver_name);
>> +   if (strcmp(driver_name + (name_len - 7), "_dri.so") != 0) {

Need to make sure name_len is >= 7 here. Should probably just have a
test that checks namelen and bails if it's < 7 as there are other places
using this magic value.

(Oh, I'd probably stick "_dri.so" in a #define and then #define the
length of it too, instead of using '7' in several places. Again, style,
not substance, so you can ignore that as you please.)

>> +   i = asprintf(&get_extensions_name, "%s_%s",
>> +__DRI_DRIVER_GET_EXTENSIONS, driver_name);
>> +   free(driver_path);
>> +   if (i == -1 || !get_extensions_name)
>> +  return;

Is the null pointer check here useful or necessary? asprintf doesn't
define the value when allocation fails, preferring to return -1
instead. Are there systems which return valid 'i' and null pointer?

>> +   /* Copy the extensions into the __driDriverExtensions array
>> +* we declared.
>> +*/
>> +   for (i = 0; i < ARRAY_SIZE(__driDriverExtensions); i++) {
>> +  __driDriverExtensions[i] = extensions[i];
>> +  if (extensions[i] == NULL)
>> + break;
>> +   }
>> +
>> +   /* If the driver had more extensions that we reserved, then
>> +* bail out. This will cause the driver to fail to load using
>> +* the older loader mechanism.
>> +*/
>> +   if (extensions[i] != NULL) {

This check is incorrect -- you will dereference off the end of the array
when you fill it. Instead, you should just check for

if (i == ARRAY_SIZE(__driDriverExtensions))

as that will let you know the array was filled

-- 
keith.pack...@intel.com


pgpBROPNRy1Ba.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3] dri megadriver_stub: add compatibility for older DRI loaders

2013-12-09 Thread Keith Packard
Jordan Justen  writes:

> To help the transition period when DRI loaders are being updated
> to support the newer __driDriverExtensions_foo mechanism,
> we populate __driDriverExtensions with the extensions returned
> by __driDriverExtensions_foo during a library contructor
> function.
>
> We find the driver foo's name by using the dladdr function
> which gives the path of the dynamic library's name that
> was being loaded.
>
> v2:
>  * dladdr on public symbol __driDriverExtensions rather
>than static megadriver_stub_init.
>  * Incorporate fixes and suggestions from Keith

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgp1rPNEULXgK.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] Remove glBlendColor and glBlendEquations decls from glext.h

2013-12-11 Thread Keith Packard
These are duplicates from gl.h; I'm not sure which file they belong in, but
you don't get to have them in both places.

Signed-off-by: Keith Packard 
---
 include/GL/glext.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/GL/glext.h b/include/GL/glext.h
index fea9e1f..4c0a373 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -457,8 +457,6 @@ GLAPI void APIENTRY glWindowPos3i (GLint x, GLint y, GLint 
z);
 GLAPI void APIENTRY glWindowPos3iv (const GLint *v);
 GLAPI void APIENTRY glWindowPos3s (GLshort x, GLshort y, GLshort z);
 GLAPI void APIENTRY glWindowPos3sv (const GLshort *v);
-GLAPI void APIENTRY glBlendColor (GLfloat red, GLfloat green, GLfloat blue, 
GLfloat alpha);
-GLAPI void APIENTRY glBlendEquation (GLenum mode);
 #endif
 #endif /* GL_VERSION_1_4 */
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] Mark drmServerInfo.debug_print with printf attribute

2013-12-11 Thread Keith Packard
I stole the conditional for _X_ATTRIBUTE_PRINTF from xproto and
changed the name to _DRM_ATTRIBUTE_PRINTF to avoid future conflicts.

Signed-off-by: Keith Packard 
---
 xf86drm.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xf86drm.h b/xf86drm.h
index 1e763a3..0bf205f 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -92,8 +92,15 @@ extern "C" {
 typedef unsigned int  drmSize, *drmSizePtr;/**< For mapped 
regions */
 typedef void  *drmAddress, **drmAddressPtr; /**< For mapped regions */
 
+/* Added in X11R6.9, so available in any version of modular xproto */
+#if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 203)
+# define _DRM_ATTRIBUTE_PRINTF(x,y) __attribute__((__format__(__printf__,x,y)))
+#else /* not gcc >= 2.3 */
+# define _DRM_ATTRIBUTE_PRINTF(x,y)
+#endif
+
 typedef struct _drmServerInfo {
-  int (*debug_print)(const char *format, va_list ap);
+  int (*debug_print)(const char *format, va_list ap) 
_DRM_ATTRIBUTE_PRINTF(1,0);
   int (*load_module)(const char *name);
   void (*get_perms)(gid_t *, mode_t *);
 } drmServerInfo, *drmServerInfoPtr;
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Mark drmServerInfo.debug_print with printf attribute

2013-12-11 Thread Keith Packard
Alan Coopersmith  writes:

> You should drop that line - those comments are used for us to figure out which
> xproto version to list in the pkg-config requirements when using newer _X_* 
> macros out of Xfuncproto.h, so doesn't make sense here.
>
> Also be warned that using a macro name starting with an _ will cause you to 
> get
> complaints about violating the "reserved for the implementation" rule in the
> ANSI/ISO C standards from people who consider the implementation to solely be
> the compiler, not the OS.  https://bugs.freedesktop.org/show_bug.cgi?id=70686
> for example.

Thanks for the suggestions; both easy to adopt.

-- 
keith.pack...@intel.com


pgp2s4VkofGWK.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-12-13 Thread Keith Packard
Kenneth Graunke  writes:

> I see that Eric reviewed it, and that it has not landed.  Are there any
> objections to merging it?

They're on top of a series of DRI3/Present patches, not all of which
have seen review. I was hoping the rest of that series would get
reviewed so that I could merge it all at the same time.

Eric also suggested that we change the switch statements using these
defines to catch unknown values and provide some better indication than
the silent failure I was experiencing.

-- 
keith.pack...@intel.com


pgphTFkN0Tfov.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 02/18] dri/swrast: Passing dri_context * instead of gl_context* to driContextSetFlags

2013-12-13 Thread Keith Packard
These are the same address, but different types and driContextSetFlags wants
a gl_context pointer.

Signed-off-by: Keith Packard 
---
 src/mesa/drivers/dri/swrast/swrast.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
b/src/mesa/drivers/dri/swrast/swrast.c
index cfa9316..79a2740 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -705,7 +705,7 @@ dri_create_context(gl_api api,
goto context_fail;
 }
 
-driContextSetFlags(ctx, flags);
+driContextSetFlags(mesaCtx, flags);
 
 /* do bounds checking to prevent segfaults and server crashes! */
 mesaCtx->Const.CheckArrayBounds = GL_TRUE;
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 01/18] Remove glBlendColor and glBlendEquations decls from glext.h

2013-12-13 Thread Keith Packard
These are duplicates from gl.h; I'm not sure which file they belong in, but
you don't get to have them in both places.

Signed-off-by: Keith Packard 
---
 include/GL/glext.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/GL/glext.h b/include/GL/glext.h
index 7d6033e..b432d2e 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -457,8 +457,6 @@ GLAPI void APIENTRY glWindowPos3i (GLint x, GLint y, GLint 
z);
 GLAPI void APIENTRY glWindowPos3iv (const GLint *v);
 GLAPI void APIENTRY glWindowPos3s (GLshort x, GLshort y, GLshort z);
 GLAPI void APIENTRY glWindowPos3sv (const GLshort *v);
-GLAPI void APIENTRY glBlendColor (GLfloat red, GLfloat green, GLfloat blue, 
GLfloat alpha);
-GLAPI void APIENTRY glBlendEquation (GLenum mode);
 #endif
 #endif /* GL_VERSION_1_4 */
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 12/18] dri3: Rename DRI3_MAX_BACK to DRI3_NUM_BACK

2013-12-13 Thread Keith Packard
It is the maximum number of back buffers, but the name is confusing and is
easily read as the maximum back buffer index. Chage to DRI3_NUM_BACK to make
the intended usage a bit clearer.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  |  4 ++--
 src/glx/dri3_priv.h | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index ea20138..c26d6e5 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1065,7 +1065,7 @@ dri3_find_back(xcb_connection_t *c, struct dri3_drawable 
*priv)
 
for (;;) {
 
-  for (b = 0; b < DRI3_MAX_BACK; b++) {
+  for (b = 0; b < DRI3_NUM_BACK; b++) {
  intid = DRI3_BACK_ID(b);
  struct dri3_buffer*buffer = priv->buffers[id];
 
@@ -1181,7 +1181,7 @@ dri3_free_buffers(__DRIdrawable *driDrawable,
switch (buffer_type) {
case dri3_buffer_back:
   first_id = DRI3_BACK_ID(0);
-  n_id = DRI3_MAX_BACK;
+  n_id = DRI3_NUM_BACK;
   break;
case dri3_buffer_front:
   first_id = DRI3_FRONT_ID;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 4c5579e..49a13ba 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -143,14 +143,14 @@ struct dri3_context
__DRIcontext *driContext;
 };
 
-#define DRI3_MAX_BACK   2
+#define DRI3_NUM_BACK   2
 #define DRI3_BACK_ID(i) (i)
-#define DRI3_FRONT_ID   (DRI3_MAX_BACK)
+#define DRI3_FRONT_ID   (DRI3_NUM_BACK)
 
 static inline int
 dri3_buf_id_next(int buf_id)
 {
-   if (buf_id == DRI3_MAX_BACK - 1)
+   if (buf_id == DRI3_NUM_BACK - 1)
   return 0;
return buf_id + 1;
 }
@@ -159,7 +159,7 @@ static inline int
 dri3_buf_id_prev(int buf_id)
 {
if (buf_id == 0)
-  return DRI3_MAX_BACK - 1;
+  return DRI3_NUM_BACK - 1;
return buf_id - 1;
 }
 
@@ -172,7 +172,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
   return DRI3_FRONT_ID;
 }
 
-#define DRI3_NUM_BUFFERS(1 + DRI3_MAX_BACK)
+#define DRI3_NUM_BUFFERS(1 + DRI3_NUM_BACK)
 
 struct dri3_drawable {
__GLXDRIdrawable base;
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 00/18] dri3+gallium patch series

2013-12-13 Thread Keith Packard
This series has a bunch of DRI3 cleanups and fixes followed by a few patches
that finish up DRI3 support in gallium.

The first two patches have nothing to do with DRI3, just some warning fixes:

 [PATCH 01/18] Remove glBlendColor and glBlendEquations decls from
 [PATCH 02/18] dri/swrast: Passing dri_context * instead of

DRI3 cleanups

 [PATCH 03/18] Don't use libudev for glx/dri3
 [PATCH 04/18] dri3: Switch to libxshmfence version 1.1
 [PATCH 05/18] dri3: Free resources when drawable is destroyed.
 [PATCH 06/18] dri3: Clean up struct dri3_drawable
 [PATCH 07/18] dri3: Track full 64-bit SBC numbers, instead of just
 [PATCH 08/18] dri3: Fix dri3_wait_for_sbc to wait for completion of
 [PATCH 09/18] dri3: Enable GLX_INTEL_swap_event
 [PATCH 10/18] i965: Correct check for re-bound buffer in
 [PATCH 11/18] i965: Set fast color clear mcs_state on newly allocated
 [PATCH 12/18] dri3: Rename DRI3_MAX_BACK to DRI3_NUM_BACK
 [PATCH 13/18] dri3: Flush XCB before blocking for special events
 [PATCH 14/18] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB

And the gallium patches: The middle two are from Ben Skeggs, but haven't been
reviewed and not in an area of the code I feel comfortable reviewing.

 [PATCH 15/18] gallium: Add __DRIimageDriverExtension support to
 [PATCH 16/18] gallium/dri: fix unsetting of format when encountering
 [PATCH 17/18] nvc0: fix segfault if nv50_miptree_from_handle() fails
 [PATCH 18/18] gallium: Use base.stamp for all drawable invalidation
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 07/18] dri3: Track full 64-bit SBC numbers, instead of just 32-bits

2013-12-13 Thread Keith Packard
Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number that
we use to pass the SBC value from request to event.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  | 34 +-
 src/glx/dri3_priv.h | 16 +---
 2 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 4c0dc29..b9a786f 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -364,10 +364,17 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
xcb_present_generic_event_
case XCB_PRESENT_COMPLETE_NOTIFY: {
   xcb_present_complete_notify_event_t *ce = (void *) ge;
 
-  if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP)
- priv->present_event_serial = ce->serial;
-  else
- priv->present_msc_event_serial = ce->serial;
+  /* Compute the processed SBC number from the received 32-bit serial 
number merged
+   * with the upper 32-bits of the sent 64-bit serial number while 
checking for
+   * wrap
+   */
+  if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
+ priv->recv_sbc = (priv->send_sbc & 0xLL) | ce->serial;
+ if (priv->recv_sbc > priv->send_sbc)
+priv->recv_sbc -= 0x1;
+  } else {
+ priv->recv_msc_serial = ce->serial;
+  }
   priv->ust = ce->ust;
   priv->msc = ce->msc;
   break;
@@ -398,12 +405,13 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
+   uint32_t msc_serial;
 
/* Ask for the an event for the target MSC */
-   ++priv->present_msc_request_serial;
+   msc_serial = ++priv->send_msc_serial;
xcb_present_notify_msc(c,
   priv->base.xDrawable,
-  priv->present_msc_request_serial,
+  msc_serial,
   target_msc,
   divisor,
   remainder);
@@ -412,7 +420,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 
/* Wait for the event */
if (priv->special_event) {
-  while (priv->present_msc_request_serial != 
priv->present_msc_event_serial) {
+  while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
  ev = xcb_wait_for_special_event(c, priv->special_event);
  if (!ev)
 break;
@@ -423,7 +431,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
 
*ust = priv->ust;
*msc = priv->msc;
-   *sbc = priv->sbc;
+   *sbc = priv->recv_sbc;
 
return 1;
 }
@@ -450,7 +458,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
 
-   while (priv->sbc < target_sbc) {
+   while (priv->send_sbc < target_sbc) {
   sleep(1);
}
return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
@@ -1281,15 +1289,15 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
   /* Compute when we want the frame shown by taking the last known 
successful
* MSC and adding in a swap interval for each outstanding swap request
*/
-  ++priv->present_request_serial;
+  ++priv->send_sbc;
   if (target_msc == 0)
- target_msc = priv->msc + priv->swap_interval * 
(priv->present_request_serial - priv->present_event_serial);
+ target_msc = priv->msc + priv->swap_interval * (priv->send_sbc - 
priv->recv_sbc);
 
   priv->buffers[buf_id]->busy = 1;
   xcb_present_pixmap(c,
  priv->base.xDrawable,
  priv->buffers[buf_id]->pixmap,
- priv->present_request_serial,
+ (uint32_t) priv->send_sbc,
  0,/* valid */
  0,/* update */
  0,/* x_off */
@@ -1301,7 +1309,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
  target_msc,
  divisor,
  remainder, 0, NULL);
-  ret = ++priv->sbc;
+  ret = (int64_t) priv->send_sbc;
 
   /* If there's a fake front, then copy the source back buffer
* to the fake front to keep it up to date. This needs
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 4adef50..4c5579e 100644
--- 

[Mesa-dev] [PATCH 03/18] Don't use libudev for glx/dri3

2013-12-13 Thread Keith Packard
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.

Signed-off-by: Keith Packard 
---
 configure.ac  |  8 -
 src/glx/dri3_common.c | 85 ++-
 2 files changed, 50 insertions(+), 43 deletions(-)

diff --git a/configure.ac b/configure.ac
index c14d39a..1193cff 100644
--- a/configure.ac
+++ b/configure.ac
@@ -824,9 +824,6 @@ xyesno)
 PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
 GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
 if test x"$enable_dri3" = xyes; then
-if test x"$have_libudev" != xyes; then
-  AC_MSG_ERROR([DRI3 requires libudev >= $LIBUDEV_REQUIRED])
-fi
 PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
 PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >= 
$PRESENTPROTO_REQUIRED])
 fi
@@ -850,11 +847,6 @@ xyesno)
 X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
 GL_LIB_DEPS="$DRIGL_LIBS"
 
-if test x"$enable_dri3$have_libudev" = xyesyes; then
-X11_INCLUDES="$X11_INCLUDES $LIBUDEV_CFLAGS"
-GL_LIB_DEPS="$GL_LIB_DEPS $LIBUDEV_LIBS"
-fi
-
 # need DRM libs, $PTHREAD_LIBS, etc.
 GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
 GL_PC_LIB_PRIV="-lm $PTHREAD_LIBS $DLOPEN_LIBS"
diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
index c758f96..511fbc8 100644
--- a/src/glx/dri3_common.c
+++ b/src/glx/dri3_common.c
@@ -23,7 +23,7 @@
 /*
  * This code is derived from src/egl/drivers/dri2/common.c which
  * carries the following copyright:
- * 
+ *
  * Copyright ?? 2011 Intel Corporation
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -67,62 +67,80 @@
 #include 
 #include 
 #include 
+#include 
 #include "xf86drm.h"
 #include "dri_common.h"
 #include "dri3_priv.h"
 
 #define DRIVER_MAP_DRI3_ONLY
-#include "pci_ids/pci_id_driver_map.h"
 
-#include 
+#include "pci_ids/pci_id_driver_map.h"
 
-static struct udev_device *
-dri3_udev_device_new_from_fd(struct udev *udev, int fd)
+static dev_t
+dri3_rdev_from_fd(int fd)
 {
-   struct udev_device *device;
struct stat buf;
 
if (fstat(fd, &buf) < 0) {
   ErrorMessageF("DRI3: failed to stat fd %d", fd);
-  return NULL;
+  return 0;
}
+   return buf.st_rdev;
+}
 
-   device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
-   if (device == NULL) {
-  ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
-  return NULL;
-   }
+/*
+ * There are multiple udev library versions, and they aren't polite about
+ * symbols, so just avoid using it until some glorious future when the udev
+ * developers figure out how to not break things
+ */
 
-   return device;
+#define SYS_PATH_MAX256
+
+static bool
+dri3_read_hex(dev_t rdev, char *entry, int *value)
+{
+   char path[SYS_PATH_MAX];
+   FILE *f;
+   int  r;
+
+   snprintf(path, sizeof (path), "/sys/dev/char/%u:%u/device/%s",
+major(rdev), minor(rdev), entry);
+
+   f = fopen(path,"r");
+   if (f == NULL)
+  return false;
+
+   r = fscanf(f, "0x%x\n", value);
+   fclose(f);
+   if (r != 1)
+  return false;
+   return true;
+}
+
+static bool
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
+{
+   dev_trdev = dri3_rdev_from_fd(fd);
+
+   if (!rdev)
+  return false;
+
+   if (!dri3_read_hex(rdev, "vendor", vendorp))
+  return false;
+   if (!dri3_read_hex(rdev, "device", chipp))
+  return false;
+   return true;
 }
 
 char *
 dri3_get_driver_for_fd(int fd)
 {
-   struct udev *udev;
-   struct udev_device *device, *parent;
-   const char *pci_id;
char *driver = NULL;
int vendor_id, chip_id, i, j;
 
-   udev = udev_new();
-   device = dri3_udev_device_new_from_fd(udev, fd);
-   if (device == NULL)
+   if (!dri3_get_pci_id_from_fd(fd, &vendor_id, &chip_id))
   return NULL;
 
-   parent = udev_device_get_parent(device);
-   if (parent == NULL) {
-  ErrorMessageF("DRI3: could not get parent device");
-  goto out;
-   }
-
-   pci_id = udev_device_get_property_value(parent, "PCI_ID");
-   if (pci_id == NULL ||
-   sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
-  ErrorMessageF("DRI3: malformed or no PCI ID");
-  goto out;
-   }
-
for (i = 0; driver_map[i].driver; i++) {
   if (vendor_id != driver_map[i].vendor_id)
  continue;
@@ -139,8 +157,5 @@ dri3_get_driver_for_fd(int fd)
}
 
 out:
-   udev_device_unref(device);
-   udev_unref(udev);
-
return driver;
 }
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 09/18] dri3: Enable GLX_INTEL_swap_event

2013-12-13 Thread Keith Packard
Now that we're tracking SBC values correctly, and the X server has the ability
to send the GLX swap events from a PresentPixmap request, enable this extension.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index d2b9d0e..ea20138 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1524,23 +1524,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct 
glx_display * priv,
__glXEnableDirectExtension(&psc->base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_SGI_make_current_read");
-
-   /*
-* GLX_INTEL_swap_event is broken on the server side, where it's
-* currently unconditionally enabled. This completely breaks
-* systems running on drivers which don't support that extension.
-* There's no way to test for its presence on this side, so instead
-* of disabling it unconditionally, just disable it for drivers
-* which are known to not support it, or for DDX drivers supporting
-* only an older (pre-ScheduleSwap) version of DRI2.
-*
-* This is a hack which is required until:
-* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
-* is merged and updated xserver makes it's way into distros:
-*/
-//   if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) {
-//  __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
-//   }
+   __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
 
mask = psc->image_driver->getAPIMask(psc->driScreen);
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 13/18] dri3: Flush XCB before blocking for special events

2013-12-13 Thread Keith Packard
XCB doesn't flush the output buffer automatically, so we have to call
xcb_flush ourselves before waiting.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index c26d6e5..7982f6b 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -405,6 +405,7 @@ dri3_wait_for_event(__GLXDRIdrawable *pdraw)
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
 
+   xcb_flush(c);
ev = xcb_wait_for_special_event(c, priv->special_event);
if (!ev)
   return false;
@@ -1074,6 +1075,7 @@ dri3_find_back(xcb_connection_t *c, struct dri3_drawable 
*priv)
  if (!buffer->busy)
 return b;
   }
+  xcb_flush(c);
   ev = xcb_wait_for_special_event(c, priv->special_event);
   if (!ev)
  return -1;
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 06/18] dri3: Clean up struct dri3_drawable

2013-12-13 Thread Keith Packard
Move the depth field up with width and height.

Remove unused previous_time and frames fields.

Signed-off-by: Keith Packard 
Reviewed-by: Kenneth Graunke 
---
 src/glx/dri3_priv.h | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 2990c4f..4adef50 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -177,7 +177,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
 struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
-   int width, height;
+   int width, height, depth;
int swap_interval;
uint8_t have_back;
uint8_t have_fake_front;
@@ -193,13 +193,9 @@ struct dri3_drawable {
/* For WaitMSC */
uint32_t present_msc_request_serial;
uint32_t present_msc_event_serial;
-   
-   uint64_t previous_time;
-   unsigned frames;
 
struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
-   int depth;
 
uint32_t *stamp;
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 11/18] i965: Set fast color clear mcs_state on newly allocated image miptrees

2013-12-13 Thread Keith Packard
Just copying code from the dri2 path to set up the fast color clear state.

This also removes a couple of bogus intel_region_reference calls.

Signed-off-by: Keith Packard 
Reviewed-by: Eric Anholt 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index a96c7ea..de47143 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -771,7 +771,13 @@ intel_miptree_create_for_image_buffer(struct brw_context 
*intel,
if (!singlesample_mt)
   return NULL;
 
-   intel_region_reference(&singlesample_mt->region, region);
+   /* If this miptree is capable of supporting fast color clears, set
+* mcs_state appropriately to ensure that fast clears will occur.
+* Allocation of the MCS miptree will be deferred until the first fast
+* clear actually occurs.
+*/
+   if (intel_is_non_msrt_mcs_buffer_supported(intel, singlesample_mt))
+  singlesample_mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_RESOLVED;
 
if (num_samples == 0)
   return singlesample_mt;
@@ -789,8 +795,6 @@ intel_miptree_create_for_image_buffer(struct brw_context 
*intel,
multisample_mt->singlesample_mt = singlesample_mt;
multisample_mt->need_downsample = false;
 
-   intel_region_reference(&multisample_mt->region, region);
-
if (intel->is_front_buffer_rendering && buffer_type == 
__DRI_IMAGE_BUFFER_FRONT) {
   intel_miptree_upsample(intel, multisample_mt);
}
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 08/18] dri3: Fix dri3_wait_for_sbc to wait for completion of requested SBC

2013-12-13 Thread Keith Packard
Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC
had been completed, which means to wait until the PresentCompleteNotify event
for that SBC had been received.

This replaces the simple sleep(1) loop (which was bogus) with a loop that just
checks to see if we've seen the specified SBC value come back in a
PresentCompleteNotify event yet.

The change is a bit larger than that as I've broken out a piece of common code
to wait for and process a single Present event for the target drawable.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 55 ++
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b9a786f..d2b9d0e 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -397,14 +397,33 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
xcb_present_generic_event_
free(ge);
 }
 
+static bool
+dri3_wait_for_event(__GLXDRIdrawable *pdraw)
+{
+   xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
+   struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+   xcb_generic_event_t *ev;
+   xcb_present_generic_event_t *ge;
+
+   ev = xcb_wait_for_special_event(c, priv->special_event);
+   if (!ev)
+  return false;
+   ge = (void *) ev;
+   dri3_handle_present_event(priv, ge);
+   return true;
+}
+
+/** dri3_wait_for_msc
+ *
+ * Get the X server to send an event when the target msc/divisor/remainder is
+ * reached.
+ */
 static int
 dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
   int64_t remainder, int64_t *ust, int64_t *msc, int64_t *sbc)
 {
xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
-   xcb_generic_event_t *ev;
-   xcb_present_generic_event_t *ge;
uint32_t msc_serial;
 
/* Ask for the an event for the target MSC */
@@ -421,11 +440,8 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
/* Wait for the event */
if (priv->special_event) {
   while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
- ev = xcb_wait_for_special_event(c, priv->special_event);
- if (!ev)
-break;
- ge = (void *) ev;
- dri3_handle_present_event(priv, ge);
+ if (!dri3_wait_for_event(pdraw))
+return 0;
   }
}
 
@@ -436,6 +452,11 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t 
target_msc, int64_t divisor,
return 1;
 }
 
+/** dri3_drawable_get_msc
+ *
+ * Return the current UST/MSC/SBC triplet by asking the server
+ * for an event
+ */
 static int
 dri3_drawable_get_msc(struct glx_screen *psc, __GLXDRIdrawable *pdraw,
   int64_t *ust, int64_t *msc, int64_t *sbc)
@@ -445,12 +466,9 @@ dri3_drawable_get_msc(struct glx_screen *psc, 
__GLXDRIdrawable *pdraw,
 
 /** dri3_wait_for_sbc
  *
- * Wait for the swap buffer count to increase. The only way this
- * can happen is if some other thread is doing swap buffers as
- * we no longer share swap buffer counts with other processes.
- *
- * I'm not sure this is actually useful as such, and so this
- * implementation is a kludge that just polls once a second
+ * Wait for the completed swap buffer count to reach the specified
+ * target. Presumably the application knows that this will be reached with
+ * outstanding complete events, or we're going to be here awhile.
  */
 static int
 dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t target_sbc, int64_t *ust,
@@ -458,10 +476,15 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t 
target_sbc, int64_t *ust,
 {
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
 
-   while (priv->send_sbc < target_sbc) {
-  sleep(1);
+   while (priv->recv_sbc < target_sbc) {
+  if (!dri3_wait_for_event(pdraw))
+ return 0;
}
-   return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
+
+   *ust = priv->ust;
+   *msc = priv->msc;
+   *sbc = priv->recv_sbc;
+   return 1;
 }
 
 /**
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 14/18] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

2013-12-13 Thread Keith Packard
The __DRIimage createImageFromFds function takes a fourcc code, but there was
no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
__DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
__IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.

I'll refrain from comments on whether I think having two separate sets of
format defines in dri_interface.h is a good idea or not...

Signed-off-by: Keith Packard 
Reviewed-by: Eric Anholt 
---
 include/GL/internal/dri_interface.h  | 1 +
 src/glx/dri3_glx.c   | 1 +
 src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
 src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
 4 files changed, 8 insertions(+)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 81f7e60..9e82904 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1041,6 +1041,7 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_FOURCC_XRGB0x34325258
 #define __DRI_IMAGE_FOURCC_ABGR0x34324241
 #define __DRI_IMAGE_FOURCC_XBGR0x34324258
+#define __DRI_IMAGE_FOURCC_SARGB0x83324258
 #define __DRI_IMAGE_FOURCC_YUV410  0x39565559
 #define __DRI_IMAGE_FOURCC_YUV411  0x31315559
 #define __DRI_IMAGE_FOURCC_YUV420  0x32315559
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 7982f6b..ad6de65 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -936,6 +936,7 @@ image_format_to_fourcc(int format)
 
/* Convert from __DRI_IMAGE_FORMAT to __DRI_IMAGE_FOURCC (sigh) */
switch (format) {
+   case __DRI_IMAGE_FORMAT_SARGB8: return __DRI_IMAGE_FOURCC_SARGB;
case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c 
b/src/mesa/drivers/dri/i915/intel_screen.c
index d607f47..d442eab 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/src/mesa/drivers/dri/i915/intel_screen.c
@@ -184,6 +184,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
+   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 4373685..9a5bf5c 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -220,6 +220,9 @@ static struct intel_image_format intel_image_formats[] = {
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
 
+   { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
+ { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
+
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
  { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 17/18] nvc0: fix segfault if nv50_miptree_from_handle() fails

2013-12-13 Thread Keith Packard
From: Ben Skeggs 

Signed-off-by: Ben Skeggs 
Signed-off-by: Keith Packard 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c
index 4e70903..7fbc6e1 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_resource.c
@@ -26,7 +26,8 @@ nvc0_resource_from_handle(struct pipe_screen * screen,
} else {
   struct pipe_resource *res = nv50_miptree_from_handle(screen,
templ, whandle);
-  nv04_resource(res)->vtbl = &nvc0_miptree_vtbl;
+  if (res)
+ nv04_resource(res)->vtbl = &nvc0_miptree_vtbl;
   return res;
}
 }
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 16/18] gallium/dri: fix unsetting of format when encountering depth/stencil

2013-12-13 Thread Keith Packard
From: Ben Skeggs 

Signed-off-by: Ben Skeggs 
Signed-off-by: Keith Packard 
---
 src/gallium/state_trackers/dri/drm/dri2.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 03b93ae..a9d6a10 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -517,6 +517,17 @@ dri_image_allocate_textures(struct dri_context *ctx,
   if (pf == PIPE_FORMAT_NONE)
  continue;
 
+  switch (statts[i]) {
+  case ST_ATTACHMENT_FRONT_LEFT:
+ buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;
+ break;
+  case ST_ATTACHMENT_BACK_LEFT:
+ buffer_mask |= __DRI_IMAGE_BUFFER_BACK;
+ break;
+  default:
+ continue;
+  }
+
   switch (pf) {
   case PIPE_FORMAT_B5G6R5_UNORM:
  image_format = __DRI_IMAGE_FORMAT_RGB565;
@@ -534,17 +545,6 @@ dri_image_allocate_textures(struct dri_context *ctx,
  image_format = __DRI_IMAGE_FORMAT_NONE;
  break;
   }
-
-  switch (statts[i]) {
-  case ST_ATTACHMENT_FRONT_LEFT:
- buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;
- break;
-  case ST_ATTACHMENT_BACK_LEFT:
- buffer_mask |= __DRI_IMAGE_BUFFER_BACK;
- break;
-  default:
- continue;
-  }
}
 
(*sPriv->image.loader->getBuffers) (dPriv,
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 18/18] gallium: Use base.stamp for all drawable invalidation checks.

2013-12-13 Thread Keith Packard
Upper levels of the stack use base.stamp to tell when a drawable needs to be
revalidated, but the dri state tracker was using dPriv->lastStamp. Those two,
along with dri2.stamp, all get simultaneously incremented when a dri2
invalidate event was delivered, and so end up containing precisely the same
value.

This patch doesn't change the fact that there are three variables, rather it
switches all of the tests to use only base.stamp, which is functionally
equivalent to the previous code.

Then, it passes base.stamp to the image loader getBuffers function so that the
one which is checked will get updated by the XCB special event queue used by 
DRI3.

Signed-off-by: Keith Packard 
Reviewed-by: Marek Olšák 
---
 src/gallium/state_trackers/dri/common/dri_drawable.c | 4 ++--
 src/gallium/state_trackers/dri/drm/dri2.c| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c 
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index f255108..734bca2 100644
--- a/src/gallium/state_trackers/dri/common/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
@@ -73,7 +73,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
 * checked.
 */
do {
-  lastStamp = drawable->dPriv->lastStamp;
+  lastStamp = drawable->base.stamp;
   new_stamp = (drawable->texture_stamp != lastStamp);
 
   if (new_stamp || new_mask || screen->broken_invalidate) {
@@ -91,7 +91,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
  drawable->texture_stamp = lastStamp;
  drawable->texture_mask = statt_mask;
   }
-   } while (lastStamp != drawable->dPriv->lastStamp);
+   } while (lastStamp != drawable->base.stamp);
 
if (!out)
   return TRUE;
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index a9d6a10..9bdb775 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -549,7 +549,7 @@ dri_image_allocate_textures(struct dri_context *ctx,
 
(*sPriv->image.loader->getBuffers) (dPriv,
image_format,
-   &dPriv->dri2.stamp,
+   (uint32_t *) &drawable->base.stamp,
dPriv->loaderPrivate,
buffer_mask,
&images);
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 04/18] dri3: Switch to libxshmfence version 1.1

2013-12-13 Thread Keith Packard
libxshmfence v1.0 foolishly used 'int32_t *' for the fence type, which
works when the fence is a linux futex. However, version 1.1
changes the exported datatype to 'struct xshmfence *'

Require libxshmfence version 1.1 and switch the API around.

Signed-off-by: Keith Packard 
---
 configure.ac| 2 +-
 src/glx/dri3_glx.c  | 4 ++--
 src/glx/dri3_priv.h | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1193cff..db0debc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -833,7 +833,7 @@ xyesno)
 dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2 >= 
1.8"
 
 if test x"$enable_dri3" = xyes; then
-dri_modules="$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence"
+dri_modules="$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence >= 
1.1"
 fi
 
 # add xf86vidmode if available
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index b047cc8..1834c6d 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -676,7 +676,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
xcb_connection_t *c = XGetXCBConnection(dpy);
xcb_pixmap_t pixmap;
xcb_sync_fence_t sync_fence;
-   int32_t *shm_fence;
+   struct xshmfence *shm_fence;
int buffer_fd, fence_fd;
int stride;
 
@@ -921,7 +921,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
struct dri3_screen   *psc;
xcb_connection_t *c;
xcb_sync_fence_t sync_fence;
-   int32_t  *shm_fence;
+   struct xshmfence *shm_fence;
int  fence_fd;
__DRIimage   *image_planar;
int  stride, offset;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index c892800..4bffeb7 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -87,7 +87,7 @@ struct dri3_buffer {
 */
 
uint32_t sync_fence; /* XID of X SyncFence object */
-   int32_t  *shm_fence; /* pointer to xshmfence object */
+   struct xshmfence *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
void *driverPrivate;
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 05/18] dri3: Free resources when drawable is destroyed.

2013-12-13 Thread Keith Packard
Always nice to clean up after ourselves.

Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c  | 17 -
 src/glx/dri3_priv.h |  5 -
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 1834c6d..4c0dc29 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -266,13 +266,25 @@ dri3_create_context(struct glx_screen *base,
 }
 
 static void
+dri3_free_render_buffer(struct dri3_drawable *pdraw, struct dri3_buffer 
*buffer);
+
+static void
 dri3_destroy_drawable(__GLXDRIdrawable *base)
 {
struct dri3_screen *psc = (struct dri3_screen *) base->psc;
struct dri3_drawable *pdraw = (struct dri3_drawable *) base;
+   xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
+   int i;
 
(*psc->core->destroyDrawable) (pdraw->driDrawable);
 
+   for (i = 0; i < DRI3_NUM_BUFFERS; i++) {
+  if (pdraw->buffers[i])
+ dri3_free_render_buffer(pdraw, pdraw->buffers[i]);
+   }
+
+   if (pdraw->special_event)
+  xcb_unregister_for_special_event(c, pdraw->special_event);
free(pdraw);
 }
 
@@ -736,6 +748,7 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   fence_fd);
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = true;
buffer->sync_fence = sync_fence;
buffer->shm_fence = shm_fence;
buffer->width = width;
@@ -769,7 +782,8 @@ dri3_free_render_buffer(struct dri3_drawable *pdraw, struct 
dri3_buffer *buffer)
struct dri3_screen   *psc = (struct dri3_screen *) pdraw->base.psc;
xcb_connection_t *c = XGetXCBConnection(pdraw->base.psc->dpy);
 
-   xcb_free_pixmap(c, buffer->pixmap);
+   if (buffer->own_pixmap)
+  xcb_free_pixmap(c, buffer->pixmap);
xcb_sync_destroy_fence(c, buffer->sync_fence);
xshmfence_unmap_shm(buffer->shm_fence);
(*psc->image->destroyImage)(buffer->image);
@@ -987,6 +1001,7 @@ dri3_get_pixmap_buffer(__DRIdrawable *driDrawable,
   goto no_image;
 
buffer->pixmap = pixmap;
+   buffer->own_pixmap = false;
buffer->width = bp_reply->width;
buffer->height = bp_reply->height;
buffer->buffer_type = buffer_type;
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 4bffeb7..2990c4f 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -89,6 +89,7 @@ struct dri3_buffer {
uint32_t sync_fence; /* XID of X SyncFence object */
struct xshmfence *shm_fence; /* pointer to xshmfence object */
GLbooleanbusy;   /* Set on swap, cleared on IdleNotify */
+   GLbooleanown_pixmap; /* We allocated the pixmap ID, free on destroy 
*/
void *driverPrivate;
 
uint32_t size;
@@ -171,6 +172,8 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
   return DRI3_FRONT_ID;
 }
 
+#define DRI3_NUM_BUFFERS(1 + DRI3_MAX_BACK)
+
 struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
@@ -194,7 +197,7 @@ struct dri3_drawable {
uint64_t previous_time;
unsigned frames;
 
-   struct dri3_buffer *buffers[1 + DRI3_MAX_BACK];
+   struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
int depth;
 
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 10/18] i965: Correct check for re-bound buffer in intel_update_image_buffer

2013-12-13 Thread Keith Packard
The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.

Signed-off-by: Keith Packard 
Reviewed-by: Eric Anholt 
---
 src/mesa/drivers/dri/i965/brw_context.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 688091f..78c06fc 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1303,10 +1303,21 @@ intel_update_image_buffer(struct brw_context *intel,
 
unsigned num_samples = rb->Base.Base.NumSamples;
 
-   if (rb->mt &&
-   rb->mt->region &&
-   rb->mt->region == region)
-  return;
+   /* Check and see if we're already bound to the right
+* buffer object
+*/
+   if (num_samples == 0) {
+   if (rb->mt &&
+   rb->mt->region &&
+   rb->mt->region->bo == region->bo)
+  return;
+   } else {
+   if (rb->mt &&
+   rb->mt->singlesample_mt &&
+   rb->mt->singlesample_mt->region &&
+   rb->mt->singlesample_mt->region->bo == region->bo)
+  return;
+   }
 
intel_miptree_release(&rb->mt);
rb->mt = intel_miptree_create_for_image_buffer(intel,
-- 
1.8.4.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 15/18] gallium: Add __DRIimageDriverExtension support to gallium

2013-12-13 Thread Keith Packard
Provide the hook to pull textures out of __DRIimage structures and use them as
renderbuffers.

Signed-off-by: Keith Packard 
---
 src/gallium/state_trackers/dri/drm/dri2.c | 238 +-
 1 file changed, 230 insertions(+), 8 deletions(-)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index 8ff77b3..03b93ae 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -457,6 +457,219 @@ dri2_release_buffer(__DRIscreen *sPriv, __DRIbuffer 
*bPriv)
FREE(buffer);
 }
 
+static void
+dri_image_allocate_textures(struct dri_context *ctx,
+   struct dri_drawable *drawable,
+   const enum st_attachment_type *statts,
+   unsigned statts_count)
+{
+   __DRIdrawable *dPriv = drawable->dPriv;
+   __DRIscreen *sPriv = drawable->sPriv;
+   struct dri_screen *screen = dri_screen(sPriv);
+   unsigned int image_format = __DRI_IMAGE_FORMAT_NONE;
+   uint32_t buffer_mask = 0;
+   struct __DRIimageList images;
+   boolean alloc_depthstencil = FALSE;
+   int i, j;
+   struct pipe_resource templ;
+
+   /* See if we need a depth-stencil buffer. */
+   for (i = 0; i < statts_count; i++) {
+  if (statts[i] == ST_ATTACHMENT_DEPTH_STENCIL) {
+ alloc_depthstencil = TRUE;
+ break;
+  }
+   }
+
+   /* Delete the resources we won't need. */
+   for (i = 0; i < ST_ATTACHMENT_COUNT; i++) {
+  /* Don't delete the depth-stencil buffer, we can reuse it. */
+  if (i == ST_ATTACHMENT_DEPTH_STENCIL && alloc_depthstencil)
+ continue;
+
+  pipe_resource_reference(&drawable->textures[i], NULL);
+   }
+
+   if (drawable->stvis.samples > 1) {
+  for (i = 0; i < ST_ATTACHMENT_COUNT; i++) {
+ boolean del = TRUE;
+
+ /* Don't delete MSAA resources for the attachments which are enabled,
+  * we can reuse them. */
+ for (j = 0; j < statts_count; j++) {
+if (i == statts[j]) {
+   del = FALSE;
+   break;
+}
+ }
+
+ if (del) {
+pipe_resource_reference(&drawable->msaa_textures[i], NULL);
+ }
+  }
+   }
+
+   for (i = 0; i < statts_count; i++) {
+  enum pipe_format pf;
+  unsigned bind;
+
+  dri_drawable_get_format(drawable, statts[i], &pf, &bind);
+  if (pf == PIPE_FORMAT_NONE)
+ continue;
+
+  switch (pf) {
+  case PIPE_FORMAT_B5G6R5_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_RGB565;
+ break;
+  case PIPE_FORMAT_B8G8R8X8_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_XRGB;
+ break;
+  case PIPE_FORMAT_B8G8R8A8_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_ARGB;
+ break;
+  case PIPE_FORMAT_R8G8B8A8_UNORM:
+ image_format = __DRI_IMAGE_FORMAT_ABGR;
+ break;
+  default:
+ image_format = __DRI_IMAGE_FORMAT_NONE;
+ break;
+  }
+
+  switch (statts[i]) {
+  case ST_ATTACHMENT_FRONT_LEFT:
+ buffer_mask |= __DRI_IMAGE_BUFFER_FRONT;
+ break;
+  case ST_ATTACHMENT_BACK_LEFT:
+ buffer_mask |= __DRI_IMAGE_BUFFER_BACK;
+ break;
+  default:
+ continue;
+  }
+   }
+
+   (*sPriv->image.loader->getBuffers) (dPriv,
+   image_format,
+   &dPriv->dri2.stamp,
+   dPriv->loaderPrivate,
+   buffer_mask,
+   &images);
+
+   if (images.image_mask & __DRI_IMAGE_BUFFER_FRONT) {
+  struct pipe_resource *texture = images.front->texture;
+
+  dPriv->w = texture->width0;
+  dPriv->h = texture->height0;
+
+  pipe_resource_reference(&drawable->textures[ST_ATTACHMENT_FRONT_LEFT], 
texture);
+   }
+
+   if (images.image_mask & __DRI_IMAGE_BUFFER_BACK) {
+  struct pipe_resource *texture = images.back->texture;
+
+  dPriv->w = images.back->texture->width0;
+  dPriv->h = images.back->texture->height0;
+
+  pipe_resource_reference(&drawable->textures[ST_ATTACHMENT_BACK_LEFT], 
texture);
+   }
+
+   memset(&templ, 0, sizeof(templ));
+   templ.target = screen->target;
+   templ.last_level = 0;
+   templ.width0 = dPriv->w;
+   templ.height0 = dPriv->h;
+   templ.depth0 = 1;
+   templ.array_size = 1;
+
+   /* Allocate private MSAA colorbuffers. */
+   if (drawable->stvis.samples > 1) {
+  for (i = 0; i < statts_count; i++) {
+ enum st_attachment_type att = statts[i];
+
+ if (att == ST_ATTACHMENT_DEPTH_STENCIL)
+continue;
+
+ if (drawable->textures[att]) {
+templ.format = drawable->textures[att]->format;
+

Re: [Mesa-dev] [PATCH 01/18] Remove glBlendColor and glBlendEquations decls from glext.h

2013-12-13 Thread Keith Packard
Kenneth Graunke  writes:

> NAK.  These headers come directly from Khronos; we need to somehow get
> this fixed upstream and take their version.

Until they're fixed upstream, we should fix them when incorporating them
into the repository. Having broken headers in our code just because
they're broken upstream doesn't make any sense.

I can envision a fairly simple script that would fetch the current
version from khronos, apply a sequence of patches and then commit the
result to the mesa repository.

-- 
keith.pack...@intel.com


pgpFDeBYIjKkD.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 04/18] dri3: Switch to libxshmfence version 1.1

2013-12-13 Thread Keith Packard
Kenneth Graunke  writes:

> Would be great to line these comments up.

Fixed.

> Patches 2 and 4-6 are:
> Reviewed-by: Kenneth Graunke 

Review marked. Thanks much!

-- 
keith.pack...@intel.com


pgpkJlR4qfmew.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 15/18] gallium: Add __DRIimageDriverExtension support to gallium

2013-12-27 Thread Keith Packard
Marek Olšák  writes:

> Some of the code seems to be copy-pasted from
> dri2_drawable_process_buffers. The MSAA color and depth-stencil
> texture allocation could be moved to a common function.

It's either that or plan on moving DRI2 to the image interface as well
at some point? As we'll have to keep DRI2 support around, it sure would
be nice to share the driver backend bits between DRI3 and DRI2?

-- 
keith.pack...@intel.com


pgpD3uan6g8yV.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))

2014-01-12 Thread Keith Packard
the drmServerInfo member, debug_print, takes a printf format string
and varargs list. Tell the compiler about it.

Signed-off-by: Keith Packard 
---
 xf86drm.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xf86drm.h b/xf86drm.h
index 1e763a3..5e170f8 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -92,8 +92,14 @@ extern "C" {
 typedef unsigned int  drmSize, *drmSizePtr;/**< For mapped 
regions */
 typedef void  *drmAddress, **drmAddressPtr; /**< For mapped regions */
 
+#if (__GNUC__ >= 3)
+#define DRM_PRINTFLIKE(f, a) __attribute__ ((format(__printf__, f, a)))
+#else
+#define DRM_PRINTFLIKE(f, a)
+#endif
+
 typedef struct _drmServerInfo {
-  int (*debug_print)(const char *format, va_list ap);
+  int (*debug_print)(const char *format, va_list ap) DRM_PRINTFLIKE(1,0);
   int (*load_module)(const char *name);
   void (*get_perms)(gid_t *, mode_t *);
 } drmServerInfo, *drmServerInfoPtr;
-- 
1.8.5.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))

2014-01-13 Thread Keith Packard
Thierry Reding  writes:

> While at it, perhaps the drmMsg() and drmDebugPrint() functions should
> be similarily annotated as well?

I don't know; I'm just fixing X server warnings this week and this was
the source of one of them. Additional warning fixes for drm would be
a great idea!

-- 
keith.pack...@intel.com


pgp2Mp9hDDHGU.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Mark debug_print with __attribute__ ((format(__printf__, 1, 0)))

2014-01-13 Thread Keith Packard
Ian Romanick  writes:

> Reviewed-by: Ian Romanick 

Thanks. Pushed.
   8279c8f..cb4bc8e  master -> master

-- 
keith.pack...@intel.com


pgpkKf6zSEV5v.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/7] loader: Use dlsym to get our udev symbols instead of explicit linking.

2014-01-26 Thread Keith Packard
Eric Anholt  writes:

> By using a dlopen() with RTLD_LOCAL, we can explicitly look for the
> symbols we want, while they get the symbols they want.

This is way better than the patch I sent that open-coded some of this.

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgp2pcQjAiclo.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/7] dri3: Fix two little memory leaks.

2014-01-26 Thread Keith Packard
Eric Anholt  writes:

> Noticed when valgrinding an unrelated bug.

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgpbTv2iprHuM.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/7] dri2: Open the fd before loading the driver.

2014-01-26 Thread Keith Packard
Eric Anholt  writes:

> I want to stop trusting the server for the driver name, and instead decide
> on our own based on the fd, so I needed this code motion.

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgp0Q34HtVkgL.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 4/7] dri2: Trust our own driver name lookup over the server's.

2014-01-26 Thread Keith Packard
Eric Anholt  writes:

> This allows Mesa to choose to rename driver .sos (or split drivers),
> without needing a flag day with the corresponding 2D driver.

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgpcrXYj0vHR5.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 5/7] dri: Fix the logger error message handling.

2014-01-26 Thread Keith Packard
Eric Anholt  writes:

> Since the loader changes, there has been a compiler warning that the
> prototype didn't match.  It turns out that if a loader error message was
> ever thrown, you'd segfault because of trying to use the warning level as
> a format string.

(Just rebased my dri3+gallium branch and needed this patch to avoid a segfault)

Reviewed-by: Keith Packard 
Tested-by:  Keith Packard 

-- 
keith.pack...@intel.com


pgp7EiKVwTrj4.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 6/7] loader: Fix missing \n on a message string.

2014-01-26 Thread Keith Packard
Eric Anholt  writes:

> ---
>  src/loader/loader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgp69RQVpsMzq.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 7/7] dri: Reuse dri_message to implement our other message handlers.

2014-01-26 Thread Keith Packard
Eric Anholt  writes:

> ---
>  src/glx/dri_common.c | 60 
> 
>  src/glx/dri_common.h |  7 +++---
>  2 files changed, 4 insertions(+), 63 deletions(-)

(I was going to whinge about the lack of PRINTFLIKE in the previous
patch, but then I saw this one)

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgpMV6LIMX4sK.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] XDC2013 - Announcement

2013-06-13 Thread Keith Packard

Now that we have everything in place we can finally make it official
and announce it:

XDC2013 will take place from September 23th to September 25th in
Portland, Oregon at the University Place Hotel and Conference Center
Ian Romanick, Bart Massey, and I will be orgainzing this event.

The initial wiki page for this event has been put in place at:

http://wiki.x.org/wiki/Events/XDC2013

This page will get updated regularly. Also we will keep you up-to-date
on the X.Org events mailing list http://lists.x.org/mailman/listinfo/events
so if you plan to come and are not subscribed there already, please consider
doing so!

For registration please add yourself to the attendees page
http://wiki.x.org/wiki/Events/XDC2013/Attendees.

If you would like to give a talk during the event, please add it to the
program page http://wiki.x.org/wiki/Events/XDC2013/Program.

We are looking forward to seeing you in Portland. So if you are corporate
please talk to your managers about funding your trip. If you aren't but
you have something to present, please contact the XOrg Foundation Board
of Directors at bo...@foundation.x.org for travel funding.

We have negotiated a special conference rate at the conference hotel.
Please check the Wiki page for more information.

-- 
keith.pack...@intel.com


pgpSffKjm5FIz.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] XDC2013 - Call for Proposals

2013-06-13 Thread Keith Packard

# Call For Proposals
**2013 X.Org Developers Conference (XDC 2013)**
**23-25 September 2013**
**Portland, Oregon USA**

The [2013 X.Org Developers Conference]
(http://www.x.org/wiki/Events/XDC2013) is the annual
technical meeting for [X Window System](http://x.org) and
[Free Desktop](http://freedesktop.org) developers. The
attendees will gather to discuss outstanding technical
issues related to X and to plan the direction of the X
Window System and its software ecosystem. The event is free
of charge and open to the general public.

The XDC 2013 Technical Program Committee (TPC) is requesting
proposals for papers and presentations at XDC 2013. While
any serious proposal will be gratefully considered, topics of
interest to X.org and FreeDesktop.org developers are encouraged.
There are three particular types of proposal the TPC is seeking:

 1. Technical talk abstracts: 250-1000 words describing a
 presentation to be made at XDC 2013. This can be
 anything: a work-in-progress talk, a proposal for
 change, analysis of trends, etc.

 2. Informal white papers: 1000+ words on something of
 interest or relevance to X.org developers, FreeDesktop.org
 developers or the X community at large. These papers will
 appear in the online conference proceedings of XDC 2013,
 and are unrefereed (beyond basic checks for legitimacy and
 relevance). Papers can be refereed if requested in advance.

 3. Technical research papers: 2500+ words in a format
 and style suitable for refereed technical publication.
 Papers that are judged acceptable by the TPC and its
 referees will be published in the printed conference
 proceedings of XDC 2013, available on a print-on-demand
 basis online.

XDC 2013 technical presenters will be chosen from the
authors of any of these submissions (as well as other
presenters invited by the TPC).

Normally, there is time for everyone who wants to present to
do so, but one can never tell. As much as possible,
presenters will be selected from those who submit before the
deadline. We also may be able to offer financial assistance
for travel for presenters who could not otherwise afford to
attend and who submit before the deadline.  Please do submit
your proposal in a timely fashion.

**Proposals due:** Thursday 1 August 2013 17:00 UTC
*Accepted formats:  PDF and ASCII text.
**Notification of acceptance:** Thursday 8 August 2013
**E-mail:** bo...@foundation.x.org

-- 
keith.pack...@intel.com


pgpTt_81Ia1JZ.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Delete pre-DRI2.3 viewport hacks.

2013-06-30 Thread Keith Packard
Kenneth Graunke  writes:

> The __DRI_USE_INVALIDATE extension was added in May 11th, 2010 by commit
> 4258e3a2e1c327.  At this point, it's unlikely that anyone's using the
> right mix of new and old components to hit this path.  Deleting it
> removes an untested code path and cleans up the driver a bit.

Thanks for the pointer; I'll definitely keep this patch in mind when I
re-add the viewport stuff to support the X Present extension.

Nice to at least have a reference to the right code ;-)

-- 
keith.pack...@intel.com


pgpqW66r7VhyP.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] dri: Require libudev-dev for building DRI on Linux.

2014-01-31 Thread Keith Packard
Lauri Kasanen  writes:

> Forgot to mention, this would appear to make 3d impossible without udev
> (ie, static devices, mdev, or other solutions).

No, DRI2 continues to fall back to using the driver provided by the X
server if it can't find one locally.

-- 
keith.pack...@intel.com


pgppIx3XzY_42.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] glx/dri3: Fix glXWaitForSbcOML() to handle targetSBC==0 correctly.

2014-12-14 Thread Keith Packard
Mario Kleiner  writes:

> targetSBC == 0 is a special case, which asks the function
> to block until all pending OpenGL bufferswap requests have
> completed.

Well, it blocks until all pending glXSwapBuffersMscOML requests for the
target window have completed. It seems that it's supposed to *not* count
regular glXSwapBuffers calls. We have no way to tell at this level which
function the application called, so I suspect treating them all the same
is about the best we can do...

> This patch fixes the problem.

Yup, looks great to me.

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/3] glx/dri3: Track separate (ust, msc) for PresentPixmap vs. PresentNotifyMsc

2014-12-14 Thread Keith Packard
Mario Kleiner  writes:

> This patch fixes the problem.

Yes, this looks like a good fix, but the names chosen seem very
misleading to me. Given that you're splitting the functionality, using
new names for the two functions will ensure that we carefully review all
current uses of the values and can ensure that we're using the correct
one in all cases. Here's a suggested patch to dri3_priv.h that makes the
names mean something to me at least:

--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -182,12 +182,19 @@ struct dri3_drawable {
uint64_t send_sbc;
uint64_t recv_sbc;
 
-   /* Last received UST/MSC values */
-   uint64_t ust, msc;
+   /* Last received UST/MSC values from
+*  XCB_PRESENT_COMPLETE_KIND_PIXMAP
+*/
+   uint64_t ust_pixmap, msc_pixmap;
+
+   /* Last received UST/MSC values from
+*  XCB_PRESENT_COMPLETE_KIND_NOTIFY_MSC
+*/
+   uint64_t ust_notify_msc, msc_notify_msc;
 
-   /* Serial numbers for tracking wait_for_msc events */
-   uint32_t send_msc_serial;
-   uint32_t recv_msc_serial;
+   /* Serial numbers for tracking present_notify_msc requests/events */
+   uint32_t send_notify_msc_serial;
+   uint32_t recv_notify_msc_serial;
 
struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;

-- 
keith.pack...@intel.com


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.

2014-12-14 Thread Keith Packard
Mario Kleiner  writes:

> Restores proper immediate tearing swap behaviour for
> OpenGL bufferswap under DRI3/Present.

Hrm. I'd love for this to be controlled by the GLX_EXT_swap_control_tear
extension, but that one uses negative interval values to indicate
tearing, instead of providing a new API, and we can't tell the
difference between 0 and -0.

Are you sure you don't want GLX_EXT_swap_control_tear and an interval of
-1 instead of an interval of 0 with tearing?

-- 
keith.pack...@intel.com


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.

2014-12-16 Thread Keith Packard
Mario Kleiner  writes:

> The 0 case is good for benchmarking.

Sure, but the current code does benchmarking just fine. In fact, because
it doesn't copy queued frames that aren't the most recent before the
vblank, benchmarks tend to run *faster* as a result, and people
generally like that aspect of it...

> In my specific case i always want vsync'ed swap for actual visual 
> stimulation in neuroscience/medical settings, with no frame skipped 
> ever. The bonus use for me, except for benchmarking how fast the system 
> can go, is if one has a multi-display setup, e.g., dual-display for 
> stereoscopic stimulation - one display per eye, or some CAVE like setup 
> for VR with more than 2 displays. You want display updates and scanout 
> on all of them synchronized, so the scene stays coherent. One simple way 
> for visually testing multi-display sync is to intentionally swap all of 
> them without vsync, e.g., timed to swap in the middle of the scanout. If 
> the tear-lines on all displays are roughly at the same vertical position 
> and stay there then that's a good visual test if stuff works. There are 
> other ways to do it, but this is the one method that seems to work 
> cross-platform, without lots of mental context switching depending on 
> what os/gpu/server/driver combo with what settings one uses, and much 
> more easy to grasp for scientists with no graphics background. You can 
> see at a glance if stuff is roughly correct or not.

It seems like you want something that the GL API doesn't express
precisely; my reading of the  GL spec definitely lets Present work the
way it does today, and as you avoid tearing *and* improve performance in
the vblank_mode=0 case, I'm very reluctant to change it.

Present could trivially offer a new bit to force tearing; I'm not sure
how you'd get at that from GL though.

-- 
keith.pack...@intel.com


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.

2014-12-16 Thread Keith Packard
Mario Kleiner  writes:

> Hmm. For benchmarking i think i'd consider that a mild form of cheating. 
> You get higher fps because you skip processing like the whole gpu blit 
> overhead and host processing overhead for queuing / validating / 
> processing the copy command in the command stream, so the benchmark 
> numbers don't translate very well anymore in how the system would behave 
> in a non-benchmark situation?

It's still a very useful mode -- imagine wanting the lowest possible
latency between the user and the display; normally, you process input
and generate a frame just after vblank, then (if the rendering is really
quick), end up waiting most of the frame time not doing anything before
finally updating it at the next vblank.

With vblank_mode=0 and DRI3, you have the ability to try and generate
another frame before vblank comes; if you manage, then you get that data
on the screen, rather than the older version.

So, it offers latency closer to the tearing vblank_mode=0 but without
any tearing.

That's why I did it; the fact that it offers a small performance benefit
for benchmarks is an unintentional bonus feature.

-- 
keith.pack...@intel.com


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.

2014-12-16 Thread Keith Packard
Mario Kleiner  writes:

> It's just that i need access to both, the old behaviour i described, and 
> the new "drop frame" behaviour, and i need a way to select what i want 
> at runtime via api without the need for easily overwhelmed and confused 
> users to change config files or environment variables. I also always 
> need meaningful and trustworthy feedback, at least for page-flipped 
> presents, about what really happened for a presented frame - was it 
> flipped, copied, exchanged, skipped, or did some error happen?

Present reports precisely what it did with each frame; flipped, copied,
or skipped.

> That's why i'd like to have an extension to INTEL_swap_events to also 
> report some new completion type "skipped" and "error" and that one patch 
> 5/5 of mine for mesa reviewed and included, to make sure the swap_events 
> don't fall apart so easily.

You can use Present events on the target drawable; they're generated to
whoever requests them, so you don't need to rely on the intel swap
events alone.

> As some kind of stop gap measure one could also think about defining a 
> new vblank_mode to enable the new behaviour instead of the old one.

I really don't have a good suggestion here, given that we have such a
limited API available.

-- 
keith.pack...@intel.com


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] glx/dri3: Provide error diagnostics when DRI3 allocation fails

2014-09-30 Thread Keith Packard
Instead of just segfaulting in the driver when a buffer allocation fails,
report error messages indicating what went wrong so that we can debug things.

As a simple example, chromium wraps Mesa in a sandbox which doesn't allow
access to most syscalls, including the ability to create shared memory
segments for fences. Before, you'd get a simple segfault in mesa and your 3D
acceleration would fail. Now you get:

$ chromium --disable-gpu-blacklist
[10618:10643:0930/200525:ERROR:nss_util.cc(856)] After loading Root Certs, 
loaded==false: NSS error code: -8018
libGL: pci id for fd 12: 8086:0a16, driver i965
libGL: OpenDriver: trying /local-miki/src/mesa/mesa/lib/i965_dri.so
libGL: Can't open configuration file /home/keithp/.drirc: Operation not 
permitted.
libGL: Can't open configuration file /home/keithp/.drirc: Operation not 
permitted.
libGL error: DRI3 Fence object allocation failure Operation not permitted
[10618:10618:0930/200525:ERROR:command_buffer_proxy_impl.cc(153)] Could not 
send GpuCommandBufferMsg_Initialize.
[10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(236)]
 CommandBufferProxy::Initialize failed.
[10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(256)]
 Failed to initialize command buffer.

This made it pretty easy to diagnose the problem in the referenced bug report.

Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681
Signed-off-by: Keith Packard 
---
 src/glx/dri3_glx.c | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 753b8d8..5cae50e 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -816,11 +816,15 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
 */
 
fence_fd = xshmfence_alloc_shm();
-   if (fence_fd < 0)
+   if (fence_fd < 0) {
+  ErrorMessageF("DRI3 Fence object allocation failure %s\n", 
strerror(errno));
   return NULL;
+   }
shm_fence = xshmfence_map_shm(fence_fd);
-   if (shm_fence == NULL)
+   if (shm_fence == NULL) {
+  ErrorMessageF("DRI3 Fence object map failure %s\n", strerror(errno));
   goto no_shm_fence;
+   }
 
/* Allocate the image from the driver
 */
@@ -829,8 +833,10 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   goto no_buffer;
 
buffer->cpp = dri3_cpp_for_format(format);
-   if (!buffer->cpp)
+   if (!buffer->cpp) {
+  ErrorMessageF("DRI3 buffer format %d invalid\n", format);
   goto no_image;
+   }
 
if (!psc->is_different_gpu) {
   buffer->image = (*psc->image->createImage) (psc->driScreen,
@@ -841,8 +847,10 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   buffer);
   pixmap_buffer = buffer->image;
 
-  if (!buffer->image)
+  if (!buffer->image) {
+ ErrorMessageF("DRI3 other gpu image creation failure\n");
  goto no_image;
+  }
} else {
   buffer->image = (*psc->image->createImage) (psc->driScreen,
   width, height,
@@ -850,8 +858,10 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   0,
   buffer);
 
-  if (!buffer->image)
+  if (!buffer->image) {
+ ErrorMessageF("DRI3 gpu image creation failure\n");
  goto no_image;
+  }
 
   buffer->linear_buffer = (*psc->image->createImage) (psc->driScreen,
   width, height,
@@ -861,19 +871,25 @@ dri3_alloc_render_buffer(struct glx_screen *glx_screen, 
Drawable draw,
   buffer);
   pixmap_buffer = buffer->linear_buffer;
 
-  if (!buffer->linear_buffer)
+  if (!buffer->linear_buffer) {
+ ErrorMessageF("DRI3 gpu linear image creation failure\n");
  goto no_linear_buffer;
+  }
}
 
/* X wants the stride, so ask the image for it
 */
-   if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_STRIDE, 
&stride))
+   if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_STRIDE, 
&stride)) {
+  ErrorMessageF("DRI3 get image stride failed\n");
   goto no_buffer_attrib;
+   }
 
buffer->pitch = stride;
 
-   if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_FD, 
&buffer_fd))
+   if (!(*psc->image->queryImage)(pixmap_buffer, __DRI_IMAGE_ATTRIB_FD, 
&buffer_fd)) {
+  ErrorMessageF("DRI3 get image FD failed\n");
   goto no_buffer_attrib;
+   }
 
xcb_dri3_pixmap_from_buffer(c,

Re: [Mesa-dev] [PATCH] glx/dri3: Provide error diagnostics when DRI3 allocation fails

2014-09-30 Thread Keith Packard
Matt Turner  writes:

> Reviewed-by: Matt Turner 
>
> Should we add a Cc: for the stable branch?

Also seems like a good plan. I've added that and pushed.

-- 
keith.pack...@intel.com


pgp3KeIMuqnda.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glx/dri3: Port LIBGL_SHOW_FPS=1 code from DRI2 to DRI3.

2014-10-28 Thread Keith Packard
Kenneth Graunke  writes:

> The code is cut-and-pasted from dri2_glx.c; we can't quite share it
> because we have to use different structures.

It might be fun to use the UST value provided in the
PRESENT_COMPLETE_NOTIFY event instead of a local gettimeofday call? That
way you'd get the presentation time, rather than the time of the swap?

Otherwise, this all seems fine to me

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgpu01DhelnAs.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glx/dri3: Port LIBGL_SHOW_FPS=1 code from DRI2 to DRI3.

2014-10-28 Thread Keith Packard
Kenneth Graunke  writes:

> Is UST expressed in a particular unit?  I thought it was just "monotonically 
> increasing" but otherwise meaningless.  At which point, our FPS would be 
> "frames per...something?" :)

UST in GL's extension is not defined, but Present uses microseconds. As
this is all hidden inside GL, we can depend on that.

-- 
keith.pack...@intel.com


pgpduAWgGW8vs.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glx/dri3: Implement LIBGL_SHOW_FPS=1 for DRI3/Present.

2014-10-29 Thread Keith Packard
Kenneth Graunke  writes:

> v2: Use the UST value provided in the PRESENT_COMPLETE_NOTIFY event
> rather than gettimeofday(), which gives us the presentation time
> instead of the time when SwapBuffers was called.  Suggested by
> Keith Packard.  This relies on the fact that the X Present
> implementation uses microseconds for UST.
>
> Signed-off-by: Kenneth Graunke 
> Cc: Keith Packard 
> Cc: Marek Olšák 
> ---
>  src/glx/dri3_glx.c  | 33 -
>  src/glx/dri3_priv.h |  6 +-
>  2 files changed, 37 insertions(+), 2 deletions(-)
>
> Is this what you had in mind, Keith?  It seems to work fine as well,
> and as long as we can rely on UST being in microseconds, it definitely
> seems nicer.

Present doesn't actually define UST at this point, but I think we can
just fix that; it seems useless to *not* define it, and microseconds
seems like a fine resolution for this clock. Certainly anything using
DRI3 will use microseconds as that's the kind of time stamps it uses.

> diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
> index e8e5c4a..ff9c2f3 100644
> --- a/src/glx/dri3_glx.c
> +++ b/src/glx/dri3_glx.c
> @@ -361,12 +361,34 @@ dri3_create_drawable(struct glx_screen *base, XID 
> xDrawable,
> return &pdraw->base;
>  }
>  
> +static void
> +show_fps(struct dri3_drawable *draw)
> +{
> +   const int interval =
> +  ((struct dri3_screen *) draw->base.psc)->show_fps_interval;
> +
> +   draw->frames++;
> +
> +   /* The Present extension uses microseconds for UST. */
> +   if (draw->previous_ust + interval * 100 <= draw->ust) {

Might want a cast here before the multiply, otherwise that gets done
with only 32 bits. It probably doesn't matter because interval is likely
to be small.

> +  if (draw->previous_ust) {
> + fprintf(stderr, "libGL: FPS = %.1f\n",
> + ((uint64_t)draw->frames * 100) /
> + (double)(draw->ust - draw->previous_ust));
> +  }
> +  draw->frames = 0;
> +  draw->previous_ust = draw->ust;
> +   }
> +}
> +
>  /*
>   * Process one Present event
>   */
>  static void
>  dri3_handle_present_event(struct dri3_drawable *priv, 
> xcb_present_generic_event_t *ge)
>  {
> +   struct dri3_screen *psc = (struct dri3_screen *) priv->base.psc;
> +
> switch (ge->evtype) {
> case XCB_PRESENT_CONFIGURE_NOTIFY: {
>xcb_present_configure_notify_event_t *ce = (void *) ge;
> @@ -400,6 +422,10 @@ dri3_handle_present_event(struct dri3_drawable *priv, 
> xcb_present_generic_event_
>}
>priv->ust = ce->ust;
>priv->msc = ce->msc;
> +
> +  if (psc->show_fps_interval) {
> + show_fps(priv);
> +  }

This actually needs to be inside the COMPLETE_KIND_PIXMAP; this same
event is delivered when the application gets the current MSC, and you
don't want to count those.

-- 
keith.pack...@intel.com


pgpvBPF1D0o1I.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glx/dri3: Implement LIBGL_SHOW_FPS=1 for DRI3/Present.

2014-10-29 Thread Keith Packard
Kenneth Graunke  writes:

> v2: Use the UST value provided in the PRESENT_COMPLETE_NOTIFY event
> rather than gettimeofday(), which gives us the presentation time
> instead of the time when SwapBuffers was called.  Suggested by
> Keith Packard.  This relies on the fact that the X DRI3/Present
> implementations use microseconds for UST.
>
> v3: Properly ignore PresentCompleteKindMSCNotify; multiply in 64 bits
> (caught by Keith Packard).

Reviewed-by: Keith Packard 

-- 
keith.pack...@intel.com


pgptgjeecaS60.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gallivm: Fix build against LLVM SVN >= r302589

2017-08-01 Thread Keith Packard
Michel Dänzer  writes:

> +#if HAVE_LLVM >= 0x0500
> +  virtual void deregisterEHFrames() {
> + mgr()->deregisterEHFrames();
> +  }
> +#elif HAVE_LLVM >= 0x0304
> +  virtual void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, 
> size_t Size) {
> + mgr()->deregisterEHFrames(Addr, LoadAddr, Size);
> +  }
> +#endif

I've got llvm 5.0.0 and it doesn't have this API change. Should that
be > instead of >=?

-- 
-keith


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/3] radv: Add VK_EXT_acquire_xlib_display

2017-08-02 Thread Keith Packard
This uses X leases to provide the same API as nVidia, allowing an
application to discover available display resources and acquire one from
the X server using RandR leases.

Signed-off-by: Keith Packard 
---
 configure.ac   |  11 +
 src/amd/vulkan/Makefile.am |   8 +
 src/amd/vulkan/radv_device.c   |   6 +
 src/amd/vulkan/radv_entrypoints_gen.py |   3 +-
 src/amd/vulkan/radv_wsi_display.c  |  31 +++
 src/vulkan/Makefile.am |   8 +
 src/vulkan/wsi/wsi_common_display.c| 375 +++--
 src/vulkan/wsi/wsi_common_display.h|  16 ++
 8 files changed, 444 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index d95b915b984..b4a17bc9c67 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1412,6 +1412,10 @@ fi
 AC_SUBST([GL_LIB])
 AC_SUBST([OSMESA_LIB])
 
+# Check for RandR leases
+PKG_CHECK_MODULES([RANDRPROTO], [randrproto >= 1.6.0],
+  [have_xlease=yes], [have_xlease=no])
+
 # Check for libdrm
 PKG_CHECK_MODULES([LIBDRM], [libdrm >= $LIBDRM_REQUIRED],
   [have_libdrm=yes], [have_libdrm=no])
@@ -1451,6 +1455,7 @@ AM_CONDITIONAL(HAVE_APPLEDRI, test "x$enable_dri" = xyes 
-a "x$dri_platform" = x
 AM_CONDITIONAL(HAVE_LMSENSORS, test "x$enable_lmsensors" = xyes )
 AM_CONDITIONAL(HAVE_GALLIUM_EXTRA_HUD, test "x$enable_gallium_extra_hud" = 
xyes )
 AM_CONDITIONAL(HAVE_WINDOWSDRI, test "x$enable_dri" = xyes -a "x$dri_platform" 
= xwindows )
+AM_CONDITIONAL(HAVE_XLEASE, test "x$have_xlease" = xyes )
 
 AC_ARG_ENABLE([shared-glapi],
 [AS_HELP_STRING([--enable-shared-glapi],
@@ -1749,6 +1754,12 @@ if test x"$enable_dri3" = xyes; then
 PKG_CHECK_MODULES([XCB_DRI3], [$dri3_modules])
 fi
 
+if test x"$have_xlease" = xyes; then
+DEFINES="$DEFINES -DHAVE_XLEASE"
+randr_modules="x11-xcb xcb-randr"
+PKG_CHECK_MODULES([XCB_RANDR], [$randr_modules])
+fi
+
 AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
 AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
 AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 3a6ada825b5..5a3c714cc03 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -84,6 +84,14 @@ AM_CPPFLAGS += \
 
 VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
 
+if HAVE_PLATFORM_X11
+if HAVE_XLEASE
+AM_CPPFLAGS += \
+   $(XCB_RANDR_CFLAGS)
+VULKAN_LIB_DEPS += $(XCB_RANDR_LIBS)
+endif
+endif
+
 endif
 
 if HAVE_PLATFORM_X11
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index da8e7a89f66..db68b0724fd 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -123,6 +123,12 @@ static const VkExtensionProperties instance_extensions[] = 
{
 .specVersion = 1,
 },
 #endif
+#ifdef VK_USE_PLATFORM_XLIB_XRANDR_EXT
+{
+.extensionName = VK_EXT_ACQUIRE_XLIB_DISPLAY_EXTENSION_NAME,
+.specVersion = 1,
+},
+#endif
 };
 
 static const VkExtensionProperties common_device_extensions[] = {
diff --git a/src/amd/vulkan/radv_entrypoints_gen.py 
b/src/amd/vulkan/radv_entrypoints_gen.py
index 48125da2e76..2a151cc701c 100644
--- a/src/amd/vulkan/radv_entrypoints_gen.py
+++ b/src/amd/vulkan/radv_entrypoints_gen.py
@@ -59,7 +59,8 @@ SUPPORTED_EXTENSIONS = [
 'VK_KHR_external_semaphore_fd',
 'VK_KEITHP_kms_display',
 'VK_KHR_display',
-'VK_EXT_direct_mode_display'
+'VK_EXT_direct_mode_display',
+'VK_EXT_acquire_xlib_display'
 ]
 
 # We generate a static hash table for entry point lookup
diff --git a/src/amd/vulkan/radv_wsi_display.c 
b/src/amd/vulkan/radv_wsi_display.c
index 26fb4bee803..0c9cf7e3315 100644
--- a/src/amd/vulkan/radv_wsi_display.c
+++ b/src/amd/vulkan/radv_wsi_display.c
@@ -137,6 +137,37 @@ radv_ReleaseDisplayEXT(VkPhysicalDevice physical_device,
   display);
 }
 
+#ifdef VK_USE_PLATFORM_XLIB_XRANDR_EXT
+VkResult
+radv_AcquireXlibDisplayEXT(VkPhysicalDevice physical_device,
+   Display  *dpy,
+   VkDisplayKHR display)
+{
+   RADV_FROM_HANDLE(radv_physical_device, pdevice, physical_device);
+
+   return wsi_acquire_xlib_display(physical_device,
+   &pdevice->wsi_device,
+   dpy,
+   display);
+}
+
+VkResult
+radv_GetRandROutputDisplayEXT(VkPhysicalDevice  physical_device,
+  Display   *dpy,
+  RROutput  output,
+  VkDisplayKHR  *dis

[Mesa-dev] [PATCH 3/3] radv: add VK_EXT_display_control to radv

2017-08-02 Thread Keith Packard
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_device.c   |  22 ++-
 src/amd/vulkan/radv_entrypoints_gen.py |   3 +-
 src/amd/vulkan/radv_private.h  |  11 +-
 src/amd/vulkan/radv_wsi_display.c  | 108 +++
 src/vulkan/wsi/wsi_common.h|   9 ++
 src/vulkan/wsi/wsi_common_display.c| 240 +
 src/vulkan/wsi/wsi_common_display.h|  28 
 7 files changed, 417 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index db68b0724fd..6531b5afb3a 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -198,6 +198,10 @@ static const VkExtensionProperties 
ext_sema_device_extensions[] = {
.extensionName = VK_KHR_EXTERNAL_SEMAPHORE_FD_EXTENSION_NAME,
.specVersion = 1,
},
+{
+.extensionName = VK_EXT_DISPLAY_CONTROL_EXTENSION_NAME,
+.specVersion = 1,
+},
 };
 
 static VkResult
@@ -2729,7 +2733,14 @@ void radv_DestroyFence(
 
if (!fence)
return;
-   device->ws->destroy_fence(fence->fence);
+switch (fence->type) {
+case RADV_FENCE_TYPE_WINSYS:
+   device->ws->destroy_fence(fence->fence);
+   break;
+case RADV_FENCE_TYPE_WSI:
+   fence->fence_wsi->destroy(fence->fence_wsi);
+   break;
+}
vk_free2(&device->alloc, pAllocator, fence);
 }
 
@@ -2770,7 +2781,14 @@ VkResult radv_WaitForFences(
if (!fence->submitted)
return VK_TIMEOUT;
 
-   expired = device->ws->fence_wait(device->ws, fence->fence, 
true, timeout);
+switch (fence->type) {
+case RADV_FENCE_TYPE_WINSYS:
+   expired = device->ws->fence_wait(device->ws, fence->fence, 
true, timeout);
+   break;
+case RADV_FENCE_TYPE_WSI:
+   expired = fence->fence_wsi->wait(fence->fence_wsi, true, 
timeout);
+   break;
+}
if (!expired)
return VK_TIMEOUT;
 
diff --git a/src/amd/vulkan/radv_entrypoints_gen.py 
b/src/amd/vulkan/radv_entrypoints_gen.py
index 2a151cc701c..3007d517a95 100644
--- a/src/amd/vulkan/radv_entrypoints_gen.py
+++ b/src/amd/vulkan/radv_entrypoints_gen.py
@@ -60,7 +60,8 @@ SUPPORTED_EXTENSIONS = [
 'VK_KEITHP_kms_display',
 'VK_KHR_display',
 'VK_EXT_direct_mode_display',
-'VK_EXT_acquire_xlib_display'
+'VK_EXT_acquire_xlib_display',
+'VK_EXT_display_control'
 ]
 
 # We generate a static hash table for entry point lookup
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 27e1e6d6ed7..146ffcc4e65 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1519,8 +1519,17 @@ void radv_initialise_cmask(struct radv_cmd_buffer 
*cmd_buffer,
 void radv_initialize_dcc(struct radv_cmd_buffer *cmd_buffer,
 struct radv_image *image, uint32_t value);
 
+enum radv_fence_type {
+RADV_FENCE_TYPE_WINSYS = 0,
+RADV_FENCE_TYPE_WSI = 1
+};
+
 struct radv_fence {
-   struct radeon_winsys_fence *fence;
+enum radv_fence_type type;
+union {
+struct radeon_winsys_fence  *fence;
+struct wsi_fence*fence_wsi;
+};
bool submitted;
bool signalled;
 };
diff --git a/src/amd/vulkan/radv_wsi_display.c 
b/src/amd/vulkan/radv_wsi_display.c
index 0c9cf7e3315..7729ac621e2 100644
--- a/src/amd/vulkan/radv_wsi_display.c
+++ b/src/amd/vulkan/radv_wsi_display.c
@@ -184,3 +184,111 @@ radv_CreateDisplayPlaneSurfaceKHR(VkInstance  
  _instanc
 
return wsi_create_display_surface(_instance, alloc, create_info, surface);
 }
+
+/* VK_EXT_display_control */
+
+VkResult
+radv_DisplayPowerControlEXT(VkDevice_device,
+VkDisplayKHRdisplay,
+const VkDisplayPowerInfoEXT *display_power_info)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+
+   return wsi_display_power_control(_device,
+&device->physical_device->wsi_device,
+display,
+display_power_info);
+}
+
+VkResult
+radv_RegisterDeviceEventEXT(VkDevice_device,
+const VkDeviceEventInfoEXT  *device_event_info,
+const VkAllocationCallbacks *allocator,
+ 

[Mesa-dev] [PATCH 1/3] radv: Add VK_KHR_display, VK_KEITHP_kms_display and VK_EXT_direct_mode_display [v2]

2017-08-02 Thread Keith Packard
Implements VK_KHR_display and VK_EXT_direct_mode_display using
DRM/KMS.

Expose ability to get to that using VK_KEITHP_kms_display, which
allows the application to provide a master fd to the library which it
uses instead of opening its own.

Signed-off-by: Keith Packard 
---
 configure.ac  |3 +-
 include/vulkan/vulkan.h   |1 +
 include/vulkan/vulkan_keithp.h|   40 +
 src/Makefile.am   |7 +
 src/amd/vulkan/Makefile.am|   10 +
 src/amd/vulkan/Makefile.sources   |3 +
 src/amd/vulkan/radv_device.c  |   73 +-
 src/amd/vulkan/radv_entrypoints_gen.py|3 +
 src/amd/vulkan/radv_private.h |7 +
 src/amd/vulkan/radv_radeon_winsys.h   |4 +
 src/amd/vulkan/radv_wsi.c |   37 +-
 src/amd/vulkan/radv_wsi_display.c |  155 +++
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c |   18 +
 src/intel/vulkan/anv_wsi.c|2 +-
 src/vulkan/Makefile.am|7 +
 src/vulkan/Makefile.sources   |4 +
 src/vulkan/registry/vk.xml|   18 +
 src/vulkan/wsi/wsi_common.h   |   12 +-
 src/vulkan/wsi/wsi_common_display.c   | 1255 +
 src/vulkan/wsi/wsi_common_display.h   |   77 ++
 src/vulkan/wsi/wsi_common_wayland.c   |2 +-
 src/vulkan/wsi/wsi_common_x11.c   |4 +-
 22 files changed, 1728 insertions(+), 14 deletions(-)
 create mode 100644 include/vulkan/vulkan_keithp.h
 create mode 100644 src/amd/vulkan/radv_wsi_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.h

diff --git a/configure.ac b/configure.ac
index 6302aa2b0c8..d95b915b984 100644
--- a/configure.ac
+++ b/configure.ac
@@ -74,7 +74,7 @@ AC_SUBST([OPENCL_VERSION])
 # in the first entry.
 LIBDRM_REQUIRED=2.4.75
 LIBDRM_RADEON_REQUIRED=2.4.71
-LIBDRM_AMDGPU_REQUIRED=2.4.82
+LIBDRM_AMDGPU_REQUIRED=2.4.83
 LIBDRM_INTEL_REQUIRED=2.4.75
 LIBDRM_NVVIEUX_REQUIRED=2.4.66
 LIBDRM_NOUVEAU_REQUIRED=2.4.66
@@ -1752,6 +1752,7 @@ fi
 AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
 AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
 AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
+AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo "$platforms" | grep -q 'drm')
 AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
'surfaceless')
 AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
 
diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
index 16434fefbe6..943ff7c82b5 100644
--- a/include/vulkan/vulkan.h
+++ b/include/vulkan/vulkan.h
@@ -214,6 +214,7 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_MIR_SURFACE_CREATE_INFO_KHR = 107000,
 VK_STRUCTURE_TYPE_ANDROID_SURFACE_CREATE_INFO_KHR = 108000,
 VK_STRUCTURE_TYPE_WIN32_SURFACE_CREATE_INFO_KHR = 109000,
+VK_STRUCTURE_TYPE_KMS_DISPLAY_INFO_KEITHP = 11,
 VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT = 111000,
 VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_RASTERIZATION_ORDER_AMD = 
118000,
 VK_STRUCTURE_TYPE_DEBUG_MARKER_OBJECT_NAME_INFO_EXT = 122000,
diff --git a/include/vulkan/vulkan_keithp.h b/include/vulkan/vulkan_keithp.h
new file mode 100644
index 0000000..acf59fa4e13
--- /dev/null
+++ b/include/vulkan/vulkan_keithp.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright © 2017 Keith Packard 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef _VULKAN_KEITHP_H_
+#define _VULKAN_KEITHP_H_
+
+#include "vulkan.h"
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C"
+{
+#endif /* __cplusplus */
+
+typedef struct VkKmsDisplayInfoKEITHP {
+   VkStructureType sType;  /* 
VK_STRUCTURE_TYPE_KMS_DISPLAY_INFO_KEITHP */
+   const void* pNext;
+   int fd;
+} VkKmsDisplayInfoKEITHP;
+
+#define VK_KEITHP_KMS_DISPLAY_SPEC_VERSION  1
+#define VK_KEITHP_KMS_DISPLAY_EXTENSION_NAME"VK_KEITHP_kms_display"
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* _VULKAN_KEITHP_H_ */
diff --git a/src/Makefile.am b/src/Makefile.am
index 5aee6b01417..1a0f32c9

[Mesa-dev] [PATCH 0/3] radv: Add leasing support

2017-08-02 Thread Keith Packard
I've split this into three patches to make review at least a little
easier.

The first provides the KHR_display extension using the new
KEITHP_kms_display extension that allows you to pass in a DRM master
to vkCreateInstance.

The second provides EXT_acquire_xlib_display, which is an API that
nVidia provides. This hides all of the actual lease creation down
inside the Vulkan driver instead of in the application.

The third provides EXT_display_control, which exposes vblank fences
and frame counts for raw display devices. It also adds DPMS control
and hotplug notification (this one I haven't bothered to hook up).

-keith

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] radv: Add VK_KHR_display, VK_KEITHP_kms_display and VK_EXT_direct_mode_display [v2]

2017-08-02 Thread Keith Packard
Emil Velikov  writes:

> Is the VK_KEITHP_kms_display spec available somewhere?

I haven't written one yet. I'll go draft one.

> Since there are multiple companies [participating in Mesa] with
> Khronos membership, could we make this an EXT extension? Once
> everything else is settled in, of course.

I'm easy; I didn't want to step on any namespace toes, so I picked
something else. Can I just assert EXT for the name and be ok?

> I think it makes sense to spit the VK_KHR_display +
> VK_EXT_direct_mode_display bits from the patch. AFAICT they're used by
> 2/3 and 3/3 which are already well defined extensions.

You can't use VK_KHR_display+VK_EXT_direct_mode_display without one of
VK_KEITHP_kms_display or VK_EXT_acquire_xlib_display as the latter two
extensions are how you actually get a VkDisplayKHR device, so I'm not
sure it would be useful to split those apart?

> This way we could land them, while the new extension [and kernel bits]
> are being refined.

VK_KEITHP_kms_display doesn't depend on the kernel bits; it just
requires that the application open the kernel
device. VK_EXT_acquire_xlib_display does depend on the kernel changes,
but only through the X extension which is where the 'lease'
originates. So, that's a pretty long dependency chain.

I should reconstruct my kms_display demo so that it doesn't use a lease;
right now, the application does all of the X stuff itself to create a
leased DRM master, but it could just open /dev/dri/card0. That would
provide a simple test case for the first patch which was independent of
the X server and kernel.

-- 
-keith


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] radv: Add VK_KHR_display, VK_KEITHP_kms_display and VK_EXT_direct_mode_display [v2]

2017-08-02 Thread Keith Packard
Emil Velikov  writes:

> Is the VK_KEITHP_kms_display spec available somewhere?

Here's a rough version:

VK_KEITHP_kms_display
=

**Name String**
VK_KEITHP_kms_display

**Extension Type**
Instance Extension

**Registered Extension Number**
TBD

**Status**
Draft.

**Last Modified Date**
2017-08-02

**Revision**
1

**IP Status**
No known IP claims.

**Dependencies**
This extension is written against version 1.0 of the Vulkan
API.

Requires VK_KHR_display

**Contributors**
    Keith Packard, keithp.com

Dave Airlie, Redhat

Pierre-Loup Griffais, Valve

**Contacts**
    Keith Packard (keithp 'at' keithp.com)

This extension provides the VkKmsDisplayInfoKEITHP struct that can be
included in the pNext chain at vkCreateInstance time. The new struct
contains a file descriptor that the Vulkan driver uses in place of the
one it would normal open to communicate with the underlying hardware.
The provided file descriptor must support rendering commands. If it
also supports display configuration, then the KHR_display extension
can be used for that.

New Enum Constants
--

 * Extending VkStructureType:

   - VK_STRUCTURE_TYPE_KMS_DISPLAY_INFO_KEITHP

New Structures
--

 * VkKmsDisplayInfoKEITHP


.. compound::

The VkKmsDisplayInfoKEITHP structure is defined as::

typedef struct VkKmsDisplayInfoKEITHP {
VkStructureType sType;
const void* pNext;
int fd;
} VkKmsDisplayInfoKEITHP;

..

* sType is the type of this structure and must be 
VK_STRUCTURE_TYPE_KMS_DISPLAY_INFO_KEITHP
* pNext is NULL or a pointer to another structure in the pCreateInfo
  chain passed to vkCreateInstance.
* fd is the file descriptor for the target graphics device.


-- 
-keith


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH mesa 2/3] radv: Add VK_EXT_display_surface_counter [v2]

2017-12-21 Thread Keith Packard
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.

v2: Thanks to kisak

Fix spelling of VkSurfaceCapabilities2EXT in wsi_common_wayland.c,
it was using ext instead of EXT.

Fix spelling of VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT
---
 src/amd/vulkan/radv_extensions.py   |  1 +
 src/amd/vulkan/radv_wsi.c   | 12 
 src/vulkan/wsi/wsi_common.c | 11 +++
 src/vulkan/wsi/wsi_common.h |  5 +
 src/vulkan/wsi/wsi_common_display.c | 27 +++
 src/vulkan/wsi/wsi_common_private.h |  2 ++
 src/vulkan/wsi/wsi_common_wayland.c | 27 +++
 src/vulkan/wsi/wsi_common_x11.c | 27 +++
 8 files changed, 112 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index fc27ff8734c..8afba9d9057 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -83,6 +83,7 @@ EXTENSIONS = [
 Extension('VK_KHR_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
+Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, True),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_global_priority',   1, 
'device->rad_info.has_ctx_priority'),
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 5ec872a63d0..2d2a30ebbb1 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -103,6 +103,18 @@ VkResult radv_GetPhysicalDeviceSurfaceCapabilities2KHR(
pSurfaceCapabilities);
 }
 
+VkResult radv_GetPhysicalDeviceSurfaceCapabilities2EXT(
+   VkPhysicalDevicephysicalDevice,
+   VkSurfaceKHRsurface,
+   VkSurfaceCapabilities2EXT*  pSurfaceCapabilities)
+{
+   RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_surface_capabilities2ext(&device->wsi_device,
+   surface,
+   pSurfaceCapabilities);
+}
+
 VkResult radv_GetPhysicalDeviceSurfaceFormatsKHR(
VkPhysicalDevicephysicalDevice,
VkSurfaceKHRsurface,
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 99f4c607666..672b0c50ec0 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -576,6 +576,17 @@ wsi_common_get_surface_capabilities2(struct wsi_device 
*wsi_device,
pSurfaceCapabilities);
 }
 
+VkResult
+wsi_common_get_surface_capabilities2ext(struct wsi_device *wsi_device,
+VkSurfaceKHR _surface,
+VkSurfaceCapabilities2EXT 
*pSurfaceCapabilities)
+{
+   ICD_FROM_HANDLE(VkIcdSurfaceBase, surface, _surface);
+   struct wsi_interface *iface = wsi_device->wsi[surface->platform];
+
+   return iface->get_capabilities2ext(surface, pSurfaceCapabilities);
+}
+
 VkResult
 wsi_common_get_surface_formats(struct wsi_device *wsi_device,
VkSurfaceKHR _surface,
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 1cb6aaebca0..124d096170a 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -155,6 +155,11 @@ wsi_common_get_surface_present_modes(struct wsi_device 
*wsi_device,
  uint32_t *pPresentModeCount,
  VkPresentModeKHR *pPresentModes);
 
+VkResult
+wsi_common_get_surface_capabilities2ext(struct wsi_device *wsi_device,
+VkSurfaceKHR surface,
+VkSurfaceCapabilities2EXT 
*pSurfaceCapabilities);
+
 VkResult
 wsi_common_get_images(VkSwapchainKHR _swapchain,
   uint32_t *pSwapchainImageCount,
diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index 05b019cf957..bf13a359ac7 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -1145,6 +1145,32 @@ wsi_display_surface_get_capabilities2(VkIcdSurfaceBase 
*icd_surface,
return wsi_display_surface_get_capabilities(icd_surface, 
&caps->surfaceCapabilities);
 }
 
+static VkResult
+wsi_display_surface_get_capabilities_2ext(VkIcdSurfaceBase *icd_surface,
+  VkSurfaceCapabilities2EXT *caps)
+{
+   VkSurfaceCapa

  1   2   3   >