Re: [PATCH] i915: Drop legacy execbuffer support

[Keith Packard]

Jason Ekstrand  writes:

> libdrm has supported the newer execbuffer2 ioctl and using it by default
> when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
> which landed Mar 2, 2010.  The i915 and i965 drivers in Mesa at the time
> both used libdrm and so did the Intel X11 back-end.  The SNA back-end
> for X11 has always used execbuffer2.

All execbuffer users in the past that I'm aware of used libdrm, which
now uses the execbuffer2 ioctl for this API. That means these
applications will remain ABI compatible through this change.

Acked-by: Keith Packard 

-- 
-keith


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

[PATCH] vulkan: Add VK_GOOGLE_display_timing extension (x11+display, anv+radv) [v8]

[Keith Packard]

This adds support for the VK_GOOGLE_display timing extension, which
provides two things:

 1) Detailed information about when frames are displayed, including
slack time between GPU execution and display frame.

 2) Absolute time control over swapchain queue processing. This allows
the application to request frames be displayed at specific
absolute times, using the same timebase as that provided in vblank
events.

Support for this extension has been implemented for the x11 and
display backends; adding support to other backends should be
reasonable straightforward for one familiar with those systems and
should not require any additional device-specific code.

v2:
Adjust GOOGLE_display_timing earliest value.  The
earliestPresentTime for an image cannot be before the previous
image was displayed, or even a frame later (in FIFO mode).

Make GOOGLE_display_timing use render completed time.  Switch
from VK_PIPELINE_TOP_OF_PIPE_BIT to
VK_PIPELINE_STAGE_ALL_COMMANDS_BIT so that the time reported
to applications as the end of rendering reflects the latest
possible value to ensure that applications don't underestimate
the amount of work done in the frame.

v3:
Adopt Jason Ekstrand's coding conventions.  Declare variables
at first use, eliminate extra whitespace between types and
names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

v4:
Adapt to changes in MESA_query_timestamp extension

v5:
Squash core bits and anv/radv wrappers into a single patch

Suggested-by: Jason Ekstrand 

v6:
Switch from MESA_query_timestamp to EXT_calibrated_timestamps

v7:
Ensure we target frame no earlier than desired. This means
rounding the target frame up, rather than selecting the
nearest one.

Suggested-by: Michel Dänzer 

v8:
Re-order display_timing in anv_extensions.py. That code
now requires extensions in alphabetical order.

Rename wsi_mark_time to wsi_present_complete to make
the functionality clearer.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py   |   1 +
 src/amd/vulkan/radv_wsi.c   |  33 +++
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_wsi.c  |  31 +++
 src/vulkan/wsi/wsi_common.c | 301 +++-
 src/vulkan/wsi/wsi_common.h |  32 +++
 src/vulkan/wsi/wsi_common_display.c | 163 ++-
 src/vulkan/wsi/wsi_common_private.h |  35 
 src/vulkan/wsi/wsi_common_x11.c |  71 ++-
 9 files changed, 656 insertions(+), 12 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 57aa67be616..c255b49437a 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -166,6 +166,7 @@ EXTENSIONS = [
 Extension('VK_AMD_shader_trinary_minmax', 1, True),
 Extension('VK_GOOGLE_decorate_string',1, True),
 Extension('VK_GOOGLE_hlsl_functionality1',1, True),
+Extension('VK_GOOGLE_display_timing', 1, True),
 Extension('VK_NV_compute_shader_derivatives', 1, 
'device->rad_info.chip_class >= GFX8'),
 ]
 
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index a2b0afa48c3..b722e23ff53 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -316,3 +316,36 @@ VkResult radv_GetPhysicalDevicePresentRectanglesKHR(
 surface,
 pRectCount, pRects);
 }
+
+/* VK_GOOGLE_display_timing */
+VkResult
+radv_GetRefreshCycleDurationGOOGLE(
+   VkDevice _device,
+   VkSwapchainKHR swapchain,
+   VkRefreshCycleDurationGOOGLE *pDisplayTimingProperties)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_refresh_cycle_duration(>wsi_device,
+_device,
+swapchain,
+pDisplayTimingProperties);
+}
+
+VkResult
+radv_GetPastPresentationTimingGOOGLE(VkDevice _device,
+VkSwapchainKHR swapchain,
+uint32_t *pPresentationTimingCount,
+VkPastPresentationTimingGOOGLE
+*pPresentationTimings)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_past_presentation_timing(>wsi_device,
+  _device,
+ 

Re: liboutput: thoughts about shared library on top of DRM/KMS

[Keith Packard]

Neil Armstrong  writes:

> Seeing the description, it seems to be a libdrm with steroids,
> why libdrm doesn't handle all this already ?

That'd be a lot of steroids; we're talking about creating helper
functions all the way up to rendering images into scanout buffers
(presumably using Vulkan?) for format conversion or flattening.

> Is there a plan to maybe use it as a foundation for projects like
> wlroots or drm_hwcomposer for example ?

Yes, the goal is to start to share code across a wide range of DRM
users, instead of having everyone roll their own.

-- 
-keith


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

Re: liboutput: thoughts about shared library on top of DRM/KMS

[Keith Packard]

Daniel Stone  writes:

> I think there would be a load of value in starting with simple helpers
> which can be used independently of any larger scheme, tackling that
> list above.

Yeah, a helper library that didn't enforce at tonne of policy and just
let the user glue things together on their own is probably going to be
more generally usable by existing and new systems.

I definitely like the idea of stealing the best parts of all existing
systems and trying to make them work together.

How many libraries we end up with isn't nearly as important to me as
making sure they work well together; common data types, similar style,
etc.

-- 
-keith


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

Re: liboutput: thoughts about shared library on top of DRM/KMS

[Keith Packard]

Robert Foss  writes:

> Hey Keith,
>
> Thanks for setting this up, and picking a descriptive project name :)
>
> How is liboutput going to relate to the libliftoff[1] project?

We heard about libliftoff at XDC. It sounds like it does the plane
selection stuff, including searching for configurations that support
'most' of what the user asked for while passing back a list of 'uh,
these didn't fit'. That sounds like a good foundation for liboutput.

I think we want a bit more, including things like render-based
operations for compositing fallback, format conversion, transforms,
PRIME support etc. I think we might also want to be able to create
pseudo outputs (to memory only) for things like virtualization and
testing.

Mostly, I heard lots of ideas at XDC about more we might do to share
code between DRM/KMS users, especially compositors.

I'd love to keep the conversation going and see if we can generate a
solid set of shared goals, then put together some kind of architecture
and bits of code to see what might work.

-- 
-keith


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

liboutput: thoughts about shared library on top of DRM/KMS

["Keith Packard"]

During XDC this year, we heard a few presentations and had a lot of
hallway talk about sharing code for driving DRM/KMS for display.

I think the general consensus is that there is enough shared
functionality between all of the various DRM/KMS clients that we can
start thinking about building a library that deals with the complexity
of DRM/KMS and can help take full advantage of the hardware.

I've started writing up some ideas, mostly just goals, but also some
random thoughts about how this might work. This is all in the
'liboutput' project on freedesktop.org:

https://gitlab.freedesktop.org/xorg/liboutput

I picked a spot in the 'xorg' namespace, not to confine this to X
systems, but to reflect the goal that this be a library shared across
all x.org-related projects, including Wayland compositors, EGL and
Vulkan direct applications and the X server.

All there is at this point is a README.md file; I'd like to generate
some consensus on a direction for the project before we start writing
any actual design documents.

Please submit MRs to that repo, or respond to this email as you prefer.

-- 
-keith


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

Re: Expose more EDID fields to userspace

[Keith Packard]

Stéphane Marchesin  writes:

> I don't have strong feelings for against this approach, but if we do this,
> I think we should ensure we keep providing the original EDID to user space.
> The contents of EDIDs have so many implications that even the kernel isn't
> always in the best position to decide if a rewrite is a good idea.

Yeah, I think I've talked myself out of modifying EDID too. What I'm
thinking this afternoon is that we should ensure that every value
derived from EDID, (and potentially modified by the kernel), needs to be
exposed to user space so that it too can play with the same
information.

If we could get a common EDID parsing library shared between kernel and
user space, that would at least give everyone the same view of the data.

> For a simple example, we can look at the max pixel clock which is reported
> in the EDID. If the EDID gets rewritten with a lower pixel clock that
> matches what the link can do, user space loses the ability to pop up a UI
> dialog telling the user that if they were using a better cable, they could
> get higher resolutions. Something similar already happens today with some
> display dongles which decide to rewrite EDIDs based on their own
> limitations. It prevents user space from showing a dialog recommending a
> better dongle. Of course one could argue the dongle is protecting itself
> here :)

Oh, that's a fine point -- what this exposes is that user space should
be able to see the lower pixel clock value which the kernel is
using. And doing that separate from the EDID data means it can explain
what's going on.

> FWIW for Chrome OS we do parse the color space in user space, since as you
> mention this isn't available through the DRM properties.

If this isn't used by the kernel, then doing it in user space is
probably the right plan.

> Tangentially related, the content of these color points is often very...
> "buggy". We have to do some sanity checking before deciding to use it or
> not. That's why I think that even with all the information parsed by the
> kernel, you still need another layer...

Right, having a shared library and database for these kinds of quirks
would be awesome.

> Yes I like the idea of parsing in user space, since it doesn't require new
> kernel changes at all, and typically updating a user space library is
> simpler than changing kernel versions. Frankly it feels to me that the
> kernel doesn't really have a business here except passing through the raw
> EDID contents to a component which knows better.

Agreed, as long as we also fix the kernel to tell user space what it's
doing with the EDID data, especially where it's modifying values.

-- 
-keith


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

Re: Expose more EDID fields to userspace

[Keith Packard]

Daniel Vetter  writes:

> Connector properties are documented here:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties

Cool. Seems like we might want a bit more organization here to make it
clear which of these are derived from the connected monitor.

It would be good to read through the source code to find other EDID-ish
data being used within the kernel. Things like the vendor and model info
might be useful as properties, especially if there might be quirks to
'fix' the edid values and drive other kernel behavior.

-- 
-keith


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

Re: Expose more EDID fields to userspace

[Keith Packard]

Adam Jackson  writes:

> If the kernel wanted to expose its quirks db somehow the library could
> certainly be taught to use it. However there are likely to be quirks
> relevant only to userspace (see below), making the kernel carry that
> doesn't make a ton of sense.

We do expose some of the quirks to user space, but not as a database,
and not consistently. Some of the quirks just match EDID data to drive
some decision (like non-desktop). Other quirks override some EDID data
that is 'wrong'. For these latter instances, I wonder if we shouldn't be
re-writing the EDID data that user space gets? Or at least making sure
the quirked values are available to user space?

> Part of the problem with the idea is that EDID parsing is not
> unambiguous. There are several fields for "physical output size" with
> slightly different semantics, which one do you want? There are both
> structured and free-form ways to encode monitor name and serial
> number.

Hrm. For places where the kernel *does* parse the data, it would sure be
nice to have the kernel version to at least make that
consistent. Model/serial data used to select quirks seems like something
we should be exposing?

I'm getting the feeling that either extreme approach (parse all of the
EDID data, or parse none of it) is not going to work and that our
current technique of picking some EDID-derived data to expose as
separate parsed values, and some to leave for user space to discover for
itself is where we'll be stuck for at least the near term.

If we come to agreement that this approach is what we'll be doing, then
I'd like to have a couple of suggestions:

 1) Document what we've got today

 2) Document basic guidelines of when to expose parsed EDID-derived data
and when to just leave it in the EDID block for user space

 3) Plan on exposing all values which the kernel *does* use internally
as parsed-out properties. Especially values which get quirked,
possibly exposing both the "raw" value and the "quirk" value.

 4) Decide if we want to let user-space in on the quirking fun. I can
imagine a user-space helper that gets run at hot-plug time, reads
the EDID data and then pokes quirk values into the kernel.

 5) Decide, as a matter of policy, whether the kernel will ever edit
EDID data that gets exposed to user space. I can think of good
reasons on both sides, but I think we need to hash out what the
kernel will do so that user space knows what's going on.

I think what I want is for kernel and user space to at least be
operating on the same data, even if we end up re-implementing a pile of
code up in user space.

-- 
-keith


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

Re: Expose more EDID fields to userspace

[Keith Packard]

Daniel Vetter  writes:

> Best to pull in some other compositor people and get them to agree. From a
> kernel pov I'm fine with whatever userspace preferes.

Hrm. It would be good to have everyone using the same interpretation of
EDID data; in particular, where the kernel has quirks that change the
interpretation, user space should be consistent with that.

Unless we expose all of the EDID data, then user space may still have to
parse EDID. If the kernel has EDID quirks, it might be good to to make
those affect the "raw" EDID data visible to use space so that values the
kernel supplies separately are consistent with values extracted from the
"raw" EDID data.

Doing this in the kernel does make it harder to quickly supply fixes for
a specific user space application. This will probably lead to
kludge-arounds in user space that could depend on kernel
version. Perhaps these EDID capabilities in the kernel should be
versioned separately?

I see good benefits from having user space able to see how the kernel is
interpreting EDID so that it can adapt as appropriate, but we should be
cautious about moving functionality into the kernel that would be more
easily maintained up in user space.

-- 
-keith


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

Re: [PATCH] drm/lease: Send a distinct uevent

[Keith Packard]

Daniel Vetter  writes:

> Cc: Keith Packard 

Reviewed-by: Keith Packard 

-- 
-keith


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

[PATCH] vulkan: Add VK_GOOGLE_display_timing extension (x11+display, anv+radv) [v7]

[Keith Packard]

This adds support for the VK_GOOGLE_display timing extension, which
provides two things:

 1) Detailed information about when frames are displayed, including
slack time between GPU execution and display frame.

 2) Absolute time control over swapchain queue processing. This allows
the application to request frames be displayed at specific
absolute times, using the same timebase as that provided in vblank
events.

Support for this extension has been implemented for the x11 and
display backends; adding support to other backends should be
reasonable straightforward for one familiar with those systems and
should not require any additional device-specific code.

v2:
Adjust GOOGLE_display_timing earliest value.  The
earliestPresentTime for an image cannot be before the previous
image was displayed, or even a frame later (in FIFO mode).

Make GOOGLE_display_timing use render completed time.  Switch
from VK_PIPELINE_TOP_OF_PIPE_BIT to
VK_PIPELINE_STAGE_ALL_COMMANDS_BIT so that the time reported
to applications as the end of rendering reflects the latest
possible value to ensure that applications don't underestimate
the amount of work done in the frame.

v3:
Adopt Jason Ekstrand's coding conventions.  Declare variables
at first use, eliminate extra whitespace between types and
names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

v4:
Adapt to changes in MESA_query_timestamp extension

v5:
Squash core bits and anv/radv wrappers into a single patch

Suggested-by: Jason Ekstrand 

v6:
Switch from MESA_query_timestamp to EXT_calibrated_timestamps

v7:
Ensure we target frame no earlier than desired. This means
rounding the target frame up, rather than selecting the
nearest one.

Suggested-by: Michel Dänzer 

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py   |   1 +
 src/amd/vulkan/radv_wsi.c   |  33 +++
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_wsi.c  |  33 +++
 src/vulkan/wsi/wsi_common.c | 303 +++-
 src/vulkan/wsi/wsi_common.h |  32 +++
 src/vulkan/wsi/wsi_common_display.c | 165 ++-
 src/vulkan/wsi/wsi_common_private.h |  35 
 src/vulkan/wsi/wsi_common_x11.c |  71 ++-
 9 files changed, 662 insertions(+), 12 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 6bdf988d117..76c3ade06f0 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -119,6 +119,7 @@ EXTENSIONS = [
 Extension('VK_AMD_shader_trinary_minmax', 1, True),
 Extension('VK_GOOGLE_decorate_string',1, True),
 Extension('VK_GOOGLE_hlsl_functionality1',1, True),
+Extension('VK_GOOGLE_display_timing', 1, True),
 ]
 
 class VkVersion:
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 346fb43d675..ba24d07edfc 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -295,3 +295,36 @@ VkResult radv_GetPhysicalDevicePresentRectanglesKHR(
 surface,
 pRectCount, pRects);
 }
+
+/* VK_GOOGLE_display_timing */
+VkResult
+radv_GetRefreshCycleDurationGOOGLE(
+   VkDevice _device,
+   VkSwapchainKHR swapchain,
+   VkRefreshCycleDurationGOOGLE *pDisplayTimingProperties)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_refresh_cycle_duration(>wsi_device,
+_device,
+swapchain,
+pDisplayTimingProperties);
+}
+
+VkResult
+radv_GetPastPresentationTimingGOOGLE(VkDevice _device,
+VkSwapchainKHR swapchain,
+uint32_t *pPresentationTimingCount,
+VkPastPresentationTimingGOOGLE
+*pPresentationTimings)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_past_presentation_timing(>wsi_device,
+  _device,
+  swapchain,
+  pPresentationTimingCount,
+  pPresentationTimings);
+}
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index e9afe06bb13..8fcc4d1376e 100644
--- a/src/intel/vulkan/anv_extensions.py
+++

Re: [Mesa-dev] [PATCH] vulkan: Add VK_GOOGLE_display_timing extension (x11+display, anv+radv) [v6]

[Keith Packard]

Michel Dänzer  writes:

Thanks for taking time to review this patch!

>> +   int64_t refresh = (int64_t) refresh_timing.refreshDuration;
>> +   int64_t frames = (delta_nsec + refresh/2) / refresh;
>
> desiredPresentTime has "no sooner than" semantics, so I think this should be
>
>int64_t frames = (delta_nsec + refresh-1) / refresh;

Hrm. You're certainly right that we want to make sure to not hit the
wrong frame, and we need to be very careful with this computation. And
that turns out to be 'hard'.

With a naïve computation of frame times:

future_frame_time = past_frame_time + n * refresh

If the reported refresh is longer than the actual interval, due
to rounding of that value or clock skew, this computation might select
frame n+1 if the driver uses a later frame for its basis than the
application:

desiredPresentTime = application_past_frame_time + n * refresh

delta_nsec = (desiredPresentTime - driver_past_frame_time);
frames = (delta_nsec + refresh-1) / refresh;

If 'driver_past_frame_time' was sampled 'm' frames after
'application_past_frame time', and 'refresh' is longer than the
actual frame time:

desiredPresentTime > driver_past_frame_time + m * refresh

Because desiredPresentTime is *past* our estimate of the beginning of
the frame the application wants, and because we're rounding the selected
frame up, we end up targeting one frame too late.

Now, if we use my value for 'frames', then we hit the right frame using
this value, as long as the error is less than 1/2 frame time:

desiredPresentTime > driver_past_frame_time + m * refresh
desiredPresentTime < driver_past_frame_time + m * refresh + refresh/2

delta_nsec > m * refresh
delta_nsec < m * refresh + refresh / 

frames > (m * refresh + refresh/2) / refresh
frames < (m * refresh + refresh) / refresh

With this computation, frames = m, which is the desired result.

So at least you can see where my code came from. But, it's clearly wrong
according to the spec, as you'll see in the next section.

An application can attempt to compensate for this by using an earlier
time; a slightly less naïve computation might look like:

future_frame_time = past_frame_time + 1 + (n-1) * refresh

This makes 'future_frame_time' be the earliest possible time that should
target the desired frame, given the 'no sooner than' semantics in the
spec.

If the reported refresh is shorter than the actual interval, this
computation might hit frame (n-1).

Ok, so now we make the application even 'smarter' by having it compute a
time in the center of the target frame:

future_frame_time = past_frame_time + (refresh/2) + (n-1) * refresh

With your suggested code, this will hit the desired frame unless the
error in the frame time is more than 1/2 of the refresh interval, which
seems pretty good.

Ok, so what can we do? I think we start with what we know:

 * driver_past_frame_time >= application_past_frame_time

   Because all application frame time information comes from the driver,
   we just need to use the latest possible frame time in the driver to
   keep this true.

Now, what will cause errors in the 'refresh' value? 'refresh' error is a
combination of rounding error and CPU vs GPU clock skew.

 * Rounding error. This is always less than 1ns.

 * Clock skew is related to the performance of a couple of crystals in
   the system.

   Even cheap crystals provide significantly better than 100ppm (parts
   per million) performance. At 30Hz, refresh_interval is 33.3ms, or
   33,333,333ns, so each crystals will have a maximum error of 3300ns;
   combine two and we've a maximum error of 6600ns.

As you can see, the rounding error is lost in the noise here, unless we
find a system that uses CLOCK_MONOTONIC for display timing. It'll take
5000 frames before that error reaches a frame time.

As long as the application_past_frame_time is within 2500 frames of the
driver_past_frame_time, the error in the future_frame_time estimate will
be within one-half frame, and our application will work reliably using
the 'smarter' computation of future frame time.

I would prefer to let applications use the initial naïve
future_frame_time estimate, as I think that could also work with
variable refresh timing, but that would require a fairly complicated
change in the specification.

>> +   timing->target_msc = swapchain->frame_msc + frames;
>> +}
>> + }
>
> Note that MSC based timing won't work well with variable refresh rate.
> In the long term, support for PresentOptionUST should be implemented and
> used.

Agreed. Given the above discussion, I think that will have to wait for a
more sophisticated specification for what 'desiredPresentTime' means, as
I think the current specification makes it "impossible" to provide an
actual desiredPresentTime to the interface without that causing
occasional incorrect frame 

[PATCH] vulkan: Add VK_GOOGLE_display_timing extension (x11+display, anv+radv) [v6]

[Keith Packard]

This adds support for the VK_GOOGLE_display timing extension, which
provides two things:

 1) Detailed information about when frames are displayed, including
slack time between GPU execution and display frame.

 2) Absolute time control over swapchain queue processing. This allows
the application to request frames be displayed at specific
absolute times, using the same timebase as that provided in vblank
events.

Support for this extension has been implemented for the x11 and
display backends; adding support to other backends should be
reasonable straightforward for one familiar with those systems and
should not require any additional device-specific code.

v2:
Adjust GOOGLE_display_timing earliest value.  The
earliestPresentTime for an image cannot be before the previous
image was displayed, or even a frame later (in FIFO mode).

Make GOOGLE_display_timing use render completed time.  Switch
from VK_PIPELINE_TOP_OF_PIPE_BIT to
VK_PIPELINE_STAGE_ALL_COMMANDS_BIT so that the time reported
to applications as the end of rendering reflects the latest
possible value to ensure that applications don't underestimate
the amount of work done in the frame.

v3:
Adopt Jason Ekstrand's coding conventions.  Declare variables
at first use, eliminate extra whitespace between types and
names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

v4:
Adapt to changes in MESA_query_timestamp extension

v5:
Squash core bits and anv/radv wrappers into a single patch

Suggested-by: Jason Ekstrand 

v6:
Switch from MESA_query_timestamp to EXT_calibrated_timestamps

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py   |   1 +
 src/amd/vulkan/radv_wsi.c   |  33 +++
 src/intel/vulkan/anv_extensions.py  |   1 +
 src/intel/vulkan/anv_wsi.c  |  33 +++
 src/vulkan/wsi/wsi_common.c | 303 +++-
 src/vulkan/wsi/wsi_common.h |  32 +++
 src/vulkan/wsi/wsi_common_display.c | 165 ++-
 src/vulkan/wsi/wsi_common_private.h |  35 
 src/vulkan/wsi/wsi_common_x11.c |  71 ++-
 9 files changed, 662 insertions(+), 12 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 6bdf988d117..76c3ade06f0 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -119,6 +119,7 @@ EXTENSIONS = [
 Extension('VK_AMD_shader_trinary_minmax', 1, True),
 Extension('VK_GOOGLE_decorate_string',1, True),
 Extension('VK_GOOGLE_hlsl_functionality1',1, True),
+Extension('VK_GOOGLE_display_timing', 1, True),
 ]
 
 class VkVersion:
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 346fb43d675..ba24d07edfc 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -295,3 +295,36 @@ VkResult radv_GetPhysicalDevicePresentRectanglesKHR(
 surface,
 pRectCount, pRects);
 }
+
+/* VK_GOOGLE_display_timing */
+VkResult
+radv_GetRefreshCycleDurationGOOGLE(
+   VkDevice _device,
+   VkSwapchainKHR swapchain,
+   VkRefreshCycleDurationGOOGLE *pDisplayTimingProperties)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_refresh_cycle_duration(>wsi_device,
+_device,
+swapchain,
+pDisplayTimingProperties);
+}
+
+VkResult
+radv_GetPastPresentationTimingGOOGLE(VkDevice _device,
+VkSwapchainKHR swapchain,
+uint32_t *pPresentationTimingCount,
+VkPastPresentationTimingGOOGLE
+*pPresentationTimings)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_past_presentation_timing(>wsi_device,
+  _device,
+  swapchain,
+  pPresentationTimingCount,
+  pPresentationTimings);
+}
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index e9afe06bb13..8fcc4d1376e 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -130,6 +130,7 @@ EXTENSIONS = [
 Extension('VK_EXT_calibrated_timestamps', 1, True),
 Extension('VK_GOOGLE_decorate_string',   

Re: [PATCH] drm/lease: drop EXPORT_SYMBOL

[Keith Packard]

Daniel Vetter  writes:

> Leases are entirely implemented within drm.ko, no need to even tempt
> drivers into doing nasty things. And if there's really a need, we can
> always re-export these again.
>
> Cc: Keith Packard 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 

Acked-by: Keith Packard 

-- 
-keith


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

Re: [PATCH 3/3] drm/lease: look at ->universal_planes only once

[Keith Packard]

Daniel Vetter  writes:

> @@ -359,7 +359,8 @@ void drm_lease_revoke(struct drm_master *top)
>  static int validate_lease(struct drm_device *dev,
> struct drm_file *lessor_priv,
> int object_count,
> -   struct drm_mode_object **objects)
> +   struct drm_mode_object **objects,
> +   bool universal_planes)

It looks like you can remove the lessor_priv argument here, which would
ensure that we didn't reference any fields in it in the future.

-- 
-keith


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

Re: [PATCH 1/3] drm/lease: debug output for lease creation

[Keith Packard]

Daniel Vetter  writes:

> I spent a bit of time scratching heads and figuring out why the igts
> don't work. Probably useful to keep this work.

Acked-by: Keith Packard 

>   /* Do not allow sub-leases */
> - if (lessor->lessor)
> + if (lessor->lessor) {
> + DRM_DEBUG_LEASE("recursive leasing not allowed\n");
>   return -EINVAL;
> + }

(not review about this patch, just noticing that the relevant code is here:-)

We may want to revisit this restriction as it looks like multi-seat may
end up using leases from a manager to multiple X servers and letting
those X servers support leases would be a good thing.

-- 
-keith


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

Re: [Mesa-dev] [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v5]

[Keith Packard]

Bas Nieuwenhuizen  writes:

> Reviewed-by: Bas Nieuwenhuizen 

Thanks to you, Jason and Lionel for reviewing the code and helping
improve it.

-- 
-keith


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

Re: [Mesa-dev] [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v5]

[Keith Packard]

Jason Ekstrand  writes:

> I like it

When the comments are longer than the code, you know you're done?

-- 
-keith


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

[PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v5]

[Keith Packard]

Offers three clocks, device, clock monotonic and clock monotonic
raw. Could use some kernel support to reduce the deviation between
clock values.

v2:
Ensure deviation is at least as big as the GPU time interval.

v3:
Set device->lost when returning DEVICE_LOST.
Use MAX2 and DIV_ROUND_UP instead of open coding these.
Delete spurious TIMESTAMP in radv version.

Suggested-by: Jason Ekstrand 
Suggested-by: Lionel Landwerlin 

v4:
Add anv_gem_reg_read to anv_gem_stubs.c

Suggested-by: Jason Ekstrand 

v5:
Adjust maxDeviation computation to max(sampled_clock_period) +
sample_interval.

Suggested-by: Bas Nieuwenhuizen 
Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_device.c   | 119 +++
 src/amd/vulkan/radv_extensions.py  |   1 +
 src/intel/vulkan/anv_device.c  | 127 +
 src/intel/vulkan/anv_extensions.py |   1 +
 src/intel/vulkan/anv_gem.c |  13 +++
 src/intel/vulkan/anv_gem_stubs.c   |   7 ++
 src/intel/vulkan/anv_private.h |   2 +
 7 files changed, 270 insertions(+)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 174922780fc..4a705a724ef 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4955,3 +4955,122 @@ radv_GetDeviceGroupPeerMemoryFeatures(
   VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT |
   VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT;
 }
+
+static const VkTimeDomainEXT radv_time_domains[] = {
+   VK_TIME_DOMAIN_DEVICE_EXT,
+   VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT,
+   VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT,
+};
+
+VkResult radv_GetPhysicalDeviceCalibrateableTimeDomainsEXT(
+   VkPhysicalDevice physicalDevice,
+   uint32_t *pTimeDomainCount,
+   VkTimeDomainEXT  *pTimeDomains)
+{
+   int d;
+   VK_OUTARRAY_MAKE(out, pTimeDomains, pTimeDomainCount);
+
+   for (d = 0; d < ARRAY_SIZE(radv_time_domains); d++) {
+   vk_outarray_append(, i) {
+   *i = radv_time_domains[d];
+   }
+   }
+
+   return vk_outarray_status();
+}
+
+static uint64_t
+radv_clock_gettime(clockid_t clock_id)
+{
+   struct timespec current;
+   int ret;
+
+   ret = clock_gettime(clock_id, );
+   if (ret < 0 && clock_id == CLOCK_MONOTONIC_RAW)
+   ret = clock_gettime(CLOCK_MONOTONIC, );
+   if (ret < 0)
+   return 0;
+
+   return (uint64_t) current.tv_sec * 10ULL + current.tv_nsec;
+}
+
+VkResult radv_GetCalibratedTimestampsEXT(
+   VkDevice _device,
+   uint32_t timestampCount,
+   const VkCalibratedTimestampInfoEXT   *pTimestampInfos,
+   uint64_t *pTimestamps,
+   uint64_t *pMaxDeviation)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   uint32_t clock_crystal_freq = 
device->physical_device->rad_info.clock_crystal_freq;
+   int d;
+   uint64_t begin, end;
+uint64_t max_clock_period = 0;
+
+   begin = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
+
+   for (d = 0; d < timestampCount; d++) {
+   switch (pTimestampInfos[d].timeDomain) {
+   case VK_TIME_DOMAIN_DEVICE_EXT:
+   pTimestamps[d] = device->ws->query_value(device->ws,
+
RADEON_TIMESTAMP);
+uint64_t device_period = DIV_ROUND_UP(100, 
clock_crystal_freq);
+max_clock_period = MAX2(max_clock_period, 
device_period);
+   break;
+   case VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT:
+   pTimestamps[d] = radv_clock_gettime(CLOCK_MONOTONIC);
+max_clock_period = MAX2(max_clock_period, 1);
+   break;
+
+   case VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT:
+   pTimestamps[d] = begin;
+   break;
+   default:
+   pTimestamps[d] = 0;
+   break;
+   }
+   }
+
+   end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
+
+/*
+ * The maximum deviation is the sum of the interval over which we
+ * perform the sampling and the maximum period of any sampled
+ * clock. That's because the maximum skew between any two sampled
+ * clock edges is when the sampled clock with the largest period is
+ * sampled at the end of that period but right at the beginning of the
+ * sampling interval and some other clock is sampled ri

Re: [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Keith Packard]

Jason Ekstrand  writes:

> Doing all of the CPU sampling on one side or the other of the GPU sampling
> would probably reduce our window.

True, although as I said, it's taking several µs to get through the
loop, and the gpu clock tick is far smaller than that, so even adding
the two values together to make it fit the current implementation won't
make the deviation that much larger.

> This leaves us with a delta of I + max(P(M), P(R), P(G)).  In
> particular, any two real-number valued times are, instantaneously,
> within that interval.

That, at least, would be easy to compute, and scale nicely if we added
more clocks in the future.

> Personally, I'm completely content to have the delta just be a the first
> one: a bound on the difference between any two real-valued times.  At this
> point, I can guarantee you that far more thought has been put into this
> mesa-dev discussion than was put into the spec and I think we're rapidly
> getting to the point of diminishing returns. :-)

It seems likely. How about we do the above computation for the current
code and leave it at that?

-- 
-keith


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

Re: [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Keith Packard]

Jason Ekstrand  writes:


> The result is that we're looking at something like "end - start +
> monotonic_raw_tick + max(gpu_tick, monotonic_tick)"  Have I just come
> full-circle?

Yes.  As monotonic_raw_tick and monotonic_tick are both 1...

-- 
-keith


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

Re: [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Keith Packard]

Bas Nieuwenhuizen  writes:

> You can make the monotonic case the same as the raw case if you make
> sure to always sample the CPU first by e.g. splitting the loops into
> two and doing CPU in the first and GPU in the second. That way you
> make the case above impossible.

Right, I had thought of that, and it probably solves the problem for
us. If more time domains are added, things become 'more complicated'
though.

> That said "start of the interval of the tick" is kinda arbitrary and
> you could pick random other points on that interval, so depending on
> what requirements you put on it (i.e. can the chosen position be
> different per call, consistent but implicit or explicitly picked which
> might be leaked through the interface) the max deviation changes. So
> depending on interpretation this thing can be very moot ...

It doesn't really matter what phase you use; the timer increments
periodically, and what really matters is the time when that happens
relative to other clocks changing.

-- 
-keith


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

Re: [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Keith Packard]

Bas Nieuwenhuizen  writes:

> Well the complication here is that in the MONOTONIC (not
> MONOTONIC_RAW) case the CPU measurement can happen at the end of the
> MONOTONIC_RAW interval (as the order of measurements is based on
> argument order), so you can get a tick that started `period` (5 in
> this case) monotonic ticks before the start of the interval and a CPU
> measurement at the end of the interval.

Ah, that's an excellent point. Let's split out raw and monotonic and
take a look. You want the GPU sampled at the start of the raw interval
and monotonic sampled at the end, I think?

 w x y z 0 1 2 3 4 5 6 7 8 9 a b c d e f
Raw  -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

  0 1 2 3
GPU   -_-_-_-_

x y z 0 1 2 3 4 5 6 7 8 9 a b c
Monotonic   -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

Interval <->
Deviation   <-->

start = read(raw)   2
gpu   = read(GPU)   1
mono  = read(monotonic) 2
end   = read(raw)   b

In this case, the error between the monotonic pulse and the GPU is
interval + gpu_period (probably plus one to include the measurement
error of the raw clock).

Thanks for finding this case.

Now, I guess the question is whether we want to try and find the
smallest maxDeviation possible for each query. For instance, if the
application asks only for raw and gpu, the max_deviation could be
max2(interval+1,gpu_period), but if it asks for monotonic and gpu, it
would be interval+1+gpu_period. I'm not seeing a simple definition
here...

-- 
-keith


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

Re: [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Keith Packard]

Jason Ekstrand  writes:


> You've got me almost convinced as well.  Thanks for the diagrams!  I think
> instead of adding 1 perhaps what we want is
>
> max2(sample_interval_ns, gpu_tick_ns + monotonic_tick_ns)
>
> Where monotonic_tick_ns is maybe as low as 1.  Am I following you correctly?

Not quite; I was thinking that because the sample_interval_ns is
measured by sampling the monotonic clock twice, the actual interval can
be up to 1 tick longer, so

max2(sample_interval_ns + monotonic_tick_ns, gpu_tick_ns)

The gpu_tick_ns is computed, not measured, and so accurately reflects
the maximum deviation in the measurements.

-- 
-keith


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

Re: [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Keith Packard]

Jason Ekstrand  writes:

> I think what Bas is getting at is that there are two problems:
>
>  1) We are not sampling at exactly the same time
>  2) The two clocks may not tick at exactly the same time.

Thanks for the clarification.

> If we want to be conservative, I suspect Bas may be right that adding is
> the safer thing to do.

Yes, it's certainly safe to increase the value of
maxDeviation. Currently, the time it takes to sample all of the clocks
is far larger than the GPU tick, so adding that in would not have a huge
impact on the value returned to the application.

I'd like to dig in a little further and actually understand if the
current computation (which is derived directly from the Vulkan spec) is
wrong, and if so, whether the spec needs to be adjusted.

I think the question is what 'maxDeviation' is supposed to
represent. All the spec says is:

 * pMaxDeviation is a pointer to a 64-bit unsigned integer value in
   which the strictly positive maximum deviation, in nanoseconds, of the
   calibrated timestamp values is returned.

I interpret this as the maximum error in sampling the individual clocks,
which is to say that the clock values are guaranteed to have been
sampled within this interval of each other.

So, if we have a monotonic clock and GPU clock:

  0 1 2 3 4 5 6 7 8 9 a b c d e f
Monotonic -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

  0 1 2 3
GPU   -_-_-_-_


gpu_period in this case is 5 ticks of the monotonic clock.

Now, I perform three operations:

start = read(monotonic)
gpu   = read(GPU)
end   = read(monotonic)

Let's say that:

start = 2
GPU = 1 * 5 = 5 monotonic equivalent ticks
end = b

So, the question is only how large the error between GPU and start could
possibly be. Certainly the GPU clock was sampled some time between
when monotonic tick 2 started and monotonic tick b ended. But, we have
no idea what phase the GPU clock was in when sampled.

Let's imagine we manage to sample the GPU clock immediately after the
first monotonic sample. I'll shift the offset of the monotonic and GPU
clocks to retain the same values (start = 2, GPU = 1), but now
the GPU clock is being sampled immediately after monotonic time 2:

w x y z 0 1 2 3 4 5 6 7 8 9 a b c d e f
Monotonic   -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

  0 1 2 3
GPU   -_-_-_-_


In this case, the GPU tick started at monotonic time y, nearly 5
monotonic ticks earlier than the measured monotonic time, so the
deviation between GPU and monotonic would be 5 ticks.

If we sample the GPU clock immediately before the second monotonic
sample, then that GPU tick either starts earlier than the range, in
which case the above evaluation holds, or the GPU tick is entirely
contained within the range:

  0 1 2 3 4 5 6 7 8 9 a b c d e f
Monotonic -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

   z 0 1 2 3
GPU  __-_-_-_-_-

In this case, the deviation between the first monotonic sample (that
returned to the application as the monotonic time) and the GPU sample is
the whole interval of measurement (b - 2).

I think I've just managed to convince myself that Jason's first
suggestion (max2(sample interval, gpu interval)) is correct, although I
think we should add '1' to the interval to account for sampling phase
errors in the monotonic clock. As that's measured in ns, and I'm
currently getting values in the µs range, that's a small error in
comparison.

-- 
-keith


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

Re: [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Keith Packard]

Bas Nieuwenhuizen  writes:

>> +   end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
>> +
>> +   uint64_t clock_period = end - begin;
>> +   uint64_t device_period = DIV_ROUND_UP(100, clock_crystal_freq);
>> +
>> +   *pMaxDeviation = MAX2(clock_period, device_period);
>
> Should this not be a sum? Those deviations can happen independently
> from each other, so worst case both deviations happen in the same
> direction which causes the magnitude to be combined.

This use of MAX2 comes right from one of the issues raised during work
on the extension:

 8) Can the maximum deviation reported ever be zero?

 RESOLVED: Unless the tick of each clock corresponding to the set of
 time domains coincides and all clocks can literally be sampled
 simutaneously, there isn’t really a possibility for the maximum
 deviation to be zero, so by convention the maximum deviation is always
 at least the maximum of the length of the ticks of the set of time
 domains calibrated and thus can never be zero.

I can't wrap my brain around this entirely, but I think that this says
that the deviation reported is supposed to only reflect the fact that we
aren't sampling the clocks at the same time, and so there may be a
'tick' of error for any sampled clock.

If you look at the previous issue in the spec, that actually has the
pseudo code I used in this implementation for computing maxDeviation
which doesn't include anything about the time period of the GPU.

Jason suggested using the GPU period as the minimum value for
maxDeviation at the GPU time period to make sure we never accidentally
returned zero, as that is forbidden by the spec. We might be able to use
1 instead, but it won't matter in practice as the time it takes to
actually sample all of the clocks is far longer than a GPU tick.

-- 
-keith


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

Re: [Mesa-dev] [PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v3]

[Keith Packard]

Jason Ekstrand  writes:


> You need to add this to anv_gem_stubs.c as well or else the unit tests
> won't build.  Sorry for not catching it earlier.  I'm always missing this
> too.

Well, that's a bit hard to test as -Dbuild-tests=true fails in a bunch
of glx tests, but I think I've got it.

> With that fixed, the anv bits are
>
> Reviewed-by: Jason Ekstrand 

Thanks. I haven't heard from any radv developers, so I can either split
the patch apart or wait for another day or two. In any case, I'll post
v4 of the patch here with the anv_gem_reg_read addition made.

-- 
-keith


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

[PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Keith Packard]

Offers three clocks, device, clock monotonic and clock monotonic
raw. Could use some kernel support to reduce the deviation between
clock values.

v2:
Ensure deviation is at least as big as the GPU time interval.

v3:
Set device->lost when returning DEVICE_LOST.
Use MAX2 and DIV_ROUND_UP instead of open coding these.
Delete spurious TIMESTAMP in radv version.
Suggested-by: Jason Ekstrand 
Suggested-by: Lionel Landwerlin 

v4:
Add anv_gem_reg_read to anv_gem_stubs.c
Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_device.c   | 81 +++
 src/amd/vulkan/radv_extensions.py  |  1 +
 src/intel/vulkan/anv_device.c  | 89 ++
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_gem.c | 13 +
 src/intel/vulkan/anv_gem_stubs.c   |  7 +++
 src/intel/vulkan/anv_private.h |  2 +
 7 files changed, 194 insertions(+)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 174922780fc..80050485e54 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4955,3 +4955,84 @@ radv_GetDeviceGroupPeerMemoryFeatures(
   VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT |
   VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT;
 }
+
+static const VkTimeDomainEXT radv_time_domains[] = {
+   VK_TIME_DOMAIN_DEVICE_EXT,
+   VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT,
+   VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT,
+};
+
+VkResult radv_GetPhysicalDeviceCalibrateableTimeDomainsEXT(
+   VkPhysicalDevice physicalDevice,
+   uint32_t *pTimeDomainCount,
+   VkTimeDomainEXT  *pTimeDomains)
+{
+   int d;
+   VK_OUTARRAY_MAKE(out, pTimeDomains, pTimeDomainCount);
+
+   for (d = 0; d < ARRAY_SIZE(radv_time_domains); d++) {
+   vk_outarray_append(, i) {
+   *i = radv_time_domains[d];
+   }
+   }
+
+   return vk_outarray_status();
+}
+
+static uint64_t
+radv_clock_gettime(clockid_t clock_id)
+{
+   struct timespec current;
+   int ret;
+
+   ret = clock_gettime(clock_id, );
+   if (ret < 0 && clock_id == CLOCK_MONOTONIC_RAW)
+   ret = clock_gettime(CLOCK_MONOTONIC, );
+   if (ret < 0)
+   return 0;
+
+   return (uint64_t) current.tv_sec * 10ULL + current.tv_nsec;
+}
+
+VkResult radv_GetCalibratedTimestampsEXT(
+   VkDevice _device,
+   uint32_t timestampCount,
+   const VkCalibratedTimestampInfoEXT   *pTimestampInfos,
+   uint64_t *pTimestamps,
+   uint64_t *pMaxDeviation)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   uint32_t clock_crystal_freq = 
device->physical_device->rad_info.clock_crystal_freq;
+   int d;
+   uint64_t begin, end;
+
+   begin = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
+
+   for (d = 0; d < timestampCount; d++) {
+   switch (pTimestampInfos[d].timeDomain) {
+   case VK_TIME_DOMAIN_DEVICE_EXT:
+   pTimestamps[d] = device->ws->query_value(device->ws,
+
RADEON_TIMESTAMP);
+   break;
+   case VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT:
+   pTimestamps[d] = radv_clock_gettime(CLOCK_MONOTONIC);
+   break;
+
+   case VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT:
+   pTimestamps[d] = begin;
+   break;
+   default:
+   pTimestamps[d] = 0;
+   break;
+   }
+   }
+
+   end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
+
+   uint64_t clock_period = end - begin;
+   uint64_t device_period = DIV_ROUND_UP(100, clock_crystal_freq);
+
+   *pMaxDeviation = MAX2(clock_period, device_period);
+
+   return VK_SUCCESS;
+}
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 5dcedae1c63..4c81d3f0068 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -92,6 +92,7 @@ EXTENSIONS = [
 Extension('VK_KHR_display',  23, 
'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_calibrated_timestamps', 1, True),
 Extension('VK_EXT_conditional_rendering', 1, True),
 Extension('VK_EXT_conservative_rasterization',  

[PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v3]

[Keith Packard]

Offers three clocks, device, clock monotonic and clock monotonic
raw. Could use some kernel support to reduce the deviation between
clock values.

v2:
Ensure deviation is at least as big as the GPU time interval.

v3:
Set device->lost when returning DEVICE_LOST.
Use MAX2 and DIV_ROUND_UP instead of open coding these.
Delete spurious TIMESTAMP in radv version.
Suggested-by: Jason Ekstrand 
Suggested-by: Lionel Landwerlin 

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_device.c   | 81 +++
 src/amd/vulkan/radv_extensions.py  |  1 +
 src/intel/vulkan/anv_device.c  | 89 ++
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_gem.c | 13 +
 src/intel/vulkan/anv_private.h |  2 +
 6 files changed, 187 insertions(+)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 174922780fc..80050485e54 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4955,3 +4955,84 @@ radv_GetDeviceGroupPeerMemoryFeatures(
   VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT |
   VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT;
 }
+
+static const VkTimeDomainEXT radv_time_domains[] = {
+   VK_TIME_DOMAIN_DEVICE_EXT,
+   VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT,
+   VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT,
+};
+
+VkResult radv_GetPhysicalDeviceCalibrateableTimeDomainsEXT(
+   VkPhysicalDevice physicalDevice,
+   uint32_t *pTimeDomainCount,
+   VkTimeDomainEXT  *pTimeDomains)
+{
+   int d;
+   VK_OUTARRAY_MAKE(out, pTimeDomains, pTimeDomainCount);
+
+   for (d = 0; d < ARRAY_SIZE(radv_time_domains); d++) {
+   vk_outarray_append(, i) {
+   *i = radv_time_domains[d];
+   }
+   }
+
+   return vk_outarray_status();
+}
+
+static uint64_t
+radv_clock_gettime(clockid_t clock_id)
+{
+   struct timespec current;
+   int ret;
+
+   ret = clock_gettime(clock_id, );
+   if (ret < 0 && clock_id == CLOCK_MONOTONIC_RAW)
+   ret = clock_gettime(CLOCK_MONOTONIC, );
+   if (ret < 0)
+   return 0;
+
+   return (uint64_t) current.tv_sec * 10ULL + current.tv_nsec;
+}
+
+VkResult radv_GetCalibratedTimestampsEXT(
+   VkDevice _device,
+   uint32_t timestampCount,
+   const VkCalibratedTimestampInfoEXT   *pTimestampInfos,
+   uint64_t *pTimestamps,
+   uint64_t *pMaxDeviation)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   uint32_t clock_crystal_freq = 
device->physical_device->rad_info.clock_crystal_freq;
+   int d;
+   uint64_t begin, end;
+
+   begin = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
+
+   for (d = 0; d < timestampCount; d++) {
+   switch (pTimestampInfos[d].timeDomain) {
+   case VK_TIME_DOMAIN_DEVICE_EXT:
+   pTimestamps[d] = device->ws->query_value(device->ws,
+
RADEON_TIMESTAMP);
+   break;
+   case VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT:
+   pTimestamps[d] = radv_clock_gettime(CLOCK_MONOTONIC);
+   break;
+
+   case VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT:
+   pTimestamps[d] = begin;
+   break;
+   default:
+   pTimestamps[d] = 0;
+   break;
+   }
+   }
+
+   end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
+
+   uint64_t clock_period = end - begin;
+   uint64_t device_period = DIV_ROUND_UP(100, clock_crystal_freq);
+
+   *pMaxDeviation = MAX2(clock_period, device_period);
+
+   return VK_SUCCESS;
+}
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 5dcedae1c63..4c81d3f0068 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -92,6 +92,7 @@ EXTENSIONS = [
 Extension('VK_KHR_display',  23, 
'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_calibrated_timestamps', 1, True),
 Extension('VK_EXT_conditional_rendering', 1, True),
 Extension('VK_EXT_conservative_rasterization',1, 
'device->rad_info.chip_class >= GFX9'),
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_

Re: [PATCH] Add tests for VK_EXT_calibrated_timestamps [v2]

[Keith Packard]

Jason Ekstrand  writes:

> We're using MRs for crucible.  Please create one and make sure you check
> the "Allow commits from members who can merge to the target branch" so it
> can be rebased through the UI by someone other than yourself.

OOo. Shiny!

-- 
-keith


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

[PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v2]

[Keith Packard]

Offers three clocks, device, clock monotonic and clock monotonic
raw. Could use some kernel support to reduce the deviation between
clock values.

v2:
Ensure deviation is at least as big as the GPU time interval.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_device.c   | 84 
 src/amd/vulkan/radv_extensions.py  |  1 +
 src/intel/vulkan/anv_device.c  | 88 ++
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_gem.c | 13 +
 src/intel/vulkan/anv_private.h |  2 +
 6 files changed, 189 insertions(+)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 174922780fc..29f0afbc69b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4955,3 +4955,87 @@ radv_GetDeviceGroupPeerMemoryFeatures(
   VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT |
   VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT;
 }
+
+static const VkTimeDomainEXT radv_time_domains[] = {
+   VK_TIME_DOMAIN_DEVICE_EXT,
+   VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT,
+   VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT,
+};
+
+VkResult radv_GetPhysicalDeviceCalibrateableTimeDomainsEXT(
+   VkPhysicalDevice physicalDevice,
+   uint32_t *pTimeDomainCount,
+   VkTimeDomainEXT  *pTimeDomains)
+{
+   int d;
+   VK_OUTARRAY_MAKE(out, pTimeDomains, pTimeDomainCount);
+
+   for (d = 0; d < ARRAY_SIZE(radv_time_domains); d++) {
+   vk_outarray_append(, i) {
+   *i = radv_time_domains[d];
+   }
+   }
+
+   return vk_outarray_status();
+}
+
+static uint64_t
+radv_clock_gettime(clockid_t clock_id)
+{
+   struct timespec current;
+   int ret;
+
+   ret = clock_gettime(clock_id, );
+   if (ret < 0 && clock_id == CLOCK_MONOTONIC_RAW)
+   ret = clock_gettime(CLOCK_MONOTONIC, );
+   if (ret < 0)
+   return 0;
+
+   return (uint64_t) current.tv_sec * 10ULL + current.tv_nsec;
+}
+
+#define TIMESTAMP 0x2358
+
+VkResult radv_GetCalibratedTimestampsEXT(
+   VkDevice _device,
+   uint32_t timestampCount,
+   const VkCalibratedTimestampInfoEXT   *pTimestampInfos,
+   uint64_t *pTimestamps,
+   uint64_t *pMaxDeviation)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   uint32_t clock_crystal_freq = 
device->physical_device->rad_info.clock_crystal_freq;
+   int d;
+   uint64_t begin, end;
+
+   begin = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
+
+   for (d = 0; d < timestampCount; d++) {
+   switch (pTimestampInfos[d].timeDomain) {
+   case VK_TIME_DOMAIN_DEVICE_EXT:
+   /* XXX older kernels don't support this interface. */
+   pTimestamps[d] = device->ws->query_value(device->ws,
+
RADEON_TIMESTAMP);
+   break;
+   case VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT:
+   pTimestamps[d] = radv_clock_gettime(CLOCK_MONOTONIC);
+   break;
+
+   case VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT:
+   pTimestamps[d] = begin;
+   break;
+   default:
+   pTimestamps[d] = 0;
+   break;
+   }
+   }
+
+   end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
+
+   uint64_t clock_period = end - begin;
+   uint64_t device_period = (100 + clock_crystal_freq - 1) / 
clock_crystal_freq;
+
+   *pMaxDeviation = clock_period > device_period ? clock_period : 
device_period;
+
+   return VK_SUCCESS;
+}
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 5dcedae1c63..4c81d3f0068 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -92,6 +92,7 @@ EXTENSIONS = [
 Extension('VK_KHR_display',  23, 
'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_calibrated_timestamps', 1, True),
 Extension('VK_EXT_conditional_rendering', 1, True),
 Extension('VK_EXT_conservative_rasterization',1, 
'device->rad_info.chip_class >= GFX9'),
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index a25

[PATCH] Add tests for VK_EXT_calibrated_timestamps [v2]

[Keith Packard]

Five tests:

 1) Check for non-null function pointers
 2) Check for in-range time domains
 3) Check monotonic domains for correct values
 4) Check correlation between monotonic and device domains
 5) Check to make sure times in device domain match queue times

Signed-off-by: Keith Packard 
---
 Makefile.am|   1 +
 src/tests/func/calibrated-timestamps.c | 442 +
 2 files changed, 443 insertions(+)
 create mode 100644 src/tests/func/calibrated-timestamps.c

diff --git a/Makefile.am b/Makefile.am
index 0ca35bd..ba98c60 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -113,6 +113,7 @@ bin_crucible_SOURCES = \
src/tests/stress/lots-of-surface-state.c \
src/tests/stress/buffer_limit.c \
src/tests/self/concurrent-output.c \
+   src/tests/func/calibrated-timestamps.c \
src/util/cru_cleanup.c \
src/util/cru_format.c \
src/util/cru_image.c \
diff --git a/src/tests/func/calibrated-timestamps.c 
b/src/tests/func/calibrated-timestamps.c
new file mode 100644
index 000..a98150b
--- /dev/null
+++ b/src/tests/func/calibrated-timestamps.c
@@ -0,0 +1,442 @@
+/*
+ * Copyright © 2018 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.
+ */
+
+#include "tapi/t.h"
+#include 
+#include 
+#include 
+
+#define GET_DEVICE_FUNCTION_PTR(name) \
+PFN_vk##name name = (PFN_vk##name)vkGetDeviceProcAddr(t_device, "vk"#name)
+
+#define GET_INSTANCE_FUNCTION_PTR(name) \
+PFN_vk##name name = (PFN_vk##name)vkGetInstanceProcAddr(t_instance, 
"vk"#name)
+
+/* Test 1: Make sure the function pointers promised by the extension
+ * are valid
+ */
+static void
+test_funcs(void)
+{
+t_require_ext("VK_EXT_calibrated_timestamps");
+
+GET_INSTANCE_FUNCTION_PTR(GetPhysicalDeviceCalibrateableTimeDomainsEXT);
+GET_DEVICE_FUNCTION_PTR(GetCalibratedTimestampsEXT);
+
+t_assert(GetPhysicalDeviceCalibrateableTimeDomainsEXT != NULL);
+t_assert(GetCalibratedTimestampsEXT != NULL);
+}
+
+test_define {
+.name = "func.calibrated-timestamps.funcs",
+.start = test_funcs,
+.no_image = true,
+};
+
+/* Test 2: Make sure all of the domains offered by the driver are in range
+ */
+static void
+test_domains(void)
+{
+t_require_ext("VK_EXT_calibrated_timestamps");
+
+GET_INSTANCE_FUNCTION_PTR(GetPhysicalDeviceCalibrateableTimeDomainsEXT);
+GET_DEVICE_FUNCTION_PTR(GetCalibratedTimestampsEXT);
+
+t_assert(GetPhysicalDeviceCalibrateableTimeDomainsEXT != NULL);
+t_assert(GetCalibratedTimestampsEXT != NULL);
+
+VkResult result;
+
+uint32_t timeDomainCount;
+result = GetPhysicalDeviceCalibrateableTimeDomainsEXT(
+t_physical_dev,
+,
+NULL);
+t_assert(result == VK_SUCCESS);
+t_assert(timeDomainCount > 0);
+
+VkTimeDomainEXT *timeDomains = calloc(timeDomainCount, sizeof 
(VkTimeDomainEXT));
+t_assert(timeDomains != NULL);
+
+result = GetPhysicalDeviceCalibrateableTimeDomainsEXT(
+t_physical_dev,
+,
+timeDomains);
+
+t_assert(result == VK_SUCCESS);
+
+/* Make sure all reported domains are valid */
+for (uint32_t d = 0; d < timeDomainCount; d++) {
+t_assert(VK_TIME_DOMAIN_BEGIN_RANGE_EXT <= timeDomains[d] &&
+ timeDomains[d] <= VK_TIME_DOMAIN_END_RANGE_EXT);
+}
+}
+
+test_define {
+.name = "func.calibrated-timestamps.domains",
+.start = test_domains,
+.no_image = true,
+};
+
+static uint64_t
+crucible_clock_gettime(VkTimeDomainEXT domain)
+{
+struct timespec current;
+int ret;
+clockid_t clock_id;
+
+switch (domain) {
+case VK_TIME_DOMAIN_CLOCK_MONOTONIC_EXT:
+clock_id = CLOCK_MONOTONIC;
+break;
+case VK_TIME_DOMAIN_CLOCK_MONOTONIC_RAW_EXT:
+clock_id = CLOCK_MONOTONIC_RAW;
+break;
+default:
+t_assert(0);
+return 0;
+}
+
+ret = clock_gettime(clock_id, );
+t_assert (ret >= 0);
+if (ret < 0)
+return 0;
+
+return (uint64_t) current.tv_sec * 10ULL + current.tv_nsec;
+}
+
+/* Test 3: Make sure any monotonic domains return accurate data
+ */
+static void
+test_monotonic(void)
+{
+t_require_ext("VK_EXT_calibrated_timestamps");
+
+GET_INSTANCE_FUNCTION_PTR(GetPhysicalDeviceCalibrateableTimeDomainsEXT);
+GET_DEVICE_FUNCTION_PTR(GetCalibratedTimestampsEXT);
+
+t_assert(GetPhysicalDeviceCalibrateableTimeDomai

Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions

[Keith Packard]

Jason Ekstrand  writes:

> Actually, I think anv is doing the right thing too.  Now I have no idea why
> Keith was having problems.

anv is happily returning a valid pointer and radv is not?

In any case, I've switched to using vkGetInstanceProcAddr for the
VkPhysicalDevice function and it works fine with both drivers.

-- 
-keith


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

[PATCH] radv: Allow physical device interfaces to be included in device extensions

[Keith Packard]

According to the Vulkan spec:

"Vulkan 1.0 initially required all new physical-device-level extension
 functionality to be structured within an instance extension. In order
 to avoid using an instance extension, which often requires loader
 support, physical-device-level extension functionality may be
 implemented within device extensions"

The code that checks for enabled extension APIs currently only passes
functions with VkDevice or VkCommandBuffer as their first
argument. This patch extends that to also allow functions with
VkPhysicalDevice parameters, in support of the above quote from the
Vulkan spec.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_entrypoints_gen.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_entrypoints_gen.py 
b/src/amd/vulkan/radv_entrypoints_gen.py
index 377b544c2aa..69e6fc3e0eb 100644
--- a/src/amd/vulkan/radv_entrypoints_gen.py
+++ b/src/amd/vulkan/radv_entrypoints_gen.py
@@ -352,7 +352,7 @@ class Entrypoint(EntrypointBase):
 self.return_type = return_type
 self.params = params
 self.guard = guard
-self.device_command = len(params) > 0 and (params[0].type == 
'VkDevice' or params[0].type == 'VkQueue' or params[0].type == 
'VkCommandBuffer')
+self.device_command = len(params) > 0 and (params[0].type == 
'VkPhysicalDevice' or params[0].type == 'VkDevice' or params[0].type == 
'VkQueue' or params[0].type == 'VkCommandBuffer')
 
 def prefixed_name(self, prefix):
 assert self.name.startswith('vk')
-- 
2.19.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Add drm.edid_quirk_param module parameter

[Keith Packard]

This parameter allows the set of EDID quirks to be changed at
runtime. The syntax is

vendor/product/quirks,vendor/product/quirks,...

where vendor is the three-letter EDID vendor value, product is the
EDID product id which may be prefixed with 0x to for hex instead of
decimal values and quirks is the replacement quirks value from the
list in drm_edid.c.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_edid.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5dc742b27ca0..63b4587faddd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -98,6 +98,12 @@ struct detailed_mode_closure {
 #define LEVEL_GTF2 2
 #define LEVEL_CVT  3
 
+#define EDID_QUIRK_PARAM_LEN   256
+static char edid_quirk_param[EDID_QUIRK_PARAM_LEN];
+module_param_string(edid_quirk_param, edid_quirk_param, 
sizeof(edid_quirk_param), 0644);
+MODULE_PARM_DESC(edid_quirk_param, "Extra EDID quirks, "
+"format is 'vendor/product/quirks;...' ");
+
 static const struct edid_quirk {
char vendor[4];
int product_id;
@@ -1774,8 +1780,24 @@ static bool edid_vendor(const struct edid *edid, const 
char *vendor)
 static u32 edid_get_quirks(const struct edid *edid)
 {
const struct edid_quirk *quirk;
+   const char *q;
int i;
 
+   for (q = edid_quirk_param; q && *q; q = strchr(q, ',')) {
+   charvendor[4];
+   int product_id;
+   int quirks;
+
+   while (*q == ',')
+   q++;
+
+   if (sscanf(q, "%3s/%i/%i", vendor, _id, ) == 3) {
+   if (edid_vendor(edid, vendor) &&
+   (EDID_PRODUCT_ID(edid) == product_id))
+   return quirks;
+   }
+   }
+
for (i = 0; i < ARRAY_SIZE(edid_quirk_list); i++) {
quirk = _quirk_list[i];
 
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] vulkan: Define new VK_MESA_query_timestamp extension [v2]

[Keith Packard]

Pekka Paalanen  writes:

> I did not mean you would be solving that problem. I meant that it would
> be good to figure out what people actually want from the API to be able
> to solve the problem themselves.

Thanks for the clarification. I'd suggest that we not try and solve that
problem until we have someone who needs it?

What I'm using this extension for is to correlate GPU times with WSI
times as required by the GOOGLE_display_timing extension. That extension
reports the time gap between the end of rendering and when a frame is
displayed as reported by the WSI backend, so I needed some way to
translate between those two time domains. To do this, I call this new
function once per presentation, which means I'm getting recent values
for both clocks which should track any minor clock skew.

-- 
-keith


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

Re: [PATCH 1/3] vulkan: Define new VK_MESA_query_timestamp extension [v2]

[Keith Packard]

Pekka Paalanen  writes:

> On Sat, 23 Jun 2018 12:13:53 -0500
> Jason Ekstrand  wrote:
>
>> I haven't thought through this comment all that hard but would it make 
>> sense to have three timestamps, CPU, GPU, CPU so that you have error bars 
>> on the GPU timestamp?  At the very least, two timestamps would be better 
>> than one so that, when we pull it into the kernel, it can provide something 
>> more accurate than userspace trying to grab a snapshot.
>
> Hi,
>
> three timestamps sounds like a good idea to me, but you might want to
> reach out to media developers (e.g. gstreamer) who have experience in
> synchronizing different clocks and what that will actually take.

Oh, I know that's really hard, and I don't want to solve that problem
here. I explicitly *don't* solve it though -- I simply expose the
ability to get correlated values in the two application-visible time
domains that the Vulkan API already exposes (surface time and GPU
time). How to synchronize the application as those two clocks drift
around is outside the domain of this extension.

> When reading the CPU timestamp, I believe it would be necessary for
> userspace to tell which clock it should be reading. I'm not sure all
> userspace is always using CLOCK_MONOTONIC. But if you have a better
> rationale, that would be interesting to record and document.

The extension doesn't state which clock is returned, you provide a
device and a surface and get timestamps for both of them. This allows
applications to translate between the two Vulkan time domains.

As far as the implementation goes, it asks the device driver to get
correlated GPU and CLOCK_MONOTONIC values and then asks the WSI layer to
translate between CLOCK_MONOTONIC and surface time. Right now, all three
surface types already operate in CLOCK_MONOTONIC natively, so there
isn't any translation needed to surface time.

The anv and radv driver implementations are simplistic and could easily
be improved; they both simply fetch the GPU clock and then
CLOCK_MONOTONIC sequentially without attempting to bound the error
between them.

The entire reason for this extension is to allow me to implement the
GOOGLE_display_timing extension using only public interfaces into the
drivers. That patch is blocked on getting this functionality landed.

-- 
-keith


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

[PATCH 2/3] anv: Add new VK_MESA_query_timestamp extension to anv driver [v2]

[Keith Packard]

This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.

v2: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Add extension to list in alphabetical order

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_gem.c | 13 +
 src/intel/vulkan/anv_private.h |  3 +++
 src/intel/vulkan/genX_query.c  | 15 +++
 4 files changed, 32 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 0f99f58ecb1..37bace23857 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -120,6 +120,7 @@ EXTENSIONS = [
   'device->has_context_priority'),
 Extension('VK_EXT_shader_viewport_index_layer',   1, True),
 Extension('VK_EXT_shader_stencil_export', 1, 'device->info.gen 
>= 9'),
+Extension('VK_MESA_query_timestamp',  1, True),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 3ba6d198a8a..8a31940e7aa 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -423,6 +423,19 @@ anv_gem_fd_to_handle(struct anv_device *device, int fd)
return args.handle;
 }
 
+int
+anv_gem_reg_read(struct anv_device *device, uint32_t offset, uint64_t *result)
+{
+   struct drm_i915_reg_read args = {
+  .offset = offset
+   };
+
+   int ret = anv_ioctl(device->fd, DRM_IOCTL_I915_REG_READ, );
+
+   *result = args.val;
+   return ret;
+}
+
 #ifndef SYNC_IOC_MAGIC
 /* duplicated from linux/sync_file.h to avoid build-time dependency
  * on new (v4.7) kernel headers.  Once distro's are mostly using
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 510471da602..0fa2a46e333 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -76,6 +76,7 @@ struct gen_l3_config;
 #include 
 #include 
 #include 
+#include 
 
 #include "anv_entrypoints.h"
 #include "anv_extensions.h"
@@ -1055,6 +1056,8 @@ int anv_gem_get_aperture(int fd, uint64_t *size);
 int anv_gem_gpu_get_reset_stats(struct anv_device *device,
 uint32_t *active, uint32_t *pending);
 int anv_gem_handle_to_fd(struct anv_device *device, uint32_t gem_handle);
+int anv_gem_reg_read(struct anv_device *device,
+ uint32_t offset, uint64_t *result);
 uint32_t anv_gem_fd_to_handle(struct anv_device *device, int fd);
 int anv_gem_set_caching(struct anv_device *device, uint32_t gem_handle, 
uint32_t caching);
 int anv_gem_set_domain(struct anv_device *device, uint32_t gem_handle,
diff --git a/src/intel/vulkan/genX_query.c b/src/intel/vulkan/genX_query.c
index e35e9b85844..980c543460e 100644
--- a/src/intel/vulkan/genX_query.c
+++ b/src/intel/vulkan/genX_query.c
@@ -552,6 +552,21 @@ void genX(CmdWriteTimestamp)(
}
 }
 
+VkResult genX(QueryCurrentTimestampMESA)(
+   VkDevice _device,
+   uint64_t *timestamp)
+{
+   ANV_FROM_HANDLE(anv_device, device, _device);
+   int  ret;
+
+   /* XXX older kernels don't support this interface. */
+   ret = anv_gem_reg_read(device, TIMESTAMP | 1, timestamp);
+
+   if (ret != 0)
+  return VK_ERROR_DEVICE_LOST;
+   return VK_SUCCESS;
+}
+
 #if GEN_GEN > 7 || GEN_IS_HASWELL
 
 static uint32_t
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] Add (internal) MESA_query_timestamp extension to anv/radv

[Keith Packard]

This extension fetches the current GPU timestamp from the hardware,
just like the OpenGL API glGetInteger64v(GL_TIMESTAMP, )
function.

I need this to correlate GPU and CPU timestamps for the
GOOGLE_display_timing extension, but I think it will be useful for
applications as well.

I'm not sure this is exactly the API we need for this; it might be
better for it to return *two* timestamps, a GPU and a CPU one which
were as closely correlated as possible down in the kernel.

The kernel APIs that this calls on anv and radv don't do that, so I
didn't want to pretend to offer functionality I couldn't actually
supply.

Suggestions on what to do here are welcome!

-keith


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] vulkan: Define new VK_MESA_query_timestamp extension [v2]

[Keith Packard]

This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.

v2: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Add extension to list in alphabetical order

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 include/vulkan/vk_mesa_query_timestamp.h | 41 
 src/vulkan/registry/vk.xml   | 15 +
 2 files changed, 56 insertions(+)
 create mode 100644 include/vulkan/vk_mesa_query_timestamp.h

diff --git a/include/vulkan/vk_mesa_query_timestamp.h 
b/include/vulkan/vk_mesa_query_timestamp.h
new file mode 100644
index 000..4e0b50cb9cc
--- /dev/null
+++ b/include/vulkan/vk_mesa_query_timestamp.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright © 2018 Keith Packard
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#ifndef __VK_MESA_QUERY_TIMESTAMP_H__
+#define __VK_MESA_QUERY_TIMESTAMP_H__
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef VkResult (VKAPI_PTR *PFN_vkQueryCurrentTimestampMESA)(
+VkDevice device, uint64_t *timestamp);
+
+VKAPI_ATTR VkResult VKAPI_CALL vkQueryCurrentTimestampMESA(
+VkDevice device, uint64_t *timestamp);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __VK_MESA_QUERY_TIMESTAMP_H__ */
+
diff --git a/src/vulkan/registry/vk.xml b/src/vulkan/registry/vk.xml
index 7018bbe8421..3a5cecdc8e3 100644
--- a/src/vulkan/registry/vk.xml
+++ b/src/vulkan/registry/vk.xml
@@ -6102,6 +6102,11 @@ server.
 uint32_t maxDrawCount
 uint32_t stride
 
+
+VkResult 
vkQueryCurrentTimestampMESA
+VkDevice device
+uint64_t* pTimestamp
+
 
 
 
@@ -8826,5 +8831,15 @@ server.
 
 
 
+
+
+
+
+
+
+
 
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] radv: Add new VK_MESA_query_timestamp extension to radv driver

[Keith Packard]

This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to correlate GPU and CPU
timestamps.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_device.c  | 8 
 src/amd/vulkan/radv_extensions.py | 1 +
 src/amd/vulkan/radv_private.h | 1 +
 3 files changed, 10 insertions(+)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 62e1b9dba66..c552030491f 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4770,3 +4770,11 @@ radv_GetDeviceGroupPeerMemoryFeatures(
   VK_PEER_MEMORY_FEATURE_GENERIC_SRC_BIT |
   VK_PEER_MEMORY_FEATURE_GENERIC_DST_BIT;
 }
+
+VkResult radv_QueryCurrentTimestampMESA(VkDevice _device, uint64_t *timestamp)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+
+   *timestamp = device->ws->query_value(device->ws, RADEON_TIMESTAMP);
+   return VK_SUCCESS;
+}
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index ebc3f6bc2b5..008e5cfe960 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -107,6 +107,7 @@ EXTENSIONS = [
 Extension('VK_AMD_shader_core_properties',1, True),
 Extension('VK_AMD_shader_info',   1, True),
 Extension('VK_AMD_shader_trinary_minmax', 1, True),
+Extension('VK_MESA_query_timestamp',  1, True),
 ]
 
 class VkVersion:
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index f001b836c8f..a3e0a6f013c 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -75,6 +75,7 @@ typedef uint32_t xcb_window_t;
 #include 
 #include 
 #include 
+#include 
 
 #include "radv_entrypoints.h"
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] vulkan: add VK_EXT_display_control [v5]

[Keith Packard]

Jason Ekstrand  writes:

> That seems good to me.  Unless, of course, DPMS is something we expect to
> change over time somehow.  Then again, we don't handle that at all right
> now so meh.  Let's go with what you wrote above for now.

It's not even the dpms value, it's the dpms property itself, which
DRM never changes.

> They shouldn't be and that's why I'm a fan of making them asserts which get
> compiled out instead of actual checks.  Also, I find this pseudo reference
> counting to be somewhat confusing and adding asserts informs the reader of
> the assumptions made.

Ok, I've added this.

> What test suite?  Honestly, I know of no code anywhere that actually uses
> this API for anything other than VR headsets.
>
> I guess it's kind-of a question of how much effort we want to put into
> this.  One option would be to add VK_KHR_display support to vkcube and make
> it automatically show up on all your displays using hotplug events.
>
> If we're going to not care, returning VK_ERROR_FEATURE_NOT_PRESENT is
> probably the best thing to do since at least the app has feedback.

Not caring seems best to me -- the Vulkan display API isn't capable of
supporting a "real" window system; for that, you'd really want to use
DRM directly and create some way to share that with Vulkan like the
extension I wrote to pass the DRM master FD into the driver at init time.

> Awesome.  I think we're really close on this one.

I'll send out the current series and you can see if you like it.

-- 
-keith


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

Re: [PATCH 6/7] anv: add VK_EXT_display_control to anv driver [v2]

[Keith Packard]

Jason Ekstrand  writes:

> I believe that the WSI common code should be capable of fishing the
> instance allocator out of the wsi_display so we need only pass the
> allocator argument unmodified through to the core WSI code.  Make sense?

Thanks, I think I've sorted it out. I've pushed an updated series with
this change.

> Yeah, Vulkan allocator fishing is weird.

Allowing custom allocators is one of the bad parts of the Vulkan spec;
it will "never" get used, and the chances of it working correctly in any
driver are pretty small. But, we do what we can to implement it.

-- 
-keith


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

Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]

[Keith Packard]

Jason Ekstrand  writes:

> You can have a full reviewed-by

You're too kind :-)

-- 
-keith


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

Re: [PATCH 6/7] anv: add VK_EXT_display_control to anv driver [v2]

[Keith Packard]

Jason Ekstrand  writes:

>> +   if (allocator)
>> + alloc = allocator;
>> +   else
>> + alloc = >instance->alloc;
>>
>
> This is what vk_alloc2 is for. :-)
...
> And vk_free2
...
> This isn't needed if you're using vk_alloc2

Yeah, but I need to pass the allocator down to the wsi common code, and
that doesn't have any way to touch the device driver allocator
pointer. I bet I'm just missing something here. Help?

>> +
>> +   fence = vk_zalloc2(>alloc, allocator, sizeof (*fence), 8,
>> +  VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
>>
>
> Above you used vk_alloc and here you're using vk_zalloc.  Mind picking
> one?  I don't think zalloc is needed but it doesn't hurt so I don't care
> which.

Thanks. Existing code is using zalloc for fences; I'll use that everywhere.

> Indentation could be consistent between the two functions you add.  I don't
> care which style.

Sure; these function names are kinda long. I've wrapped the first call
after the (

> vk_free2?

I've had to compute 'alloc' to pass into wsi_common; I figured I might
as well use it.

-- 
-keith


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

Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]

[Keith Packard]

Jason Ekstrand  writes:

> I don't think I have any more comments on this patch.  It's gross but I
> think it should work.

I'll mark you down as 'Acked-by' then. Neither of us loves the
implementation; I'll see about creating the kernel infrastructure
necessary to supplant it.

-- 
-keith


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

Re: [PATCH 5/7] vulkan: add VK_EXT_display_control [v5]

[Keith Packard]

Jason Ekstrand  writes:


>> +  if (!prop)
>> + continue;
>> +  if (prop->flags & DRM_MODE_PROP_ENUM) {
>> + if (!strcmp(prop->name, "DPMS"))
>> +connector->dpms_property = drm_connector->props[p];
>>
>
> break?

Not break; I need to free the property. However, an early exit from the
loop seems reasonable. How about:

   for (int p = 0; connector->dpms_property == 0 && p < 
drm_connector->count_props; p++) {

This skips the whole sequence if the property has already been found, or
stops as soon as it has.

>> +static bool
>> +wsi_display_fence_wait(struct wsi_fence *fence_wsi,
>> +   bool absolute,
>> +   uint64_t timeout)
>>
>
> Would it make more sense for this function to return a VkResult?  Then you
> could tell the difference between success, timeout, and some other
> failure.  I guess the only other thing to return would be
> VK_ERROR_DEVICE_LOST which seems pretty harsh but, then again,
> pthread_timed_wait just failed so that's also really bad.

That's a good idea. The boolean return is pretty ambiguous. I copied
that from the radv internal fence API, which could also benefit from
this change. I've changed the API and adjusted the anv and radv code to
match. It reads a lot better now.

>> +   if (!absolute)
>> +  timeout = wsi_rel_to_abs_time(timeout);
>>
>
> Are relative times really useful?  I suspect it doesn't save you more than
> a couple of lines and it makes the interface weird.

No. Relative timeouts aren't actually used anywhere either. I've removed them.

I did catch a mistake in the anv driver looking at this -- the !waitAll
code wasn't bothering to check the fences if the time had already
passed, so an application polling would never catch the fences being
ready. I've changed the while (current_time < timeout) {} to a do {}
while (current_time < timeout) loop.

>> +static void
>> +wsi_display_fence_destroy(struct wsi_fence *fence_wsi)
>> +{
>> +   struct wsi_display_fence *fence = (struct wsi_display_fence *)
>> fence_wsi;
>> +
>>
>
> An assert(!fence->destroyed) in here might be useful to guard against
> double-frees.

Sure. I was under the impression that application bugs weren't supposed
to be rigorously checked in the implementation though? When should I be
checking API usage issues?

>> +  if (!ret)
>> + return VK_SUCCESS;
>> +
>> +  if (errno != ENOMEM) {
>> + wsi_display_debug("queue vblank event %lu failed\n",
>> fence->sequence);
>> + struct timespec delay = {
>> +.tv_sec = 0,
>> +.tv_nsec = 1ull,
>> + };
>> + nanosleep(, NULL);
>> + return VK_ERROR_OUT_OF_HOST_MEMORY;
>>
>
> Why are we sleeping for 0.1s before we return?  That seems fishy.

Yeah, the kernel API is not great. There's a finite queue which can be
consumed with both flip events and vblank wait events. If that fills,
we'll get an error back. The only way to empty it is to have some events
get delivered, and those will only get delivered after a vblank happens.

It's an application bug that triggers this -- requesting too many vblank
events. Throttling the application so it doesn't just spin makes it
possible to stop it.

>> +  pthread_mutex_lock(>wait_mutex);
>> +  ret = wsi_display_wait_for_event(wsi, wsi_rel_to_abs_time(
>> 1ull));
>>
>
> What's with the magic number?

0.1s -- a value which is longer than any display time, but short enough
to catch things like DPMS off or VT switch without unduly delaying the
application.

>> +VkResult
>> +wsi_register_device_event(VkDevice device,
>> +  struct wsi_device *wsi_device,
>> +  const VkDeviceEventInfoEXT *device_event_info,
>> +  const VkAllocationCallbacks *allocator,
>> +  struct wsi_fence **fence_p)
>> +{
>> +   return VK_ERROR_FEATURE_NOT_PRESENT;
>>
>
> I don't think we're allowed to just not implemnet this.  At the very least,
> we should accept the event and never trigger it.  Better would be to
> actually wire up hotplug detection.  I have no idea how insane that would
> be to do. :-P

It's not a big deal to implement, I just didn't need it. I suppose the
test suite will be unhappy with this? Let me know if you want to insist
on having it implemented.

> Both RegisterDeviceEvent and RegisterDisplayEvent say they can only return
> VK_SUCCESS.  We should submit a MR against the extensions to also allow
> OUT_OF_HOST_MEMORY at the very least.

There's already weasel words in the section on memory allocation that
says the command must generate VK_ERROR_OUT_OF_HOST_MEMORY when
allocation fails. But, it would be nice for these APIs to be documented
as possibly returning that value.

> Any particular reason to put these all the way down here?  I think my
> preference would be to move wsi_display_fence_event_handler to right after
> wsi_display_fence_check_free and give it a predeclaration 

Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]

[Keith Packard]

Jason Ekstrand  writes:

> I suppose we probably shouldn't worry about current_time being greater than
> INT64_MAX?  I guess if that happens we have pretty big problems...

Nope, we've already given up on that working -- it's a couple hundred
years of system uptime. Neither of us have any concerns in this area.

>>timeout = MIN2(max_timeout, timeout);
>>
>>return (current_time + timeout);
>> }
>>
>
> Yeah, I think that's better.

Cool. I'll wait for further review :-)

-- 
-keith


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

Re: [PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]

[Keith Packard]

Jason Ekstrand  writes:

> I still don't really like this but I agree that this code really should not
> be getting hit very often so it's probably not too bad.  Maybe one day
> we'll be able to drop the non-syncobj paths entirely.  Wouldn't that be
> nice.

I agree. What I want to have is kernel-side syncobj support for all of
the WSI fences that we need here.

I thought about using syncobjs and signaling them from user-space, but
realized that we couldn't eliminate the non-syncobj path quite yet as
that requires a new enough kernel. And, if we want to get to
kernel-native WSI syncobjs, that would mean we'd eventually have three
code paths. I think it's better to have one 'legacy' path, which works
on all kernels, and then one 'modern' path which does what we want.

> In the mean time, this is probably fine.  I did see one issue below
> with time conversions that should be fixed though.

Always a hard thing to get right.

>> +static uint64_t anv_get_absolute_timeout(uint64_t timeout)
>> +{
>> +   if (timeout == 0)
>> +  return 0;
>> +   uint64_t current_time = gettime_ns();
>> +
>> +   timeout = MIN2(INT64_MAX - current_time, timeout);
>> +
>> +   return (current_time + timeout);
>> +}
>>
>
> This does not have the same behavior as the code it replaces.  In
> particular, the old code saturates at INT64_MAX whereas this code does not
> do so properly anymore.  If UINT64_MAX gets passed into timeout, I believe
> that will be implicitly casted to signed and the MIN will yield -1 which
> gets casted back to unsigned and you get UINT64_MAX again.

It won't not get implicitly casted to signed; the implicit cast works
the other way where  OP  implicitly casts the 
operand to unsigned for types of the same 'rank' (where 'rank' is not
quite equivalent to size). Here's a fine article on this:

https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules

However, this is a rather obscure part of the ISO standard, and I don't
think we should expect that people reading the code know it well. Adding
a cast to make it clear what we want is a good idea. How about this?

static uint64_t anv_get_absolute_timeout(uint64_t timeout)
{
   if (timeout == 0)
  return 0;
   uint64_t current_time = gettime_ns();
   uint64_t max_timeout = (uint64_t) INT64_MAX - current_time;

   timeout = MIN2(max_timeout, timeout);

   return (current_time + timeout);
}

> This is a problem because the value we pass into the kernel ioctls is
> signed.  The behavior of the kernel *should* be infinite when timeout
> < 0 but, on some older kernels, -1 is treated as 0 and you get no
> timeout.

Yeah, we definitely want to cap the values to INT64_MAX.

>> -  else if (current_ns + _timeout > INT64_MAX)
>>
>
> I suspect we need to cast INT64_MAX to a uint64_t here to ensure we don't
> accidentally get an implicit conversion to signed.

Again, it's not necessary given the C conversion rules, but it is a good
way to clarify the intent.

-- 
-keith


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

Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values

[Keith Packard]

Jason Ekstrand  writes:

> Looks good.  Passes the CTS.  Push it!

All done. Now just two more series to go in this set :-)

-- 
-keith


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

Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values

[Keith Packard]

Jason Ekstrand  writes:

>  1) We weren't setting planeReorderPossible at all and we were using 0
> instead of VK_FALSE (they're the same but we should use the enum) for
> persistentContent
>  2) We weren't advertising disconnected connectors via
> GetPhysicalDeviceDisplayProperties but were returning them from
> GetPhysicalDeviceDisplayPlaneProperties.
>  3) We weren't setting result if the condition variable failed to
> initialize (thanks GCC!)
> ​
> There is one outstanding issue that the CTS is complaining about, namely
> that you can't create modes.  It tests that mode creation fails for a mode
> with a zero width, height, or refresh rate and that's all fine.  It then
> tries to re-create one of the modes that we've returned to it in
> GetDisplayModeProperties and assumes that it will work.  We should probably
> at least make sure that works by walking the list and looking for a mode
> that matches the requested one and returning it.  I don't think anything
> actually requires us to return a unique pointer so it can be a search
> instead of a create.

And that seems to at least make CTS happy. I've merged your fixes into
the first patch, added support for vkCreateDisplayModeKHR, rebased to
master and pushed the results to my repository.

It looks like we're done here but I'll wait until I hear from you before
pushing to master in case you've got additional concerns.

-- 
-keith


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

Re: [PATCH 1/7] vulkan: Add VK_EXT_display_surface_counter [v4]

[Keith Packard]

Jason Ekstrand  writes:

> I really don't like adding a third get_capabilities hook.

Yeah, but this new function takes a different struct parameter which has
a different (but not strict superset) of contents from either of the
existing functions. Annoying.

> An alternative way to do this would be to add a pseud-extension which
> allows you do get he extra bit of data with a chain-in on
> vkGetSurfaceCapabilities2KHR.  I sent two patches which do just that.
> If you like them, I'm happy do do the reabase for you if you'd like.

I'll review that when I have some time Monday.

-- 
-keith


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

[PATCH 0/7] vulkan: Add VK_EXT_display_control and VK_EXT_display_surface_counter

[Keith Packard]

Here's a couple of reasonably straightforward extensions implemented
for both anv and radv drivers.

VK_EXT_display_surface_counter is a very simple extension which
adds an API, vkGetPhysicalSurfaceCapabilities2EXT, to extend the
existing vkGetPhysicalDeviceSurfaceCapabilitiesKHR and
vkGetPhysicalDeviceSurfaceCapablities2KHR interfaces.

The new interface uses a slightly different structure that includes a
new flags word, "supportedSurfaceCounters". This new field describes
the counters available from the underlying WSI layer. As this
extension doesn't provide any counters itself, each WSI layer
initializes this to zero for now.

VK_EXT_display_control is an extension specific to display surfaces
(those created via the KHR_display extension). This extension adds
DPMS support and fences which signal when vblank or monitor hotplug
events happen.

I've implemented the DPMS support and the vblank fence stuff; I
haven't bothered hooking up the monitor hotplug bits, although it
would be fairly simple.

To make the fences work on anv, I had to refactor the existing fence
waiting code to add the ability to spin waiting for any of a set of
heterogeneous fences (a mixture of syncobj and bo fences) to become
ready; this mirrors the same functionality in the radv driver,
although anv hadn't needed it before as it only supported homogenous
fence types (either all syncobj or all bo).

I've created a separate patch for this refactoring to try and reduce
the difficulty in reviewing that part.

-keith


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] anv: add VK_EXT_display_control to anv driver [v2]

[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.

v2: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Add extension to list in alphabetical order

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_private.h |  4 ++
 src/intel/vulkan/anv_queue.c   | 22 +++
 src/intel/vulkan/anv_wsi_display.c | 97 ++
 4 files changed, 124 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 68e545a40f8..8c010e9280b 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -111,6 +111,7 @@ EXTENSIONS = [
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_display_control',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_global_priority',   1,
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index fb91bc33046..c81885979ad 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2133,6 +2133,7 @@ enum anv_fence_type {
ANV_FENCE_TYPE_NONE = 0,
ANV_FENCE_TYPE_BO,
ANV_FENCE_TYPE_SYNCOBJ,
+   ANV_FENCE_TYPE_WSI,
 };
 
 enum anv_bo_fence_state {
@@ -2167,6 +2168,9 @@ struct anv_fence_impl {
 
   /** DRM syncobj handle for syncobj-based fences */
   uint32_t syncobj;
+
+  /** WSI fence */
+  struct wsi_fence *fence_wsi;
};
 };
 
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 8df99c84549..073e65acf5e 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -324,6 +324,10 @@ anv_fence_impl_cleanup(struct anv_device *device,
   anv_gem_syncobj_destroy(device, impl->syncobj);
   break;
 
+   case ANV_FENCE_TYPE_WSI:
+  impl->fence_wsi->destroy(impl->fence_wsi);
+  break;
+
default:
   unreachable("Invalid fence type");
}
@@ -672,6 +676,21 @@ done:
return result;
 }
 
+static VkResult
+anv_wait_for_wsi_fence(struct anv_device *device,
+   const VkFence _fence,
+   uint64_t abs_timeout)
+{
+   ANV_FROM_HANDLE(anv_fence, fence, _fence);
+
+   struct anv_fence_impl *impl = >permanent;
+   bool expired = impl->fence_wsi->wait(impl->fence_wsi, true, abs_timeout);
+
+   if (!expired)
+  return VK_TIMEOUT;
+   return VK_SUCCESS;
+}
+
 static VkResult
 anv_wait_for_fences(struct anv_device *device,
 uint32_t fenceCount,
@@ -694,6 +713,9 @@ anv_wait_for_fences(struct anv_device *device,
 result = anv_wait_for_syncobj_fences(device, 1, [i],
  true, abs_timeout);
 break;
+ case ANV_FENCE_TYPE_WSI:
+result = anv_wait_for_wsi_fence(device, pFences[i], abs_timeout);
+break;
  case ANV_FENCE_TYPE_NONE:
 result = VK_SUCCESS;
 break;
diff --git a/src/intel/vulkan/anv_wsi_display.c 
b/src/intel/vulkan/anv_wsi_display.c
index f749a8d98f7..cd736bcdd74 100644
--- a/src/intel/vulkan/anv_wsi_display.c
+++ b/src/intel/vulkan/anv_wsi_display.c
@@ -168,3 +168,100 @@ anv_GetRandROutputDisplayEXT(VkPhysicalDevice  
physical_device,
display);
 }
 #endif /* VK_USE_PLATFORM_XLIB_XRANDR_EXT */
+
+/* VK_EXT_display_control */
+
+VkResult
+anv_DisplayPowerControlEXT(VkDevice_device,
+VkDisplayKHRdisplay,
+const VkDisplayPowerInfoEXT *display_power_info)
+{
+   ANV_FROM_HANDLE(anv_device, device, _device);
+
+   return wsi_display_power_control(
+  _device, >instance->physicalDevice.wsi_device,
+  display, display_power_info);
+}
+
+VkResult
+anv_RegisterDeviceEventEXT(VkDevice _device,
+const VkDeviceEventInfoEXT *device_event_info,
+const VkAllocationCallbacks *allocator,
+VkFence *_fence)
+{
+   ANV_FROM_HANDLE(anv_device, device, _device);
+   const VkAllocationCallbacks *alloc;
+   struct anv_fence *fence;
+   VkResult ret;
+
+   if (allocator)
+ alloc = allocator;
+   else
+ alloc = >instance->alloc;
+

[PATCH 7/7] radv: add VK_EXT_display_control to radv driver [v3]

[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.

v2:
Rework fence integration into the driver so that waiting for
any of a mixture of fence types (wsi, driver or syncobjs)
causes the driver to poll, while a list of just syncobjs or
just driver fences will block. When we get syncobjs for wsi
fences, we'll adapt to use them.

v3: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_device.c  |  68 +-
 src/amd/vulkan/radv_extensions.py |   1 +
 src/amd/vulkan/radv_private.h |   1 +
 src/amd/vulkan/radv_wsi_display.c | 113 ++
 4 files changed, 167 insertions(+), 16 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 59ee503c8c2..fd80db1c9b4 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -3240,6 +3240,7 @@ VkResult radv_CreateFence(
if (!fence)
return vk_error(device->instance, VK_ERROR_OUT_OF_HOST_MEMORY);
 
+   fence->fence_wsi = NULL;
fence->submitted = false;
fence->signalled = !!(pCreateInfo->flags & 
VK_FENCE_CREATE_SIGNALED_BIT);
fence->temp_syncobj = 0;
@@ -3284,6 +3285,8 @@ void radv_DestroyFence(
device->ws->destroy_syncobj(device->ws, fence->syncobj);
if (fence->fence)
device->ws->destroy_fence(fence->fence);
+   if (fence->fence_wsi)
+   fence->fence_wsi->destroy(fence->fence_wsi);
vk_free2(>alloc, pAllocator, fence);
 }
 
@@ -3309,7 +3312,19 @@ static bool radv_all_fences_plain_and_submitted(uint32_t 
fenceCount, const VkFen
 {
for (uint32_t i = 0; i < fenceCount; ++i) {
RADV_FROM_HANDLE(radv_fence, fence, pFences[i]);
-   if (fence->syncobj || fence->temp_syncobj || (!fence->signalled 
&& !fence->submitted))
+   if (fence->fence == NULL || fence->syncobj ||
+   fence->temp_syncobj ||
+   (!fence->signalled && !fence->submitted))
+   return false;
+   }
+   return true;
+}
+
+static bool radv_all_fences_syncobj(uint32_t fenceCount, const VkFence 
*pFences)
+{
+   for (uint32_t i = 0; i < fenceCount; ++i) {
+   RADV_FROM_HANDLE(radv_fence, fence, pFences[i]);
+   if (fence->syncobj == 0 && fence->temp_syncobj == 0)
return false;
}
return true;
@@ -3325,7 +3340,9 @@ VkResult radv_WaitForFences(
RADV_FROM_HANDLE(radv_device, device, _device);
timeout = radv_get_absolute_timeout(timeout);
 
-   if (device->always_use_syncobj) {
+   if (device->always_use_syncobj &&
+   radv_all_fences_syncobj(fenceCount, pFences))
+   {
uint32_t *handles = malloc(sizeof(uint32_t) * fenceCount);
if (!handles)
return vk_error(device->instance, 
VK_ERROR_OUT_OF_HOST_MEMORY);
@@ -3395,21 +3412,35 @@ VkResult radv_WaitForFences(
if (fence->signalled)
continue;
 
-   if (!fence->submitted) {
-   while(radv_get_current_time() <= timeout && 
!fence->submitted)
-   /* Do nothing */;
+   if (fence->fence) {
+   if (!fence->submitted) {
+   while(radv_get_current_time() <= timeout &&
+ !fence->submitted)
+   /* Do nothing */;
 
-   if (!fence->submitted)
-   return VK_TIMEOUT;
+   if (!fence->submitted)
+   return VK_TIMEOUT;
 
-   /* Recheck as it may have been set by submitting 
operations. */
-   if (fence->signalled)
-   continue;
+   /* Recheck as it may have been set by
+* submitting operations. */
+
+   if (fence->signalled)
+   continue;
+   }
+
+   expired = device->ws->fence_wait(device->ws,
+fence->fence,
+true, timeout);
+   

[PATCH 2/7] anv: Add VK_EXT_display_surface_counter to anv driver [v2]

[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:
Add extension to list in alphabetical order

Suggested-by:  Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_wsi.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 4bffbcb5a2a..68e545a40f8 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -111,6 +111,7 @@ EXTENSIONS = [
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_global_priority',   1,
   'device->has_context_priority'),
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index a7efb1416fa..1403601e9c0 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -120,6 +120,18 @@ VkResult anv_GetPhysicalDeviceSurfaceCapabilities2KHR(
pSurfaceCapabilities);
 }
 
+VkResult anv_GetPhysicalDeviceSurfaceCapabilities2EXT(
+   VkPhysicalDevicephysicalDevice,
+   VkSurfaceKHRsurface,
+   VkSurfaceCapabilities2EXT*  pSurfaceCapabilities)
+{
+   ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_surface_capabilities2ext(>wsi_device,
+  surface,
+  pSurfaceCapabilities);
+}
+
 VkResult anv_GetPhysicalDeviceSurfaceFormatsKHR(
 VkPhysicalDevicephysicalDevice,
 VkSurfaceKHRsurface,
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] anv: Support wait for heterogeneous list of fences [v2]

[Keith Packard]

Handle the case where the set of fences to wait for is not all of the
same type by either waiting for them sequentially (waitAll), or
polling them until the timer has expired (!waitAll). We hope the
latter case is not common.

While the current code makes sure that it always has fences of only
one type, that will not be true when we add WSI fences. Split out this
refactoring to make merging that clearer.

v2: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/intel/vulkan/anv_queue.c | 105 +--
 1 file changed, 88 insertions(+), 17 deletions(-)

diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 6fe04a0a19d..8df99c84549 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -459,12 +459,32 @@ gettime_ns(void)
return (uint64_t)current.tv_sec * NSEC_PER_SEC + current.tv_nsec;
 }
 
+static uint64_t anv_get_absolute_timeout(uint64_t timeout)
+{
+   if (timeout == 0)
+  return 0;
+   uint64_t current_time = gettime_ns();
+
+   timeout = MIN2(INT64_MAX - current_time, timeout);
+
+   return (current_time + timeout);
+}
+
+static int64_t anv_get_relative_timeout(uint64_t abs_timeout)
+{
+   uint64_t now = gettime_ns();
+
+   if (abs_timeout < now)
+  return 0;
+   return abs_timeout - now;
+}
+
 static VkResult
 anv_wait_for_syncobj_fences(struct anv_device *device,
 uint32_t fenceCount,
 const VkFence *pFences,
 bool waitAll,
-uint64_t _timeout)
+uint64_t abs_timeout_ns)
 {
uint32_t *syncobjs = vk_zalloc(>alloc,
   sizeof(*syncobjs) * fenceCount, 8,
@@ -484,19 +504,6 @@ anv_wait_for_syncobj_fences(struct anv_device *device,
   syncobjs[i] = impl->syncobj;
}
 
-   int64_t abs_timeout_ns = 0;
-   if (_timeout > 0) {
-  uint64_t current_ns = gettime_ns();
-
-  /* Add but saturate to INT32_MAX */
-  if (current_ns + _timeout < current_ns)
- abs_timeout_ns = INT64_MAX;
-  else if (current_ns + _timeout > INT64_MAX)
- abs_timeout_ns = INT64_MAX;
-  else
- abs_timeout_ns = current_ns + _timeout;
-   }
-
/* The gem_syncobj_wait ioctl may return early due to an inherent
 * limitation in the way it computes timeouts.  Loop until we've actually
 * passed the timeout.
@@ -665,6 +672,67 @@ done:
return result;
 }
 
+static VkResult
+anv_wait_for_fences(struct anv_device *device,
+uint32_t fenceCount,
+const VkFence *pFences,
+bool waitAll,
+uint64_t abs_timeout)
+{
+   VkResult result = VK_SUCCESS;
+
+   if (fenceCount <= 1 || waitAll) {
+  for (uint32_t i = 0; i < fenceCount; i++) {
+ ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
+ switch (fence->permanent.type) {
+ case ANV_FENCE_TYPE_BO:
+result = anv_wait_for_bo_fences(
+   device, 1, [i], true,
+   anv_get_relative_timeout(abs_timeout));
+break;
+ case ANV_FENCE_TYPE_SYNCOBJ:
+result = anv_wait_for_syncobj_fences(device, 1, [i],
+ true, abs_timeout);
+break;
+ case ANV_FENCE_TYPE_NONE:
+result = VK_SUCCESS;
+break;
+ }
+ if (result != VK_SUCCESS)
+return result;
+  }
+   } else {
+  while (gettime_ns() < abs_timeout) {
+ for (uint32_t i = 0; i < fenceCount; i++) {
+if (anv_wait_for_fences(device, 1, [i], true, 0) == 
VK_SUCCESS)
+   return VK_SUCCESS;
+ }
+  }
+  result = VK_TIMEOUT;
+   }
+   return result;
+}
+
+static bool anv_all_fences_syncobj(uint32_t fenceCount, const VkFence *pFences)
+{
+   for (uint32_t i = 0; i < fenceCount; ++i) {
+  ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
+  if (fence->permanent.type != ANV_FENCE_TYPE_SYNCOBJ)
+ return false;
+   }
+   return true;
+}
+
+static bool anv_all_fences_bo(uint32_t fenceCount, const VkFence *pFences)
+{
+   for (uint32_t i = 0; i < fenceCount; ++i) {
+  ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
+  if (fence->permanent.type != ANV_FENCE_TYPE_BO)
+ return false;
+   }
+   return true;
+}
+
 VkResult anv_WaitForFences(
 VkDevice_device,
 uint32_tfenceCount,
@@ -677,12 +745,15 @@ VkResult anv_WaitForFences(
if (unlikely(device->lost))
   return VK_ERROR_DEVICE_LOST;
 
-   if (device->instance->physicalDevice.has_syncobj_wait) {
+   if (anv_all_fences_syncobj(fenceCount,

[PATCH 1/7] vulkan: Add VK_EXT_display_surface_counter [v4]

[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

v3: Fix wayland WSI, regularize spelling

Misspelled 'surface' in get_capabilities2ext
Remove extra _ from get_capabilities_2ext in a couple of places

v4: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace
between types and names. Wrap lines to 80 columns.

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/vulkan/wsi/wsi_common.c | 12 
 src/vulkan/wsi/wsi_common.h |  6 ++
 src/vulkan/wsi/wsi_common_display.c | 27 +++
 src/vulkan/wsi/wsi_common_private.h |  3 +++
 src/vulkan/wsi/wsi_common_wayland.c | 27 +++
 src/vulkan/wsi/wsi_common_x11.c | 27 +++
 6 files changed, 102 insertions(+)

diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 142c5d8fe58..91d0b72e1ba 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -710,6 +710,18 @@ 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 61b1de59d7f..054aad23c1c 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -178,6 +178,12 @@ 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 e140e71c518..504f7741d73 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -641,6 +641,32 @@ wsi_display_surface_get_capabilities2(VkIcdSurfaceBase 
*icd_surface,
>surfaceCapabilities);
 }
 
+static VkResult
+wsi_display_surface_get_capabilities2ext(VkIcdSurfaceBase *icd_surface,
+  VkSurfaceCapabilities2EXT *caps)
+{
+   VkSurfaceCapabilitiesKHR khr_caps;
+   VkResult ret;
+
+   assert(caps->sType == VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT);
+   ret = wsi_display_surface_get_capabilities(icd_surface, _caps);
+   if (ret)
+  return ret;
+
+   caps->minImageCount = khr_caps.minImageCount;
+   caps->maxImageCount = khr_caps.maxImageCount;
+   caps->currentExtent = khr_caps.currentExtent;
+   caps->minImageExtent = khr_caps.minImageExtent;
+   caps->maxImageExtent = khr_caps.maxImageExtent;
+   caps->maxImageArrayLayers = khr_caps.maxImageArrayLayers;
+   caps->supportedTransforms = khr_caps.supportedTransforms;
+   caps->currentTransform = khr_caps.currentTransform;
+   caps->supportedCompositeAlpha = khr_caps.supportedCompositeAlpha;
+   caps->supportedUsageFlags = khr_caps.supportedUsageFlags;
+   caps->supportedSurfaceCounters = 0;
+   return ret;
+}
+
 static const struct {
VkFormat format;
uint32_t drm_format;
@@ -1393,6 +1419,7 @@ wsi_display_init_wsi(struct wsi_device *wsi_device,
wsi->base.get_support = wsi_display_surface_get_support;
wsi->base.get_capabilities = wsi_display_surface_get_capabilities;
wsi->base.get_capabilities2 = wsi_display_surface_get_capabilities2;
+   wsi->base.get_capabilities2ext = wsi_display_surface_get_capabilities2ext;
wsi->base.get_formats = wsi_display_surface_get_formats;
wsi->base.get_formats2 = wsi_display_surface_get_formats2;
wsi->base.get_present_modes = wsi_display_surface_get_present_modes;
diff --git a/src/vulkan/wsi/wsi_common_private.h 
b/src/vulkan/wsi/wsi_common_private.h
index 3d502b9fc9d..b97d2d8ba06 100644
--- a/src/vulkan/wsi/wsi_common_private.h
+++ b/src/vulkan/wsi/wsi_common_private.h
@@ -10

[PATCH 5/7] vulkan: add VK_EXT_display_control [v5]

[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.

v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
been removed from the proposed kernel API.

Add NULL parameter to drmCrtcQueueSequence ioctl as we
don't care what sequence the event was actually queued to.

v3: Adapt to pthread clock switch to MONOTONIC

v4: Fix scope for wsi_display_mode andwsi_display_connector allocs

Suggested-by: Jason Ekstrand 

v5: Adopt Jason Ekstrand's coding conventions

Declare variables at first use, eliminate extra whitespace between
types and names. Wrap lines to 80 columns.

Use wsi_rel_to_abs_time helper function to convert relative
timeouts to absolute timeouts without causing overflow.

Suggested-by: Jason Ekstrand 

Signed-off-by: Keith Packard 
---
 src/vulkan/wsi/wsi_common.h |  10 +
 src/vulkan/wsi/wsi_common_display.c | 307 +++-
 src/vulkan/wsi/wsi_common_display.h |  29 +++
 3 files changed, 345 insertions(+), 1 deletion(-)

diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 054aad23c1c..081fe1dcf8d 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -66,6 +66,16 @@ struct wsi_format_modifier_properties_list {
struct wsi_format_modifier_properties *modifier_properties;
 };
 
+struct wsi_fence {
+   VkDevice device;
+   const struct wsi_device  *wsi_device;
+   VkDisplayKHR display;
+   const VkAllocationCallbacks  *alloc;
+   bool (*wait)(struct wsi_fence *fence,
+bool absolute, uint64_t timeout);
+   void (*destroy)(struct wsi_fence *fence);
+};
+
 struct wsi_interface;
 
 #define VK_ICD_WSI_PLATFORM_MAX (VK_ICD_WSI_PLATFORM_DISPLAY + 1)
diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index 504f7741d73..40eaa6a322e 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -79,6 +79,7 @@ typedef struct wsi_display_connector {
struct list_head display_modes;
wsi_display_mode *current_mode;
drmModeModeInfo  current_drm_mode;
+   uint32_t dpms_property;
 #ifdef VK_USE_PLATFORM_XLIB_XRANDR_EXT
xcb_randr_output_t   output;
 #endif
@@ -132,6 +133,15 @@ struct wsi_display_swapchain {
struct wsi_display_image images[0];
 };
 
+struct wsi_display_fence {
+   struct wsi_fence base;
+   bool event_received;
+   bool destroyed;
+   uint64_t sequence;
+};
+
+static uint64_t fence_sequence;
+
 ICD_DEFINE_NONDISP_HANDLE_CASTS(wsi_display_mode, VkDisplayModeKHR)
 ICD_DEFINE_NONDISP_HANDLE_CASTS(wsi_display_connector, VkDisplayKHR)
 
@@ -307,6 +317,19 @@ wsi_display_get_connector(struct wsi_device *wsi_device,
 
connector->connected = drm_connector->connection != DRM_MODE_DISCONNECTED;
 
+   /* Look for a DPMS property */
+   for (int p = 0; p < drm_connector->count_props; p++) {
+  drmModePropertyPtr prop = drmModeGetProperty(wsi->fd,
+   drm_connector->props[p]);
+  if (!prop)
+ continue;
+  if (prop->flags & DRM_MODE_PROP_ENUM) {
+ if (!strcmp(prop->name, "DPMS"))
+connector->dpms_property = drm_connector->props[p];
+  }
+  drmModeFreeProperty(prop);
+   }
+
/* Mark all connector modes as invalid */
wsi_display_invalidate_connector_modes(wsi_device, connector);
 
@@ -663,7 +686,7 @@ wsi_display_surface_get_capabilities2ext(VkIcdSurfaceBase 
*icd_surface,
caps->currentTransform = khr_caps.currentTransform;
caps->supportedCompositeAlpha = khr_caps.supportedCompositeAlpha;
caps->supportedUsageFlags = khr_caps.supportedUsageFlags;
-   caps->supportedSurfaceCounters = 0;
+   caps->supportedSurfaceCounters = VK_SURFACE_COUNTER_VBLANK_EXT;
return ret;
 }
 
@@ -896,12 +919,21 @@ static void wsi_display_page_flip_handler(int fd,
wsi_display_page_flip_handler2(fd, frame, sec, usec, 0, data);
 }
 
+static void wsi_display_vblank_handler(int fd, unsigned int frame,
+   unsigned int sec, unsigned int usec,
+   void *data);
+
+static void wsi_display_sequence_handler(int fd, uint64_t frame,
+ uint64_t ns, uint64_t user_data);
+
 static drmEventContext event_context = {
.version = DRM_EVENT_CONTEXT_VERSION,
.page_flip_handler = wsi_display_page_flip_handler,
 #if DRM_EVENT_CONTEXT_VERSION >= 3
.page_flip_handler2 = wsi_display_page_flip_handler2,
 #endif
+   .vblank_handler = wsi_display_vblank_handler,
+   .

[PATCH 3/7] radv: Add VK_EXT_display_surface_counter to radv driver

[Keith Packard]

This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.

Signed-off-by: Keith Packard 
---
 src/amd/vulkan/radv_extensions.py |  1 +
 src/amd/vulkan/radv_wsi.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 65ce7349016..601a345b114 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -89,6 +89,7 @@ EXTENSIONS = [
 Extension('VK_KHR_display',  23, 
'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_EXT_debug_report',  9, True),
 Extension('VK_EXT_depth_range_unrestricted',  1, True),
 Extension('VK_EXT_descriptor_indexing',   2, True),
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 2840b666727..20484177135 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(>wsi_device,
+  surface,
+  pSurfaceCapabilities);
+}
+
 VkResult radv_GetPhysicalDeviceSurfaceFormatsKHR(
VkPhysicalDevicephysicalDevice,
VkSurfaceKHRsurface,
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [PATCH] wsi_common_display: Deal with vscan values

[Keith Packard]

Jason Ekstrand  writes:

> Looks good to me.  With this properly sprinkled on the appropriate patches,
> the entire series is
>
> Reviewed-by: Jason Ekstrand 

Thanks so much! I've rebased the series onto current master and pushed
it back to my gitlab repo here

https://gitlab.freedesktop.org/keithp/mesa/tree/drm-lease

I'll be doing testing tomorrow morning, and if it all looks good on both
anv and radv, I'll get it merged and pushed to master.

Now to get the next series ready for review :-)


-- 
-keith


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

[PATCH] wsi_common_display: Deal with vscan values

[Keith Packard]

We sorted out what 'vscan' means and are trying to use it correctly.

vscan = 0 is the same as vscan = 1, which is slightly annoying; we use
MAX2(vscan, 1) everywhere.

randr doesn't pass vscan at all, so we set wsi mode vscan = 0.

The doublescan flag doubles the vscan value, so we don't need to deal
with that separately, we can just compare flags normally.

Signed-off-by: Keith Packard 
---
 src/vulkan/wsi/wsi_common_display.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index c7f794a0eff..de1c1826bd2 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -149,7 +149,7 @@ wsi_display_mode_matches_drm(wsi_display_mode *wsi,
   wsi->vsync_start == drm->vsync_start &&
   wsi->vsync_end == drm->vsync_end &&
   wsi->vtotal == drm->vtotal &&
-  wsi->vscan == drm->vscan &&
+  MAX2(wsi->vscan, 1) == MAX2(drm->vscan, 1) &&
   wsi->flags == drm->flags;
 }
 
@@ -158,7 +158,7 @@ wsi_display_mode_refresh(struct wsi_display_mode *wsi)
 {
return (double) wsi->clock * 1000.0 / ((double) wsi->htotal *
   (double) wsi->vtotal *
-  (double) (wsi->vscan + 1));
+  (double) MAX2(wsi->vscan, 1));
 }
 
 static uint64_t wsi_get_current_monotonic(void)
@@ -1657,6 +1657,7 @@ wsi_display_mode_matches_x(struct wsi_display_mode *wsi,
   wsi->vsync_start == xcb->vsync_start &&
   wsi->vsync_end == xcb->vsync_end &&
   wsi->vtotal == xcb->vtotal &&
+  wsi->vscan <= 1 && 
   wsi->flags == xcb->mode_flags;
 }
 
@@ -1707,8 +1708,6 @@ wsi_display_register_x_mode(struct wsi_device *wsi_device,
display_mode->vsync_end = x_mode->vsync_end;
display_mode->vtotal = x_mode->vtotal;
display_mode->vscan = 0;
-   if (x_mode->mode_flags & XCB_RANDR_MODE_FLAG_DOUBLE_SCAN)
-  display_mode->vscan = 1;
display_mode->flags = x_mode->mode_flags;
 
list_addtail(_mode->list, >display_modes);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"

[Keith Packard]

Eric Anholt  writes:

> Just wait for all tasks to complete when any object is freed?  That's
> going to be bad for performance.  Or are you saying that you already
> have the connection between the task and its objects (and, if so, why
> aren't you just doing refcounting correctly through that path?)

How about wait on close of the DRM device?

-- 
-keith


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

Re: RFC for a render API to support adaptive sync and VRR

[Keith Packard]

Michel Dänzer  writes:

> Time-based presentation seems to be the right approach for preventing
> micro-stutter in games as well, Croteam developers have been researching
> this.

Both the Vulkan GOOGLE_display_timing extension and X11 Present
extension offer the ability to specify the desired display time in
seconds.

Similarly, I'd suggest that the min/max display refresh rate values be
advertised as time between frames rather than frames per second.

I'd also encourage using a single unit for all of these values,
preferably nanoseconds. Absolute times should all be referenced to
CLOCK_MONOTONIC.

-- 
-keith


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

Re: [PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

[Keith Packard]

Jason Ekstrand  writes:

> Yeah, I suppose an application could ask for 10k frames in the future or
> something ridiculous like that.  For sync_file, people strongly want a
> finite time guarantee for security/deadlock reasons.  I don't know how
> happy they would be with a finite time of 10 minutes...

Sure, we've put arbitrary finite limits on vblank counters in other
places, so adding some kind of arbitrary limit like a couple of seconds
would be entirely reasonable here. The Vulkan API doesn't need any of
this complexity at all; the one I'm doing only lets you create a fence
for the next vblank.

> Ok, that's not expected... Part of the point of sync objects is that
> they're re-usable.  The client is free to not re-use them or to be very
> careful about the recycling process.

Heh. I thought the opposite -- lightweight objects that you'd use once
and delete. I can certainly change the API to pass in an existing
syncobj rather than creating a new one. That would be easier in some
ways as it reduces the failure paths a bit.

> Is the event the important part or the moderately accurate timestamp?

I need the timestamp and sequence number, getting them in an event would
mean not having to make another syscall.

> We could probably modify drm_syncobj to have a "last signaled"
> timestamp that's queryable through an IOCTL.

That's exactly what I did, but it only works for these new syncobjs. The
fields are global and could be filled in by other bits of the code.

> Is the sequence number returned necessary?  Will it ever be different from
> the one requested?

Yes, when the application queues it just slightly too late.

The application doesn't actually need either of these values directly,
but the system needs them to respond to requests to queue presentation
at a specific time, so the vulkan driver wants 'recent' vblank
time/sequence data to estimate when a vblank will occur.

-- 
-keith


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

Re: [PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

[Keith Packard]

Jason Ekstrand  writes:

> Is the given sequence number guaranteed to be hit in finite time?

Certainly, it's a finite value...

However, realistically, it's just like all of the other vblank
interfaces where you can specify a crazy sequence and block for a very
long time. So, no different from the current situation.

Of course, the only vulkan API available today only lets you wait for
the next vblank, so we'll be asking for a sequence which is one more
than the current sequence.

> Just to make sure I've got this straight, the client queues a syncobj with
> queue_syncobj to fire at a given sequence number.  Once the syncobj has
> fired (which it can find out by waiting on it), it then calls get_syncobj
> to figure out when it was fired?

If it cares, it can ask. It might not care at all, in which case it
wouldn't have to ask. The syncobj API doesn't provide any direct
information about the state of the object in the wait call.

> If so, what happens if a syncobj is re-used?  Do you just loose the
> information?

You can't reuse one of these -- the 'queue_syncobj' API creates a new
one each time.

> If we have a finite time guarantee, I'm kind-of thinking a sync_file might
> be better as it's a one-shot and doesn't have the information loss
> problem.  I'm not actually sure though.

It's a one-shot, once signaled, you're done with it.

> This whole "wait for a syncobj and then ask when it fired" thing is a bit
> odd.  I'll have to think on it.

Yeah, the event mechanism has the nice feature that you get data with
each event. I guess the alternative would be to have a way to get an
event when a sync object was ready; perhaps a call which provided a set
of syncobjs and delivered a DRM event when any of them was ready?

That has a lot of appeal; it turns the poll-like nature of the current
API into an epoll-like system. Hrm.

-- 
-keith


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

[PATCH 0/1] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

[Keith Packard]

(This is an RFC on whether this pair of ioctls seems reasonable. The
code compiles, but I haven't tested it as I'm away from home this
weekend.)

I'm rewriting my implementation of the Vulkan EXT_display_control
extension, which provides a way to signal a Vulkan fence at vblank
time. I had implemented it using events, but that isn't great as the
Vulkan API includes the ability to wait for any of a set of fences to
be signaled. As the other Vulkan fences are implemented using
dma_fences in the kernel, and (eventually) using syncobj up in user
space, it seems reasonable to use syncobjs for everything and hook
vblank to those.

In any case, I'm proposing two new syncobj/vblank ioctls (the names
aren't great; suggestions welcome, as usual):

DRM_IOCTL_CRTC_QUEUE_SYNCOBJ

Create a new syncobj that will be signaled at (or after) the
specified vblank sequence value. This uses the same parameters
to specify the target sequence as
DRM_IOCTL_CRTC_QUEUE_SEQUENCE.

DRM_IOCTL_CRTC_GET_SYNCOBJ

Once the above syncobj has been signaled, this ioctl allows
the application to find out when that happened, returning both
the vblank sequence count and time (in ns).

I'd like to hear comments on whether this seems reasonable, or whether
I should go in some other direction.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

[Keith Packard]

crtc_queue_syncobj creates a new syncobj that will get signaled at a
specified vblank sequence count.

crtc_get_syncobj returns the time and vblank sequence count when the
syncobj was signaled.

The pair of these allows use of syncobjs instead of events for
monitoring vblank activity.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 drivers/gpu/drm/drm_file.c |   5 +
 drivers/gpu/drm/drm_internal.h |   4 +
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_syncobj.c  |  13 ++-
 drivers/gpu/drm/drm_vblank.c   | 212 +
 include/drm/drm_file.h |  11 ++-
 include/drm/drm_syncobj.h  |  13 +++
 include/uapi/drm/drm.h |  17 
 8 files changed, 253 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index b3c6e997ccdb..c1ada3fe70b0 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -37,6 +37,7 @@
 
 #include 
 #include 
+#include 
 
 #include "drm_legacy.h"
 #include "drm_internal.h"
@@ -711,6 +712,10 @@ void drm_send_event_locked(struct drm_device *dev, struct 
drm_pending_event *e)
dma_fence_put(e->fence);
}
 
+   if (e->syncobj) {
+   drm_syncobj_put(e->syncobj);
+   }
+
if (!e->file_priv) {
kfree(e);
return;
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index c9d5a6cd4d41..71b9435b5b37 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -75,6 +75,10 @@ int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void 
*data,
 
 int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp);
+int drm_crtc_queue_syncobj_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
+int drm_crtc_get_syncobj_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
 
 /* drm_auth.c */
 int drm_getmagic(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4aafe4802099..309611fb5d0d 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -665,6 +665,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, 
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SYNCOBJ, 
drm_crtc_queue_syncobj_ioctl, DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SYNCOBJ, drm_crtc_get_syncobj_ioctl, 
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index cb4d09c70fd4..e197b007079d 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -208,7 +208,7 @@ static const struct dma_fence_ops 
drm_syncobj_null_fence_ops = {
.release = NULL,
 };
 
-static int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
+int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj, bool signal)
 {
struct drm_syncobj_null_fence *fence;
fence = kzalloc(sizeof(*fence), GFP_KERNEL);
@@ -218,7 +218,8 @@ static int drm_syncobj_assign_null_handle(struct 
drm_syncobj *syncobj)
spin_lock_init(>lock);
dma_fence_init(>base, _syncobj_null_fence_ops,
   >lock, 0, 0);
-   dma_fence_signal(>base);
+   if (signal)
+   dma_fence_signal(>base);
 
drm_syncobj_replace_fence(syncobj, >base);
 
@@ -226,6 +227,7 @@ static int drm_syncobj_assign_null_handle(struct 
drm_syncobj *syncobj)
 
return 0;
 }
+EXPORT_SYMBOL(drm_syncobj_assign_null_handle);
 
 int drm_syncobj_find_fence(struct drm_file *file_private,
   u32 handle,
@@ -283,7 +285,7 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj, 
uint32_t flags,
spin_lock_init(>lock);
 
if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) {
-   ret = drm_syncobj_assign_null_handle(syncobj);
+   ret = drm_syncobj_assign_null_handle(syncobj, true);
if (ret < 0) {
drm_syncobj_put(syncobj);
return ret;
@@ -341,7 +343,7 @@ static int drm_syncobj_create_as_handle(struct drm_file 
*file_private,
return ret;
 }
 
-static int drm_syncobj_destroy(struc

RE: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

"Mao, David"  writes:

> Hi Keith,
> If I read the patch correctly, the plane has been interpreted as the same as 
> connector, and the stackIndex is the index of connector of current device.
> Is it by intentional?
> If the hardware don't have underlay/overlay supported, is it better to
> always report plane 0 rather than pretend to have multiple plane?

Yes, you're right. I must have mis-read the specification when writing
this function. Thanks for catching this. I've merged this fix into the
patch and re-pushed it to my drm-lease-v2 branch.

-- 
-keith


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

Re: [PATCH] Allow non-desktop displays when not in strict mode

[Keith Packard]

Charles Lohr <char...@cnlohr.com> writes:

> Considering the lukewarm reception of my last past request and Keith's
> recommendation, I've created and tested a new patch, to bring the
> intended functionality back, only prohibiting non-desktop devices if a
> regular desktop screen is present.
>
> Signed-off-by: Charles Lohr <loh...@gmail.com>

This seems like a reasonable idea to me.

Reviewed-by: Keith Packard <kei...@keithp.com>

-- 
-keith


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

Re: fbcon non-desktop display use

[Keith Packard]

Charles Lohr  writes:

> Even if the vive is the only device connected, it will still not permit it
> to be operated.  See https://github.com/linux-sunxi/linux-sunxi/issues/291
> for dri with a lot of debugging turned on.

Oh, it's not supposed to do that. I had intended to write the code so
that if the only device available was a non-desktop device that it would
go ahead and use it. The X server patches did that, but the kernel ones
did not. It looks like that would be an easy patch -- just skip the
non_desktop check in the !strict case for drm_connector_enabled.

However, your patch is a good addition as it will allow you to also
enable the HMD when other monitors are connected.

> I can understand that most users would probably prefer that the vive isn't
> automatically used if no other displays are available, however, the current
> behavior prevents use of the vive on all devices that use fbdev for their
> primary output.

That was definitely not my intention, and thanks for discovering this!

> I've never sent an email to the kernel devel list, so I'm still a little
> nervous.  Especially because this is against a different branch, and I'm
> starting to think that I should be messaging there, but this is something
> that really needs to go upstream.

We'll get it sorted out; I'm not sure what Dave's preference is these
days anyways.

Aside from some minor formatting issues, this patch looks good to me.

> Signed-off-by:

You'll need to add your name and email address here.

> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
> index 035784ddd..8bfaf79ff 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -55,6 +55,11 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
>  "Overallocation of the fbdev buffer (%) [default="
>  __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
>
> +static bool drm_fbdev_permit_non_desktop;
> +module_param(drm_fbdev_permit_non_desktop, bool, 0644);
> +MODULE_PARM_DESC(drm_fbdev_permit_non_desktop,
> +   "Allow the framebuffer to use non-desktop displays
> [default=off]");
> +

Your email client appears to be wrapping long lines, which breaks the patch.


>  static LIST_HEAD(kernel_fb_helper_list);
>  static DEFINE_MUTEX(kernel_fb_helper_lock);
>
> @@ -2109,7 +2114,7 @@ static bool drm_connector_enabled(struct
> drm_connector *connector, bool strict)
>  {
> bool enable;
>
> -   if (connector->display_info.non_desktop)
> +   if (connector->display_info.non_desktop &&
> !drm_fbdev_permit_non_desktop)

If you added '&& strict' here, it will use the HMD if there aren't any
desktop monitors connected.

-- 
-keith


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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

Jason Ekstrand <ja...@jlekstrand.net> writes:

> On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard <kei...@keithp.com> wrote:
>
> Once we're sure that's what we want, create an MR against the spec that
> just adds enough to the XML to reserve your extension number.  That will
> get merged almost immediately.  Then make a second one with the actual
> extension text and we'll iterate on that either in Khronos gitlab or, if
> you prefer, you can send it as a patch to mesa-dev and then make a Khrons
> MR once it's baked.

I just wrote up the full extension description for both extensions I
need (the one for passing a KMS fd to the driver, and the second to get
the GPU timestamp for doing GOOGLE_display_timing):

https://github.com/keith-packard/Vulkan-Docs

> See also my comments about GEM handle ownership.

Yeah, I think I've got that all cleaned up now -- the code no longer
shares the same file for rendering and display.

-- 
-keith


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

Re: [Mesa-dev] [PATCH 01/21] vulkan: Add KHR_display extension using DRM

[Keith Packard]

Daniel Stone  writes:

> Or better, just use drmModeAddFB2 and pass the format directly. That
> landed back in 3.2 or so, and I don't think there's anyone trying to
> use Vulkan on a kernel from 2011.

Yeah, that's probably a better plan. I've pushed a patch that does this
on top of the long list of patches made in response to Jason's email.

Once he's replied to that, I'll go ahead and smash the new patches back
on top of the original series and re-publish that.

-- 
-keith


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

Re: [PATCH 01/21] vulkan: Add KHR_display extension using DRM

[Keith Packard]

Jason Ekstrand  writes:

Thanks a million for the intense review. I've pushed 15 tiny patches
that address individual questions in this message. If you want to look
at those separately, that would be great. When we're done, I'll merge
them back into the giant patch.

Sorry for the delay in answering; you asked a hard question about GEM
handles and reference counting which I think I've resolved by
eliminating the ability to share the same fd for modesetting and
rendering.

Let me know if I've deleted too much context from your answers.

> With the exception of NIR (which is a bit odd), we usually use ALL_CAPS for
> enum values.

Thanks, fixed.

> Yes, this does seem like the only reasonable mode for now.  I suppose you
> could check to see if the platform supports ASYNC_FLIP and advertise
> IMMEDIATE in that case.  I know intel doesn't advertise it but I thought
> amdgpu does.

Ok, we'll put that on the wish list, along with MAILBOX (which
applications actually want :-)

> vk_outarray, though I suppose you've probably already made that
> change.

Yup, vk_outarray everywhere now.

> I don't see use_prime_blit being set anywhere.  Perhaps that comes in a
> later patch?  The line is obviously correct, so I'm fine with leaving
> it.

You're right -- this was a cult-n-paste error. I don't support prime at
all, so I've removed this bit.

> This will have to be updated for modifiers.  I'm reasonably happy for it to
> be the no-op update for now though KHR_display supporting real modifiers
> would be nice. :-)

Yeah, "patches welcome", of course. I don't have a requirement for them
on Radeon at this point.

>> +   if (result != VK_SUCCESS)
>> +  return result;
>> +
>> +   ret = drmPrimeFDToHandle(wsi->master_fd, image->base.fd,
>> _handle);
>>
>
> This opens up some interesting questions.  GEM handles are not reference
> counted by the kernel.  If the driver that we're running on is using
> master_fd, then we shouldn't close our handle because that would close the
> handle for the driver as well.  If it's not using master_fd, we should
> close the handle to avoid leaking it.  The later is only a worry in the
> prime case but given that I saw a line above about use_prime_blit, you have
> me scared. :-)

Ok, as I mentioned in the header of this message, I've eliminated any
code which talks about potentially sharing master_fd and render_fd. I
removed render_fd from the wsi layer entirely as it is no longer used
anywhere.

In the drivers, when you request KHR_display, I attempt to open the
related primary node and if that succeeds, I pass that to the wsi layer
for use there. That fd is otherwise unused by the driver, and in fact
the driver doesn't need to close it as the wsi layer will.

Obviously having two FDs is "wasteful" at some level as we really don't
need that, but that's what the acquire_xlib extension will have to do
anyways.

> One solution to this connundrum would be to simply never use the master FD
> for the Vulkan driver itself and always open a render node.  If handed a
> master FD, you could check if it matches your render node and set
> use_prime_blit accordingly.  Then the driver and WSI would have separate
> handle domains and this problem would be solved.  You could also just open
> the master FD twice, once for WSI and once for the driver.

Yup, two FDs, one master, one render. That way, the kludge
seen in this patch where it opens the master when you request the
KHR_display extension works the same as the acquire_xlib code in the
later patch.

> You have the format in create_info.  We could add some generic VkFormat
> introspection or we can just handle the 2-4 cases we care about
> directly.

Given that this layer provides the list of valid surface formats which
that image could contain, I've added depth/bpp information to that list
and the image_init code walks over the list of possible formats to find
the associated depth/bpp values.

If the application provides an invalid format, I'm returning
VK_ERROR_DEVICE_LOST as that is a valid error return and I couldn't find
anything else that seemed like a better value. If we get here, the
application made a mistake anyways.

> What happens if we close the handle immediately after calling
> drmModeAddFB?  Does the FB become invalid?  If so, then we probably want to
> stash the handle so we can clean it up when we destroy the swapchain.
> Unless, of course, we're willing to make the assumption (as stated above)
> that the driver and WSI are always using the same FD.

It looks like the FB ends up with a reference to the object, so it would
should be safe to just close the handle at this point.  However, to make
it less dependent on the kernel behavior, I've changed the code to store
the buffer_object handle in the image and then added code to free both
the buffer object and the frame buffer in wsi_display_image_finish.

Thanks for finding the leak.

>> +/* call with wait_mutex held */
>>
>
> It might be worth a line in the 

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

Jason Ekstrand  writes:

> I think I like option 1 (KEITHP_kms_display).  If the client knows the
> difference between render and primary for 2, then they are most likely
> already opening the master node themselves or at least have access to
> the FD.

Ok, I'll work on cleaning up that extension and renaming it. I have no
idea how to get new words into the Vulkan spec, but it would be good to
have that done too.

I guess the question is whether I should bother to leave the current
try-to-open-primary kludge in place. In good news, under X, both radv
and anv "fail" to use the primary device as another master is already
running, so at least we aren't running with a primary FD open?

> Sorry, I'm just not feeling all that opinionated about this at the moment.
> :-)

No more than I; either way is fine with me, if you're happy to use
something like the existing code I've got, that's even nicer.

> Clearly, we need systemd-edidd. :-)

A library would be nice; we have the edid data everywhere, we just don't
have it in a useful form except inside the X server and kernel.

> Yes, *if* it has a preferred resolution, we should return that one.  If it
> doesn't, we should walk the list and return the largest instead of just
> defaulting to 1024x768.  At least that's what the spec seems to say to
> me.

Oh. I totally missed that part. Yeah, that's just wrong. I've just
pushed a patch that finds the largest mode when there isn't a preferred
one. Oddly, I have no devices here which don't specify a preferred mode,
so it will be somewhat difficult to test...

> Yup.  Let's just drop INHERIT and only advertise OPAQUE.

Done.

I've updated my drm-lease branch with all of these changes merged into
the existing patches (and so noted), plus the new patch described above
which looks for the largest mode when no preferred mode is specified.

Thanks again for all of your careful review; while we haven't changed
any significant semantics, we have found a bunch of outright bugs in the
code.

-- 
-keith


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

Re: [PATCH 1/3] drm/edid: quirk Oculus Rift headsets as non-desktop

[Keith Packard]

Philipp Zabel  writes:

> Should these be backported to older kernels as well, to avoid burning
> the fbdev console into VR headset OLED displays?

I don't think so; it's a bunch of code to backport, and the matching
code for the X desktop hasn't even landed upstream yet. Wayland doesn't
even have a proposed specification for this stuff yet.

-- 
-keith


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

Re: [Mesa-dev] [PATCH 07/21] vulkan: Add EXT_acquire_xlib_display

[Keith Packard]

Eric Engestrom  writes:

> Can be simplified a bit:
>
>   _xlib_lease = get_option('xlib-lease')
>   if _xlib_lease == 'auto'
> with_xlib_lease = with_platform_x11 and with_platform_display
>   else
> with_xlib_lease = _xlib_lease == 'true'
>   endif
>
> (We also usually try to avoid changing the type of a var, and meson might
> start being more strict with types in future releases)

I wondered about that in the places I copied my code from. Good to know
there's a better practice. I've switched to using this form.

>> +if with_xlib_lease
>> +  vulkan_wsi_deps += dep_xcb_xrandr
>> +  vulkan_wsi_args += [
>> +'-DVK_USE_PLATFORM_XLIB_XRANDR_EXT',
>> +  ]
>
> vulkan_wsi_args += '-DVK_USE_PLATFORM_XLIB_XRANDR_EXT'

I switched all of the inappropriate usage to this form for six separate
patches (three each for core/anv/radv by two extensions (DISPLAY and 
XLIB_XRANDR).

> with that, the meson part of this is
> Reviewed-by: Eric Engestrom 

Awesome!

Thanks for reviewing the build system bits; I'm just starting to use
meson and every new change is a learning opportunity at this point.

-- 
-keith


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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

Jason Ekstrand  writes:

> It seems a little odd to me to default to opening the master node and then
> fall back to the render node if it doesn't work.  I suppose that's probably
> ok so long as we ensure that vkGetPhysicalDeviceDisplayPropertiesKHR
> returns no displays if we're on the render node.
>
> We could always go back to the DRM fd extension idea but I'm not coming up
> with something nice and clean in the 60 seconds I've thought about it.

As I said in the last comments about this section, Dave Airlie and I
added this code only recently so that we could test this extension
without also needing the kernel and X leasing changes.

I think we should decide how to enable this functionality "for real",
and I have two easy options:

 1) Use my KEITHP_kms_display extension (presumably renamed MESA), which
exposes a way to pass the DRM fd from the application into the
driver. This makes it possible for the application to get the FD
through any mechanism at all (including RandR or the new Wayland
extension) and leave that out of the Vulkan code entirely.

 2) Add a new extension which passes a new data structure that directs
the driver to open either the Render or Primary nodes.

When this is done, we can switch from the current code which tries to
open the Primary node whenever the KHR_display extension is requested.

> Would it make anything easier if we just storred the DRM struct here?  "No"
> is a perfectly valid answer.

Nope -- once we add the acquire_xlib extension, we get modes through
either X or DRM, depending on whether we're pre-lease or post-lease.

> Any particular reason why the list of modes is global and not in the
> connector?  It seems like it would be a tiny bit more efficient and
> convenient to put the list in the connector.

I think you're right. I have some vague memory of a lifetime issue with
connectors, but can't think of what it might be, even after reviewing
the relevant parts of the Vulkan spec. I've gone ahead and changed it;
seems to work fine.

>> +   LIST_FOR_EACH_ENTRY(display_mode, >display_modes, list)
>> +  if (display_mode->connector == connector)
>> + display_mode->valid = false;
>>
>
> Please use braces for loops containing more than one line.

Well, that was easy to fix -- the condition is now gone :-)

> Since we're allocating these in a physical device query, we need to use the
> INSTANCE scope.  the OBJECT scope is intended for vkCreate functions to
> allocated data that will live no longer than the associated vkDestroy
> function.

Thanks! The whole Vulkan memory model remains a mystery to me.

I've changed allocation of wsi_display_mode and wsi_display_connector to
use SCOPE_INSTANCE. VkIceSurfaceDisplay, wsi_display_fence and
wsi_display_swapchain remain using SCOPE_OBJECT.

I've also changed *all* instances of vk_alloc to use
vk_zalloc. These are all small data structures allocated only during
application startup, so I think the benefit of known memory contents is
worth the cost of memset.

> Hooray for obviously false fixed constants!
>
> I know the answer to this will be "EDIDs lie, never trust them!" but can we
> get the real value somehow?  As someone who has a 13" laptop with a
> 3200x1800 display, I know that number isn't always right. :-)

Yes, we could dig the real value out of the EDID, but we'd have to parse
the entire EDID to manage that. I don't want to stick an EDID parser
directly in Mesa, so I'm kinda waiting for someone to create a separate
EDID parsing library that the X server, Mesa and others can share. Until
then, I'd prefer to just lie here.

> double-;;

Thx. I remember seeing this while reviewing patches and forgot all about
it...

> From the Vulkan spec:
>
> Note:
> For devices which have no natural value to return here, implementations
> *should* return the maximum resolution supported.
>
> We should walk the list and pick the biggest one.

I did this intentionally -- most monitors have a preferred resolution,
which is their native pixel size. And, we want to tell applications to
use that size, even if the monitor offers a larger (presumabl scaled)
resolution in their mode list.

> See question about MM_PER_PIXEL above

Yeah, see response about not boiling the EDID ocean above ;-)

> I know i915 can do better at least in some cases.  Is there a practical way
> to expose this?  If not, I'm fine with just exposing IDENTITY.

I'm not seeing this exposed through the common DRM mode interfaces
yet. We should probably consider adding this to the kernel and then
adding it here.

> This error is not allowed for this function.  We should just write 0 to
> property_count and return VK_SUCCESS.  Maybe add some asserts for debug
> builds if you really think this shouldn't ever happen.

I bet it will happen if you VT switch away and then try this function.

I've added this at the end of the function:

bail:
   *property_count = 0;
   return VK_SUCCESS;

> 

[PATCH 21/21] radv: Add VK_GOOGLE_display_timing extension to radv driver

[Keith Packard]

This adds support for the VK_GOOGLE_display timing extension.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/amd/vulkan/radv_extensions.py |  1 +
 src/amd/vulkan/radv_wsi.c | 32 
 2 files changed, 33 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 0e7b18dc104..a8d9c8410e1 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -96,6 +96,7 @@ EXTENSIONS = [
 Extension('VK_AMD_rasterization_order',   1, 
'device->rad_info.chip_class >= VI && device->rad_info.max_se >= 2'),
 Extension('VK_AMD_shader_info',   1, True),
 Extension('VK_MESA_query_timestamp',  1, True),
+Extension('VK_GOOGLE_display_timing', 1, True),
 ]
 
 class VkVersion:
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 2433390562b..fd26194f6ce 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -247,3 +247,35 @@ VkResult radv_QueuePresentKHR(
queue->queue_family_index,
pPresentInfo);
 }
+
+/* VK_GOOGLE_display_timing */
+VkResult
+radv_GetRefreshCycleDurationGOOGLE(
+   VkDevice  _device,
+   VkSwapchainKHRswapchain,
+   VkRefreshCycleDurationGOOGLE  *pDisplayTimingProperties)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_refresh_cycle_duration(>wsi_device,
+_device,
+swapchain,
+pDisplayTimingProperties);
+}
+
+VkResult
+radv_GetPastPresentationTimingGOOGLE(VkDevice
_device,
+VkSwapchainKHR  
swapchain,
+uint32_t
*pPresentationTimingCount,
+VkPastPresentationTimingGOOGLE  
*pPresentationTimings)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   struct radv_physical_device *pdevice = device->physical_device;
+
+   return wsi_common_get_past_presentation_timing(>wsi_device,
+  _device,
+  swapchain,
+  pPresentationTimingCount,
+  pPresentationTimings);
+}
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 17/21] anv: Add new VK_MESA_query_timestamp extension to anv driver

[Keith Packard]

This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/intel/Makefile.vulkan.am   |  7 +++
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_gem.c | 13 +
 src/intel/vulkan/anv_private.h |  1 +
 src/intel/vulkan/genX_query.c  | 15 +++
 src/intel/vulkan/meson.build   | 12 ++--
 6 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index 0f0d3815097..5d4298c040a 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -24,36 +24,43 @@
 # out and we'll fail at `make dist'
 vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
 vk_android_native_buffer_xml = 
$(top_srcdir)/src/vulkan/registry/vk_android_native_buffer.xml
+vk_mesa_query_timestamp_xml = 
$(top_srcdir)/src/vulkan/registry/vk_mesa_query_timestamp.xml
 
 vulkan/anv_entrypoints.c: vulkan/anv_entrypoints_gen.py \
  vulkan/anv_extensions.py \
  $(vulkan_api_xml) \
+ $(vk_mesa_query_timestamp_xml) \
  $(vk_android_native_buffer_xml)
$(MKDIR_GEN)
$(AM_V_GEN)$(PYTHON2) $(srcdir)/vulkan/anv_entrypoints_gen.py \
--xml $(vulkan_api_xml) \
--xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
--outdir $(builddir)/vulkan
 vulkan/anv_entrypoints.h: vulkan/anv_entrypoints.c
 
 vulkan/anv_extensions.c: vulkan/anv_extensions_gen.py \
 vulkan/anv_extensions.py \
 $(vulkan_api_xml) \
+$(vk_mesa_query_timestamp_xml) \
 $(vk_android_native_buffer_xml)
$(MKDIR_GEN)
$(AM_V_GEN)$(PYTHON2) $(srcdir)/vulkan/anv_extensions_gen.py \
--xml $(vulkan_api_xml) \
--xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
--out-c $@
 
 vulkan/anv_extensions.h: vulkan/anv_extensions_gen.py \
 vulkan/anv_extensions.py \
 $(vulkan_api_xml) \
+$(vk_mesa_query_timestamp_xml) \
 $(vk_android_native_buffer_xml)
$(MKDIR_GEN)
$(AM_V_GEN)$(PYTHON2) $(srcdir)/vulkan/anv_extensions_gen.py \
--xml $(vulkan_api_xml) \
--xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
--out-h $@
 
 BUILT_SOURCES += $(VULKAN_GENERATED_FILES)
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 1c6c4f8e27b..7706ccdb5bb 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -91,6 +91,7 @@ EXTENSIONS = [
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_display_control',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_MESA_query_timestamp',  1, True),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 34c09891086..588b323d113 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -418,6 +418,19 @@ anv_gem_fd_to_handle(struct anv_device *device, int fd)
return args.handle;
 }
 
+int
+anv_gem_reg_read(struct anv_device *device, uint32_t offset, uint64_t *result)
+{
+   struct drm_i915_reg_read args = {
+  .offset = offset
+   };
+
+   int ret = anv_ioctl(device->fd, DRM_IOCTL_I915_REG_READ, );
+
+   *result = args.val;
+   return ret;
+}
+
 #ifndef SYNC_IOC_MAGIC
 /* duplicated from linux/sync_file.h to avoid build-time dependency
  * on new (v4.7) kernel headers.  Once distro's are mostly using
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 1d3e5fcd921..337d8ca3f15 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -932,6 +932,7 @@ bool anv_gem_supports_48b_addresses(int fd);
 int anv_gem_gpu_get_reset_stats(struct anv_device *device,
 uint32_t *active, uint32_t *pending);
 int anv_gem_handle_to_fd(struct anv_device *device, uint32_t gem_handle);
+int anv_gem_reg_read(struct anv_device *device, uint32_t offset, uint64_t 
*result);
 uint32_t anv_gem_fd_to_handle(struct anv_device *device, int fd);
 int anv_gem_set_caching(struct anv_device *device, uint32_t gem_handle, 
uint32_t caching);
 int anv_gem_set_domain(struct anv_device *device, uint32_t gem_handle,
diff --

[PATCH 07/21] vulkan: Add EXT_acquire_xlib_display

[Keith Packard]

This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application. For DRM, we use the
Linux resource leasing mechanism.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 configure.ac|  32 +++
 meson.build |  17 ++
 meson_options.txt   |   7 +
 src/vulkan/Makefile.am  |   5 +
 src/vulkan/wsi/meson.build  |   7 +
 src/vulkan/wsi/wsi_common_display.c | 472 
 src/vulkan/wsi/wsi_common_display.h |  17 ++
 7 files changed, 557 insertions(+)

diff --git a/configure.ac b/configure.ac
index 46318365603..cf05d049c26 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1547,6 +1547,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],
@@ -1846,6 +1847,18 @@ if test x"$enable_dri3" = xyes; then
 PKG_CHECK_MODULES([XCB_DRI3], [$dri3_modules])
 fi
 
+
+if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm'; then
+have_xlease=yes
+else
+have_xlease=no
+fi
+
+if test x"$have_xlease" = xyes; then
+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')
@@ -1853,6 +1866,25 @@ 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')
 
+AC_ARG_ENABLE(xlib-lease,
+[AS_HELP_STRING([--enable-xlib-lease]
+[enable VK_acquire_xlib_display using X leases])],
+[enable_xlib_lease=$enableval], [enable_xlib_lease=auto])
+case "x$enable_xlib_lease" in
+xyes)
+;;
+xno)
+;;
+*)
+if echo "$platforms" | grep -q 'x11' && echo "$platforms" | grep -q 'drm'; 
then
+enable_xlib_lease=yes
+else
+enable_xlib_lease=no
+fi
+esac
+
+AM_CONDITIONAL(HAVE_XLIB_LEASE, test "x$enable_xlib_lease" = xyes)
+
 dnl
 dnl More DRI setup
 dnl
diff --git a/meson.build b/meson.build
index aeb7f5e2917..595b0f66cd7 100644
--- a/meson.build
+++ b/meson.build
@@ -262,6 +262,19 @@ if _platforms != ''
   egl_native_platform = _split[0]
 endif
 
+with_xlib_lease = get_option('xlib-lease')
+if with_xlib_lease == 'auto'
+  if with_platform_x11 and with_platform_display
+with_xlib_lease = true
+  else
+with_xlib_lease = false
+  endif
+elif with_xlib_lease == 'true'
+  with_xlib_lease = true
+else
+  with_xlib_lease = false
+endif
+
 with_glx = get_option('glx')
 if with_glx == 'auto'
   if with_dri
@@ -1151,6 +1164,7 @@ dep_xcb_present = []
 dep_xcb_sync = []
 dep_xcb_xfixes = []
 dep_xshmfence = []
+dep_xcb_xrandr = []
 if with_platform_x11
   if with_glx == 'xlib' or with_glx == 'gallium-xlib'
 dep_x11 = dependency('x11')
@@ -1190,6 +1204,9 @@ if with_platform_x11
   if with_egl
 dep_xcb_xfixes = dependency('xcb-xfixes')
   endif
+  if with_xlib_lease
+dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.12')
+  endif
 endif
 
 if get_option('gallium-extra-hud')
diff --git a/meson_options.txt b/meson_options.txt
index 7fafe2deaac..d38c9aa6149 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -286,3 +286,10 @@ option(
   value : '',
   description : 'Comma delimited list of tools to build. choices : 
freedreno,glsl,intel,nir,nouveau or all'
 )
+option(
+  'xlib-lease',
+  type : 'combo',
+  value : 'auto',
+  choices : ['auto', 'true', 'false'],
+  description : 'Enable VK_EXT_acquire_xlib_display.'
+)
diff --git a/src/vulkan/Makefile.am b/src/vulkan/Makefile.am
index c33ac5758f7..e96ef68972c 100644
--- a/src/vulkan/Makefile.am
+++ b/src/vulkan/Makefile.am
@@ -64,6 +64,11 @@ AM_CPPFLAGS += \
 VULKAN_WSI_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
 endif
 
+if HAVE_XLIB_LEASE
+AM_CPPFLAGS += \
+   -DVK_USE_PLATFORM_XLIB_XRANDR_EXT
+endif
+
 BUILT_SOURCES += $(VULKAN_WSI_WAYLAND_GENERATED_FILES)
 CLEANFILES = $(BUILT_SOURCES)
 
diff --git a/src/vulkan/wsi/meson.build b/src/vulkan/wsi/meson.build
index 743631a6113..5e3d43a2748 100644
--- a/src/vulkan/wsi/meson.build
+++ b/src/vulkan/wsi/meson.bui

[PATCH 10/21] vulkan: Add VK_EXT_display_surface_counter [v3]

[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

v3: Fix wayland WSI, regularize spelling

Misspelled 'surface' in get_capabilities2ext
Remove extra _ from get_capabilities_2ext in a couple of places

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 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 +++
 6 files changed, 99 insertions(+)

diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index c0a285e5814..02abc9ef7fb 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -579,6 +579,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 29d64b21aff..e63700e2e65 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -655,6 +655,32 @@ wsi_display_surface_get_capabilities2(VkIcdSurfaceBase 
*icd_surface,
return wsi_display_surface_get_capabilities(icd_surface, 
>surfaceCapabilities);
 }
 
+static VkResult
+wsi_display_surface_get_capabilities2ext(VkIcdSurfaceBase *icd_surface,
+  VkSurfaceCapabilities2EXT *caps)
+{
+   VkSurfaceCapabilitiesKHR khr_caps;
+   VkResult ret;
+
+   assert(caps->sType == VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT);
+   ret = wsi_display_surface_get_capabilities(icd_surface, _caps);
+   if (ret)
+  return ret;
+
+   caps->minImageCount = khr_caps.minImageCount;
+   caps->maxImageCount = khr_caps.maxImageCount;
+   caps->currentExtent = khr_caps.currentExtent;
+   caps->minImageExtent = khr_caps.minImageExtent;
+   caps->maxImageExtent = khr_caps.maxImageExtent;
+   caps->maxImageArrayLayers = khr_caps.maxImageArrayLayers;
+   caps->supportedTransforms = khr_caps.supportedTransforms;
+   caps->currentTransform = khr_caps.currentTransform;
+   caps->supportedCompositeAlpha = khr_caps.supportedCompositeAlpha;
+   caps->supportedUsageFlags = khr_caps.supportedUsageFlags;
+   caps->supportedSurfaceCounters = 0;
+   return ret;
+}
+
 static const VkFormat available_surface_formats[] = {
VK_FORMAT_B8G8R8A8_SRGB,
VK_FORMAT_B8G8R8A8_UNORM,
@@ -1323,6 +1349,7 @@ wsi_display_init_wsi(struct wsi_device *wsi_device,
wsi->base.get_support = wsi_display_surface_get_support;
wsi->base.get_capabilities = wsi_display_surface_get_capabilities;
wsi->base.get_capabilities2 = wsi_display_surface_get_capabilities2;
+   wsi->base.get_capabilities2ext = wsi_display_surface_get_capabilities2ext;
wsi->base.get_formats = wsi_display_surface_get_formats;
wsi->base.get_formats2 = wsi_display_surface_get_formats2;
wsi->base.get_present_modes = wsi_display_surface_get_present_modes;
diff --git a/src/vulkan/wsi/wsi_common_private.h 
b/src/vulkan/wsi/wsi_common_private.h
index d38d2efa116..0d902846238 100644
--- a/src/vulkan/wsi/wsi_common_private.h
+++ b/src/vulkan/wsi/wsi_common_private.h

[PATCH 08/21] anv: Add EXT_acquire_xlib_display to anv driver

[Keith Packard]

This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application to the anv driver.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/intel/Makefile.vulkan.am   |  7 +++
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_extensions_gen.py | 10 +-
 src/intel/vulkan/anv_wsi_display.c | 30 ++
 src/intel/vulkan/meson.build   |  7 +++
 5 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index 7c428a799d7..0f0d3815097 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -194,6 +194,13 @@ VULKAN_CPPFLAGS += \
 VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
 endif
 
+if HAVE_XLIB_LEASE
+VULKAN_CPPFLAGS += \
+   -DVK_USE_PLATFORM_XLIB_XRANDR_EXT \
+   $(XCB_RANDR_CFLAGS)
+VULKAN_LIB_DEPS += $(XCB_RANDR_LIBS)
+endif
+
 noinst_LTLIBRARIES += vulkan/libvulkan_common.la
 vulkan_libvulkan_common_la_SOURCES = $(VULKAN_SOURCES)
 vulkan_libvulkan_common_la_CFLAGS = $(VULKAN_CFLAGS)
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 75b6bf0b41f..47993f45d41 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -85,6 +85,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHR_display',  23, 
'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_KHX_multiview', 1, True),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
diff --git a/src/intel/vulkan/anv_extensions_gen.py 
b/src/intel/vulkan/anv_extensions_gen.py
index 84d07f9767a..025907aff72 100644
--- a/src/intel/vulkan/anv_extensions_gen.py
+++ b/src/intel/vulkan/anv_extensions_gen.py
@@ -113,12 +113,12 @@ _TEMPLATE_C = Template(COPYRIGHT + """
 #include "vk_util.h"
 
 /* Convert the VK_USE_PLATFORM_* defines to booleans */
-%for platform in ['ANDROID', 'WAYLAND', 'XCB', 'XLIB', 'DISPLAY']:
-#ifdef VK_USE_PLATFORM_${platform}_KHR
-#   undef VK_USE_PLATFORM_${platform}_KHR
-#   define VK_USE_PLATFORM_${platform}_KHR true
+%for platform in ['ANDROID_KHR', 'WAYLAND_KHR', 'XCB_KHR', 'XLIB_KHR', 
'DISPLAY_KHR', 'XLIB_XRANDR_EXT']:
+#ifdef VK_USE_PLATFORM_${platform}
+#   undef VK_USE_PLATFORM_${platform}
+#   define VK_USE_PLATFORM_${platform} true
 #else
-#   define VK_USE_PLATFORM_${platform}_KHR false
+#   define VK_USE_PLATFORM_${platform} false
 #endif
 %endfor
 
diff --git a/src/intel/vulkan/anv_wsi_display.c 
b/src/intel/vulkan/anv_wsi_display.c
index e6f67f7dec9..e87aed49f7d 100644
--- a/src/intel/vulkan/anv_wsi_display.c
+++ b/src/intel/vulkan/anv_wsi_display.c
@@ -138,3 +138,33 @@ anv_ReleaseDisplayEXT(VkPhysicalDevice physical_device,
   >wsi_device,
   display);
 }
+
+#ifdef VK_USE_PLATFORM_XLIB_XRANDR_EXT
+VkResult
+anv_AcquireXlibDisplayEXT(VkPhysicalDevice physical_device,
+   Display  *dpy,
+   VkDisplayKHR display)
+{
+   ANV_FROM_HANDLE(anv_physical_device, pdevice, physical_device);
+
+   return wsi_acquire_xlib_display(physical_device,
+   >wsi_device,
+   dpy,
+   display);
+}
+
+VkResult
+anv_GetRandROutputDisplayEXT(VkPhysicalDevice  physical_device,
+  Display   *dpy,
+  RROutput  output,
+  VkDisplayKHR  *display)
+{
+   ANV_FROM_HANDLE(anv_physical_device, pdevice, physical_device);
+
+   return wsi_get_randr_output_display(physical_device,
+   >wsi_device,
+   dpy,
+   output,
+   display);
+}
+#endif /* VK_USE_PLATFORM_XLIB_XRANDR_EXT */
diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index 2e2ab8f7ecd..d3ab5ac8a64 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -178,6 +178,13 @@ if with_platform_display
   libanv_files += files('anv_wsi_display.c')
 endif
 
+if with_xlib_lease
+  anv_deps += dep_xcb_xrandr
+  anv_flags += [
+'-DVK_USE_PLATFORM_XLIB_XRANDR_EXT',
+  ]
+endif
+
 libanv_common = static_library(
   'anv_common',
   [libanv_files, anv_entrypoints, anv_extensions_c, anv_extensions_h],
-- 
2.15.1

___
dri-devel mail

[PATCH 20/21] anv: Add VK_GOOGLE_display_timing extension to anv driver

[Keith Packard]

This adds support for the VK_GOOGLE_display timing extension.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_wsi.c | 29 +
 2 files changed, 30 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 7706ccdb5bb..b441b8e1d8e 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -92,6 +92,7 @@ EXTENSIONS = [
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_display_control',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_MESA_query_timestamp',  1, True),
+Extension('VK_GOOGLE_display_timing', 1, True),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 52362adfb71..7801a989e0d 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -239,3 +239,32 @@ VkResult anv_QueuePresentKHR(
_queue, 0,
pPresentInfo);
 }
+
+/* VK_GOOGLE_display_timing */
+VkResult
+anv_GetRefreshCycleDurationGOOGLE(VkDevice  _device,
+  VkSwapchainKHRswapchain,
+  VkRefreshCycleDurationGOOGLE  
*pDisplayTimingProperties)
+{
+   ANV_FROM_HANDLE(anv_device, device, _device);
+
+   return 
wsi_common_get_refresh_cycle_duration(>instance->physicalDevice.wsi_device,
+_device,
+swapchain,
+pDisplayTimingProperties);
+}
+
+VkResult
+anv_GetPastPresentationTimingGOOGLE(VkDevice
_device,
+VkSwapchainKHR  
swapchain,
+uint32_t
*pPresentationTimingCount,
+VkPastPresentationTimingGOOGLE  
*pPresentationTimings)
+{
+   ANV_FROM_HANDLE(anv_device, device, _device);
+
+   return 
wsi_common_get_past_presentation_timing(>instance->physicalDevice.wsi_device,
+  _device,
+  swapchain,
+  pPresentationTimingCount,
+  pPresentationTimings);
+}
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 19/21] vulkan: Add VK_GOOGLE_display_timing extension (x11 and display backends)

[Keith Packard]

This adds support for the VK_GOOGLE_display timing extension, which
provides two things:

 1) Detailed information about when frames are displayed, including
slack time between GPU execution and display frame.

 2) Absolute time control over swapchain queue processing. This allows
the application to request frames be displayed at specific
absolute times, using the same timebase as that provided in vblank
events.

Support for this extension has been implemented for the x11 and
display backends; adding support to other backends should be
reasonable straightforward for one familiar with those systems and
should not require any additional device-specific code.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/vulkan/wsi/wsi_common.c | 254 +++-
 src/vulkan/wsi/wsi_common.h |  24 
 src/vulkan/wsi/wsi_common_display.c | 143 +++-
 src/vulkan/wsi/wsi_common_private.h |  35 +
 src/vulkan/wsi/wsi_common_x11.c |  69 +-
 5 files changed, 514 insertions(+), 11 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 02abc9ef7fb..c36e4ccdcbe 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -40,11 +40,16 @@ wsi_device_init(struct wsi_device *wsi,
PFN_vk##func func = (PFN_vk##func)proc_addr(pdevice, "vk" #func)
WSI_GET_CB(GetPhysicalDeviceMemoryProperties);
WSI_GET_CB(GetPhysicalDeviceQueueFamilyProperties);
+   WSI_GET_CB(GetPhysicalDeviceProperties);
 #undef WSI_GET_CB
 
GetPhysicalDeviceMemoryProperties(pdevice, >memory_props);
GetPhysicalDeviceQueueFamilyProperties(pdevice, >queue_family_count, 
NULL);
 
+   VkPhysicalDeviceProperties properties;
+   GetPhysicalDeviceProperties(pdevice, );
+   wsi->timestamp_period = properties.limits.timestampPeriod;
+
 #define WSI_GET_CB(func) \
wsi->func = (PFN_vk##func)proc_addr(pdevice, "vk" #func)
WSI_GET_CB(AllocateMemory);
@@ -53,14 +58,18 @@ wsi_device_init(struct wsi_device *wsi,
WSI_GET_CB(BindImageMemory);
WSI_GET_CB(BeginCommandBuffer);
WSI_GET_CB(CmdCopyImageToBuffer);
+   WSI_GET_CB(CmdResetQueryPool);
+   WSI_GET_CB(CmdWriteTimestamp);
WSI_GET_CB(CreateBuffer);
WSI_GET_CB(CreateCommandPool);
WSI_GET_CB(CreateFence);
WSI_GET_CB(CreateImage);
+   WSI_GET_CB(CreateQueryPool);
WSI_GET_CB(DestroyBuffer);
WSI_GET_CB(DestroyCommandPool);
WSI_GET_CB(DestroyFence);
WSI_GET_CB(DestroyImage);
+   WSI_GET_CB(DestroyQueryPool);
WSI_GET_CB(EndCommandBuffer);
WSI_GET_CB(FreeMemory);
WSI_GET_CB(FreeCommandBuffers);
@@ -68,9 +77,13 @@ wsi_device_init(struct wsi_device *wsi,
WSI_GET_CB(GetImageMemoryRequirements);
WSI_GET_CB(GetImageSubresourceLayout);
WSI_GET_CB(GetMemoryFdKHR);
+   WSI_GET_CB(GetPhysicalDeviceProperties);
WSI_GET_CB(GetPhysicalDeviceFormatProperties);
+   WSI_GET_CB(GetPhysicalDeviceQueueFamilyProperties);
+   WSI_GET_CB(GetQueryPoolResults);
WSI_GET_CB(ResetFences);
WSI_GET_CB(QueueSubmit);
+   WSI_GET_CB(QueryCurrentTimestampMESA);
WSI_GET_CB(WaitForFences);
 #undef WSI_GET_CB
 
@@ -136,6 +149,8 @@ wsi_swapchain_init(const struct wsi_device *wsi,
chain->device = device;
chain->alloc = *pAllocator;
chain->use_prime_blit = false;
+   chain->timing_insert = 0;
+   chain->timing_count = 0;
 
chain->cmd_pools =
   vk_zalloc(pAllocator, sizeof(VkCommandPool) * wsi->queue_family_count, 8,
@@ -209,6 +224,60 @@ align_u32(uint32_t v, uint32_t a)
return (v + a - 1) & ~(a - 1);
 }
 
+static VkResult
+wsi_image_init_timestamp(const struct wsi_swapchain *chain,
+ struct wsi_image *image)
+{
+   const struct wsi_device *wsi = chain->wsi;
+   VkResult result;
+   /* Set up command buffer to get timestamp info */
+
+   result = wsi->CreateQueryPool(chain->device,
+ &(const VkQueryPoolCreateInfo) {
+.sType = 
VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO,
+   .queryType = VK_QUERY_TYPE_TIMESTAMP,
+   .queryCount = 1,
+   },
+ NULL,
+ >query_pool);
+
+   if (result != VK_SUCCESS)
+  goto fail;
+
+   result = wsi->AllocateCommandBuffers(chain->device,
+&(const VkCommandBufferAllocateInfo) {
+   .sType = 
VK_STRUCTURE_TYPE_COMMAND_BUFFER_ALLOCATE_INFO,
+  .pNext = NULL,
+  .commandPool = 
chain->cmd_pools[0],
+  .level = 
VK_COMMAND_

[PATCH 13/21] vulkan: add VK_EXT_display_control [v3]

[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.

v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
been removed from the proposed kernel API.

Add NULL parameter to drmCrtcQueueSequence ioctl as we
don't care what sequence the event was actually queued to.

v3: Adapt to pthread clock switch to MONOTONIC

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/vulkan/wsi/wsi_common.h |   9 ++
 src/vulkan/wsi/wsi_common_display.c | 286 +++-
 src/vulkan/wsi/wsi_common_display.h |  29 
 3 files changed, 323 insertions(+), 1 deletion(-)

diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 124d096170a..e504f4120ad 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -48,6 +48,15 @@ struct wsi_memory_allocate_info {
 bool implicit_sync;
 };
 
+struct wsi_fence {
+   VkDevice device;
+   const struct wsi_device  *wsi_device;
+   VkDisplayKHR display;
+   const VkAllocationCallbacks  *alloc;
+   bool (*wait)(struct wsi_fence *fence, bool 
absolute, uint64_t timeout);
+   void (*destroy)(struct wsi_fence *fence);
+};
+
 struct wsi_interface;
 
 #define VK_ICD_WSI_PLATFORM_MAX 6
diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index e63700e2e65..c3608f13e54 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -77,6 +77,7 @@ typedef struct wsi_display_connector {
bool active;
wsi_display_mode *current_mode;
drmModeModeInfo  current_drm_mode;
+   uint32_t dpms_property;
 #ifdef VK_USE_PLATFORM_XLIB_XRANDR_EXT
xcb_randr_output_t   output;
 #endif
@@ -124,6 +125,15 @@ struct wsi_display_swapchain {
struct wsi_display_image images[0];
 };
 
+struct wsi_display_fence {
+   struct wsi_fence base;
+   bool event_received;
+   bool destroyed;
+   uint64_t sequence;
+};
+
+static uint64_t fence_sequence;
+
 ICD_DEFINE_NONDISP_HANDLE_CASTS(wsi_display_mode, VkDisplayModeKHR)
 ICD_DEFINE_NONDISP_HANDLE_CASTS(wsi_display_connector, VkDisplayKHR)
 
@@ -271,6 +281,7 @@ wsi_display_get_connector(struct wsi_device 
*wsi_device,
drmModeConnectorPtr  drm_connector;
VkResult result;
int  m;
+   int  p;
 
if (wsi->master_fd < 0)
   return NULL;
@@ -292,6 +303,18 @@ wsi_display_get_connector(struct wsi_device 
*wsi_device,
 
connector->connected = drm_connector->connection != DRM_MODE_DISCONNECTED;
 
+   /* Look for a DPMS property */
+   for (p = 0; p < drm_connector->count_props; p++) {
+  drmModePropertyPtr prop = drmModeGetProperty(wsi->master_fd, 
drm_connector->props[p]);
+  if (!prop)
+ continue;
+  if (prop->flags & DRM_MODE_PROP_ENUM) {
+ if (!strcmp(prop->name, "DPMS"))
+connector->dpms_property = drm_connector->props[p];
+  }
+  drmModeFreeProperty(prop);
+   }
+
/* Mark all connector modes as invalid */
wsi_display_invalidate_connector_modes(wsi_device, connector);
 
@@ -677,7 +700,7 @@ wsi_display_surface_get_capabilities2ext(VkIcdSurfaceBase 
*icd_surface,
caps->currentTransform = khr_caps.currentTransform;
caps->supportedCompositeAlpha = khr_caps.supportedCompositeAlpha;
caps->supportedUsageFlags = khr_caps.supportedUsageFlags;
-   caps->supportedSurfaceCounters = 0;
+   caps->supportedSurfaceCounters = VK_SURFACE_COUNTER_VBLANK_EXT;
return ret;
 }
 
@@ -865,12 +888,20 @@ static void wsi_display_page_flip_handler(int fd, 
unsigned int frame,
wsi_display_page_flip_handler2(fd, frame, sec, usec, 0, data);
 }
 
+static void wsi_display_vblank_handler(int fd, unsigned int frame,
+   unsigned int sec, unsigned int usec, 
void *data);
+
+static void wsi_display_sequence_handler(int fd, uint64_t frame,
+ uint64_t ns, uint64_t user_data);
+
 static drmEventContext event_context = {
.version = DRM_EVENT_CONTEXT_VERSION,
.page_flip_handler = wsi_display_page_flip_handler,
 #if DRM_EVENT_CONTEXT_VERSION >= 3
.page_flip_handler2 = wsi_display_page_flip_handler2,
 #endif
+   .vblank_handler = wsi_display_vblank_handler,
+   .sequence_handler = wsi_display_sequence_handler,
 };
 
 static void *
@@ -1117,6 +1148,135 @@ bail:
 
 }
 
+static bool
+wsi_display_fence_wait(struct wsi_fence *fence_wsi,
+   bool absolute,
+   uint64_t timeout)
+{
+   co

[PATCH 09/21] radv: Add EXT_acquire_xlib_display to radv driver

[Keith Packard]

This extension adds the ability to borrow an X RandR output for
temporary use directly by a Vulkan application to the radv driver.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/amd/vulkan/Makefile.am|  7 +++
 src/amd/vulkan/meson.build|  7 +++
 src/amd/vulkan/radv_extensions.py | 11 ++-
 src/amd/vulkan/radv_wsi_display.c | 30 ++
 4 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 061b8144b88..94ece06e99e 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -81,7 +81,14 @@ AM_CPPFLAGS += \
-DVK_USE_PLATFORM_DISPLAY_KHR
 
 VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
+endif
+
+if HAVE_XLIB_LEASE
+AM_CPPFLAGS += \
+   -DVK_USE_PLATFORM_XLIB_XRANDR_EXT \
+   $(XCB_RANDR_CFLAGS)
 
+VULKAN_LIB_DEPS += $(XCB_RANDR_LIBS)
 endif
 
 if HAVE_PLATFORM_X11
diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
index b7bb1075e7d..0b92a1763a1 100644
--- a/src/amd/vulkan/meson.build
+++ b/src/amd/vulkan/meson.build
@@ -119,6 +119,13 @@ if with_platform_display
   libradv_files += files('radv_wsi_display.c')
 endif
 
+if with_xlib_lease
+  radv_deps += dep_xcb_xrandr
+  radv_flags += [
+'-DVK_USE_PLATFORM_XLIB_XRANDR_EXT',
+  ]
+endif
+
 libvulkan_radeon = shared_library(
   'vulkan_radeon',
   [libradv_files, radv_entrypoints, radv_extensions_c, vk_format_table_c],
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index b04b9bf87b0..df3325d47d4 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -83,6 +83,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHR_display',  23, 
'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_KHX_multiview', 1, '!ANDROID'),
 Extension('VK_EXT_debug_report',  9, True),
 Extension('VK_EXT_discard_rectangles',1, True),
@@ -170,12 +171,12 @@ _TEMPLATE = Template(COPYRIGHT + """
 #include "vk_util.h"
 
 /* Convert the VK_USE_PLATFORM_* defines to booleans */
-%for platform in ['ANDROID', 'WAYLAND', 'XCB', 'XLIB', 'DISPLAY']:
-#ifdef VK_USE_PLATFORM_${platform}_KHR
-#   undef VK_USE_PLATFORM_${platform}_KHR
-#   define VK_USE_PLATFORM_${platform}_KHR true
+%for platform in ['ANDROID_KHR', 'WAYLAND_KHR', 'XCB_KHR', 'XLIB_KHR', 
'DISPLAY_KHR', 'XLIB_XRANDR_EXT']:
+#ifdef VK_USE_PLATFORM_${platform}
+#   undef VK_USE_PLATFORM_${platform}
+#   define VK_USE_PLATFORM_${platform} true
 #else
-#   define VK_USE_PLATFORM_${platform}_KHR false
+#   define VK_USE_PLATFORM_${platform} false
 #endif
 %endfor
 
diff --git a/src/amd/vulkan/radv_wsi_display.c 
b/src/amd/vulkan/radv_wsi_display.c
index deaf61ce0df..d7a5956ad97 100644
--- a/src/amd/vulkan/radv_wsi_display.c
+++ b/src/amd/vulkan/radv_wsi_display.c
@@ -152,3 +152,33 @@ radv_ReleaseDisplayEXT(VkPhysicalDevice physical_device,
   >wsi_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,
+   >wsi_device,
+   dpy,
+   display);
+}
+
+VkResult
+radv_GetRandROutputDisplayEXT(VkPhysicalDevice  physical_device,
+ Display   *dpy,
+ RROutput  output,
+ VkDisplayKHR  *display)
+{
+   RADV_FROM_HANDLE(radv_physical_device, pdevice, physical_device);
+
+   return wsi_get_randr_output_display(physical_device,
+   >wsi_device,
+   dpy,
+   output,
+   display);
+}
+#endif /* VK_USE_PLATFORM_XLIB_XRANDR_EXT */
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 18/21] radv: Add new VK_MESA_query_timestamp extension to radv driver

[Keith Packard]

This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/amd/vulkan/Makefile.am| 3 +++
 src/amd/vulkan/meson.build| 8 
 src/amd/vulkan/radv_device.c  | 8 
 src/amd/vulkan/radv_extensions.py | 1 +
 4 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 94ece06e99e..86dfb0265d6 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -129,12 +129,14 @@ libvulkan_radeon_la_SOURCES = $(VULKAN_GEM_FILES)
 
 vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
 vk_android_native_buffer_xml = 
$(top_srcdir)/src/vulkan/registry/vk_android_native_buffer.xml
+vk_mesa_query_timestamp_xml = 
$(top_srcdir)/src/vulkan/registry/vk_mesa_query_timestamp.xml
 
 radv_entrypoints.c: radv_entrypoints_gen.py radv_extensions.py 
$(vulkan_api_xml)
$(MKDIR_GEN)
$(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_entrypoints_gen.py \
--xml $(vulkan_api_xml) \
--xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
--outdir $(builddir)
 radv_entrypoints.h: radv_entrypoints.c
 
@@ -144,6 +146,7 @@ radv_extensions.c: radv_extensions.py \
$(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_extensions.py \
--xml $(vulkan_api_xml) \
--xml $(vk_android_native_buffer_xml) \
+   --xml $(vk_mesa_query_timestamp_xml) \
--out $@
 
 vk_format_table.c: vk_format_table.py \
diff --git a/src/amd/vulkan/meson.build b/src/amd/vulkan/meson.build
index 0b92a1763a1..34f578476c0 100644
--- a/src/amd/vulkan/meson.build
+++ b/src/amd/vulkan/meson.build
@@ -20,10 +20,10 @@
 
 radv_entrypoints = custom_target(
   'radv_entrypoints.[ch]',
-  input : ['radv_entrypoints_gen.py', vk_api_xml],
+  input : ['radv_entrypoints_gen.py', vk_api_xml, 
vk_android_native_buffer_xml, vk_mesa_query_timestamp_xml],
   output : ['radv_entrypoints.h', 'radv_entrypoints.c'],
   command : [
-prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--outdir',
+prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
'--xml', '@INPUT3@', '--outdir',
 meson.current_build_dir()
   ],
   depend_files : files('radv_extensions.py'),
@@ -31,10 +31,10 @@ radv_entrypoints = custom_target(
 
 radv_extensions_c = custom_target(
   'radv_extensions.c',
-  input : ['radv_extensions.py', vk_api_xml, vk_android_native_buffer_xml],
+  input : ['radv_extensions.py', vk_api_xml, vk_android_native_buffer_xml, 
vk_mesa_query_timestamp_xml],
   output : ['radv_extensions.c'],
   command : [
-prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
'--out', '@OUTPUT@',
+prog_python2, '@INPUT0@', '--xml', '@INPUT1@', '--xml', '@INPUT2@', 
'--xml', '@INPUT3@', '--out', '@OUTPUT@',
   ],
 )
 
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 8ae7391c891..09c5ca8edcc 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4083,3 +4083,11 @@ radv_DebugReportMessageEXT(VkInstance _instance,
vk_debug_report(>debug_report_callbacks, flags, objectType,
object, location, messageCode, pLayerPrefix, pMessage);
 }
+
+VkResult radv_QueryCurrentTimestampMESA(VkDevice _device, uint64_t *timestamp)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+
+   *timestamp = device->ws->query_value(device->ws, RADEON_TIMESTAMP);
+   return VK_SUCCESS;
+}
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 42b8d996b6a..0e7b18dc104 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -95,6 +95,7 @@ EXTENSIONS = [
 Extension('VK_AMD_draw_indirect_count',   1, True),
 Extension('VK_AMD_rasterization_order',   1, 
'device->rad_info.chip_class >= VI && device->rad_info.max_se >= 2'),
 Extension('VK_AMD_shader_info',   1, True),
+Extension('VK_MESA_query_timestamp',  1, True),
 ]
 
 class VkVersion:
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/21] radv: Add VK_EXT_display_surface_counter to radv driver

[Keith Packard]

This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/amd/vulkan/radv_extensions.py |  1 +
 src/amd/vulkan/radv_wsi.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index df3325d47d4..048192b9e05 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -84,6 +84,7 @@ EXTENSIONS = [
 Extension('VK_KHR_display',  23, 
'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, '!ANDROID'),
 Extension('VK_EXT_debug_report',  9, True),
 Extension('VK_EXT_discard_rectangles',1, True),
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 9bdd55ef11c..2433390562b 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(>wsi_device,
+  surface,
+  pSurfaceCapabilities);
+}
+
 VkResult radv_GetPhysicalDeviceSurfaceFormatsKHR(
VkPhysicalDevicephysicalDevice,
VkSurfaceKHRsurface,
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 15/21] radv: add VK_EXT_display_control to radv driver

[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 <kei...@keithp.com>
---
 src/amd/vulkan/radv_extensions.py |   1 +
 src/amd/vulkan/radv_private.h |  11 +++-
 src/amd/vulkan/radv_wsi_display.c | 109 ++
 3 files changed, 120 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 048192b9e05..42b8d996b6a 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -85,6 +85,7 @@ EXTENSIONS = [
 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_EXT_display_control',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, '!ANDROID'),
 Extension('VK_EXT_debug_report',  9, True),
 Extension('VK_EXT_discard_rectangles',1, True),
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 1e3719bcc4f..fc6a5781847 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1647,8 +1647,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 d7a5956ad97..92d8936bba0 100644
--- a/src/amd/vulkan/radv_wsi_display.c
+++ b/src/amd/vulkan/radv_wsi_display.c
@@ -182,3 +182,112 @@ radv_GetRandROutputDisplayEXT(VkPhysicalDevice  
physical_device,
display);
 }
 #endif /* VK_USE_PLATFORM_XLIB_XRANDR_EXT */
+
+/* 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,
+>physical_device->wsi_device,
+display,
+display_power_info);
+}
+
+VkResult
+radv_RegisterDeviceEventEXT(VkDevice_device,
+   const VkDeviceEventInfoEXT  *device_event_info,
+   const VkAllocationCallbacks *allocator,
+   VkFence *_fence)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+   const VkAllocationCallbacks  *alloc;
+   struct radv_fence*fence;
+   VkResult ret;
+
+   if (allocator)
+   alloc = allocator;
+   else
+   alloc = >instance->alloc;
+
+   fence = vk_alloc(alloc, sizeof (*fence), 8,
+VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
+   if (!fence)
+   return VK_ERROR_OUT_OF_HOST_MEMORY;
+
+   fence->type = RADV_FENCE_TYPE_WSI;
+   fence->submitted = true;
+   fence->signalled = false;
+
+   ret = wsi_register_device_event(_device,
+   >physical_device->wsi_device,
+   device_event_info,
+   alloc,
+   >fence_wsi);
+   if (ret == VK_SUCCESS)
+   *_fence = radv_fence_to_handle(fence);
+   else
+   vk_free(alloc, fence);
+   return ret;
+}
+
+VkResult
+radv_RegisterDisplayEventEXT(VkDevice   _device,
+VkDisplayKHR   display,
+const VkDisplayEventInfoEXT
*display_event_info,
+const VkAllocationCallbacks*allocator,
+VkFence*_fence)
+{
+   RADV_FROM_HANDLE(radv_device, device, _device);
+
+   const VkAllocationCallbacks  *alloc;
+   struct radv_fence*fence;
+   VkResult ret;
+
+   

[PATCH 14/21] anv: add VK_EXT_display_control to anv driver

[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 <kei...@keithp.com>
---
 src/intel/vulkan/anv_extensions.py |   1 +
 src/intel/vulkan/anv_private.h |   4 ++
 src/intel/vulkan/anv_queue.c   |  59 ++---
 src/intel/vulkan/anv_wsi_display.c | 103 +
 4 files changed, 160 insertions(+), 7 deletions(-)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 32643e31045..1c6c4f8e27b 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -90,6 +90,7 @@ EXTENSIONS = [
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_display_control',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index d38dd9e4220..1d3e5fcd921 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1941,6 +1941,7 @@ enum anv_fence_type {
ANV_FENCE_TYPE_NONE = 0,
ANV_FENCE_TYPE_BO,
ANV_FENCE_TYPE_SYNCOBJ,
+   ANV_FENCE_TYPE_WSI,
 };
 
 enum anv_bo_fence_state {
@@ -1975,6 +1976,9 @@ struct anv_fence_impl {
 
   /** DRM syncobj handle for syncobj-based fences */
   uint32_t syncobj;
+
+  /** WSI fence */
+  struct wsi_fence *fence_wsi;
};
 };
 
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index c6b2e01c628..d0bfad742d7 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -320,6 +320,10 @@ anv_fence_impl_cleanup(struct anv_device *device,
case ANV_FENCE_TYPE_SYNCOBJ:
   anv_gem_syncobj_destroy(device, impl->syncobj);
   return;
+
+   case ANV_FENCE_TYPE_WSI:
+  impl->fence_wsi->destroy(impl->fence_wsi);
+  return;
}
 
unreachable("Invalid fence type");
@@ -465,11 +469,32 @@ anv_wait_for_syncobj_fences(struct anv_device *device,
uint32_t *syncobjs = vk_zalloc(>alloc,
   sizeof(*syncobjs) * fenceCount, 8,
   VK_SYSTEM_ALLOCATION_SCOPE_COMMAND);
+   uint32_t syncobjCount = 0;
if (!syncobjs)
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
for (uint32_t i = 0; i < fenceCount; i++) {
   ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
+
+  if (fence->permanent.type == ANV_FENCE_TYPE_WSI) {
+ struct anv_fence_impl *impl = >permanent;
+ bool expired = impl->fence_wsi->wait(impl->fence_wsi, true, _timeout);
+
+ VkResult result;
+
+ if (!expired) {
+result = VK_TIMEOUT;
+goto done;
+ }
+ if (!waitAll) {
+result = VK_SUCCESS;
+goto done;
+ }
+ continue;
+  done:
+ vk_free(>alloc, syncobjs);
+ return result;
+  }
   assert(fence->permanent.type == ANV_FENCE_TYPE_SYNCOBJ);
 
   struct anv_fence_impl *impl =
@@ -477,7 +502,7 @@ anv_wait_for_syncobj_fences(struct anv_device *device,
  >temporary : >permanent;
 
   assert(impl->type == ANV_FENCE_TYPE_SYNCOBJ);
-  syncobjs[i] = impl->syncobj;
+  syncobjs[syncobjCount++] = impl->syncobj;
}
 
int64_t abs_timeout_ns = 0;
@@ -499,7 +524,7 @@ anv_wait_for_syncobj_fences(struct anv_device *device,
 */
int ret;
do {
-  ret = anv_gem_syncobj_wait(device, syncobjs, fenceCount,
+  ret = anv_gem_syncobj_wait(device, syncobjs, syncobjCount,
  abs_timeout_ns, waitAll);
} while (ret == -1 && errno == ETIME && gettime_ns() < abs_timeout_ns);
 
@@ -545,14 +570,33 @@ anv_wait_for_bo_fences(struct anv_device *device,
   for (uint32_t i = 0; i < fenceCount; i++) {
  ANV_FROM_HANDLE(anv_fence, fence, pFences[i]);
 
- /* This function assumes that all fences are BO fences and that they
-  * have no temporary state.  Since BO fences will never be exported,
-  * this should be a safe assumption.
+ /* This function assumes that all fences have no temporary
+  * state.Since BO fences will never be exported, this should be a
+  * safe assumption.
   */
- assert(fence->permanent.type == ANV_FENCE_TYPE_BO);
  assert(fence->temporary.type == ANV_FENCE_TYPE_NONE);
  struct anv_fence_impl *impl = >permanent;
 
+ /* This function assumes that all fences are either BO fences or WSI
+  * fences
+  */
+
+ if (impl->type == ANV_FENCE_TYPE_WSI) {
+bool expired = impl-

[PATCH 16/21] vulkan: Define new VK_MESA_query_timestamp extension

[Keith Packard]

This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ). This
function is needed to complete the implementation of
GOOGLE_display_timing, which needs to be able to coorelate GPU and CPU
timestamps.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 include/vulkan/vulkan.h |  6 ++
 src/Makefile.am |  1 +
 src/vulkan/meson.build  |  1 +
 src/vulkan/registry/vk_mesa_query_timestamp.xml | 22 ++
 4 files changed, 30 insertions(+)
 create mode 100644 src/vulkan/registry/vk_mesa_query_timestamp.xml

diff --git a/include/vulkan/vulkan.h b/include/vulkan/vulkan.h
index d3e2e246cf3..5523eb7586f 100644
--- a/include/vulkan/vulkan.h
+++ b/include/vulkan/vulkan.h
@@ -7025,6 +7025,12 @@ VKAPI_ATTR VkResult VKAPI_CALL 
vkGetMemoryHostPointerPropertiesEXT(
 VkMemoryHostPointerPropertiesEXT*   pMemoryHostPointerProperties);
 #endif
 
+typedef VkResult (VKAPI_PTR *PFN_vkQueryCurrentTimestampMESA)(VkDevice device, 
uint64_t *timestamp);
+
+VKAPI_ATTR VkResult VKAPI_CALL vkQueryCurrentTimestampMESA(
+VkDevice_device,
+uint64_t*timestamp);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/src/Makefile.am b/src/Makefile.am
index 014ffaf3e29..74ff305d7c6 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -68,6 +68,7 @@ endif
 
 EXTRA_DIST += vulkan/registry/vk.xml
 EXTRA_DIST += vulkan/registry/vk_android_native_buffer.xml
+EXTRA_DIST += vulkan/registry/vk_mesa_query_timestamp.xml
 
 if HAVE_AMD_DRIVERS
 SUBDIRS += amd
diff --git a/src/vulkan/meson.build b/src/vulkan/meson.build
index 3908005b8a0..6ab0966b7c5 100644
--- a/src/vulkan/meson.build
+++ b/src/vulkan/meson.build
@@ -20,6 +20,7 @@
 
 vk_api_xml = files('registry/vk.xml')
 vk_android_native_buffer_xml = files('registry/vk_android_native_buffer.xml')
+vk_mesa_query_timestamp_xml = files('registry/vk_mesa_query_timestamp.xml')
 
 inc_vulkan_util = include_directories('util')
 inc_vulkan_wsi = include_directories('wsi')
diff --git a/src/vulkan/registry/vk_mesa_query_timestamp.xml 
b/src/vulkan/registry/vk_mesa_query_timestamp.xml
new file mode 100644
index 000..7fd4d974872
--- /dev/null
+++ b/src/vulkan/registry/vk_mesa_query_timestamp.xml
@@ -0,0 +1,22 @@
+
+
+
+
+VkResult 
vkQueryCurrentTimestampMESA
+VkDevice device
+uint64_t* pTimestamp
+
+
+
+
+
+
+
+
+
+
+
+
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/21] vulkan: Add EXT_direct_mode_display

[Keith Packard]

Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/vulkan/wsi/wsi_common_display.c | 17 +
 src/vulkan/wsi/wsi_common_display.h |  5 +
 2 files changed, 22 insertions(+)

diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index 2732b1dd721..5c123e6465e 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -1366,3 +1366,20 @@ wsi_display_finish_wsi(struct wsi_device *wsi_device,
   vk_free(alloc, wsi);
}
 }
+
+/*
+ * Implement vkReleaseDisplay
+ */
+VkResult
+wsi_release_display(VkPhysicalDevicephysical_device,
+struct wsi_device   *wsi_device,
+VkDisplayKHRdisplay)
+{
+   struct wsi_display   *wsi = (struct wsi_display *) 
wsi_device->wsi[VK_ICD_WSI_PLATFORM_DISPLAY];
+
+   if (wsi->master_fd >= 0 && wsi->master_fd != wsi->render_fd) {
+  close(wsi->master_fd);
+  wsi->master_fd = -1;
+   }
+   return VK_SUCCESS;
+}
diff --git a/src/vulkan/wsi/wsi_common_display.h 
b/src/vulkan/wsi/wsi_common_display.h
index b414a226293..5fbb6925e4a 100644
--- a/src/vulkan/wsi/wsi_common_display.h
+++ b/src/vulkan/wsi/wsi_common_display.h
@@ -69,4 +69,9 @@ wsi_create_display_surface(VkInstance instance,
const VkDisplaySurfaceCreateInfoKHR *pCreateInfo,
VkSurfaceKHR *pSurface);
 
+VkResult
+wsi_release_display(VkPhysicalDevicephysical_device,
+struct wsi_device   *wsi_device,
+VkDisplayKHRdisplay);
+
 #endif
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/21] anv: Add VK_EXT_display_surface_counter to anv driver [v4]

[Keith Packard]

This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.

v4: Add anv support

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_wsi.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 47993f45d41..32643e31045 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -89,6 +89,7 @@ EXTENSIONS = [
 Extension('VK_KHX_multiview', 1, True),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
+Extension('VK_EXT_display_surface_counter',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 ]
 
 class VkVersion:
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index f86d83589ea..52362adfb71 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -104,6 +104,18 @@ VkResult anv_GetPhysicalDeviceSurfaceCapabilities2KHR(
pSurfaceCapabilities);
 }
 
+VkResult anv_GetPhysicalDeviceSurfaceCapabilities2EXT(
+   VkPhysicalDevicephysicalDevice,
+   VkSurfaceKHRsurface,
+   VkSurfaceCapabilities2EXT*  pSurfaceCapabilities)
+{
+   ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
+
+   return wsi_common_get_surface_capabilities2ext(>wsi_device,
+  surface,
+  pSurfaceCapabilities);
+}
+
 VkResult anv_GetPhysicalDeviceSurfaceFormatsKHR(
 VkPhysicalDevicephysicalDevice,
 VkSurfaceKHRsurface,
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/21] vulkan: Add KHR_display extension using DRM

[Keith Packard]

This adds support for the KHR_display extension support to the vulkan
WSI layer. Driver support will be added separately.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 configure.ac|1 +
 meson.build |4 +-
 src/amd/vulkan/radv_wsi.c   |3 +-
 src/intel/vulkan/anv_wsi.c  |3 +-
 src/vulkan/Makefile.am  |7 +
 src/vulkan/Makefile.sources |4 +
 src/vulkan/wsi/meson.build  |   10 +
 src/vulkan/wsi/wsi_common.c |   19 +-
 src/vulkan/wsi/wsi_common.h |5 +-
 src/vulkan/wsi/wsi_common_display.c | 1368 +++
 src/vulkan/wsi/wsi_common_display.h |   72 ++
 src/vulkan/wsi/wsi_common_private.h |   10 +
 12 files changed, 1500 insertions(+), 6 deletions(-)
 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 8ed606c7694..46318365603 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1849,6 +1849,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/meson.build b/meson.build
index b39e2f8ab96..aeb7f5e2917 100644
--- a/meson.build
+++ b/meson.build
@@ -239,11 +239,12 @@ with_platform_wayland = false
 with_platform_x11 = false
 with_platform_drm = false
 with_platform_surfaceless = false
+with_platform_display = false
 egl_native_platform = ''
 _platforms = get_option('platforms')
 if _platforms == 'auto'
   if system_has_kms_drm
-_platforms = 'x11,wayland,drm,surfaceless'
+_platforms = 'x11,wayland,drm,surfaceless,display'
   elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
 _platforms = 'x11,surfaceless'
   else
@@ -257,6 +258,7 @@ if _platforms != ''
   with_platform_wayland = _split.contains('wayland')
   with_platform_drm = _split.contains('drm')
   with_platform_surfaceless = _split.contains('surfaceless')
+  with_platform_display = _split.contains('display')
   egl_native_platform = _split[0]
 endif
 
diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index e016e837102..9bdd55ef11c 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -41,7 +41,8 @@ radv_init_wsi(struct radv_physical_device *physical_device)
return wsi_device_init(_device->wsi_device,
   radv_physical_device_to_handle(physical_device),
   radv_wsi_proc_addr,
-  _device->instance->alloc);
+  _device->instance->alloc,
+  physical_device->local_fd);
 }
 
 void
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 6082c3dd093..f86d83589ea 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -39,7 +39,8 @@ anv_init_wsi(struct anv_physical_device *physical_device)
return wsi_device_init(_device->wsi_device,
   anv_physical_device_to_handle(physical_device),
   anv_wsi_proc_addr,
-  _device->instance->alloc);
+  _device->instance->alloc,
+  physical_device->local_fd);
 }
 
 void
diff --git a/src/vulkan/Makefile.am b/src/vulkan/Makefile.am
index 037436c1cd7..c33ac5758f7 100644
--- a/src/vulkan/Makefile.am
+++ b/src/vulkan/Makefile.am
@@ -57,6 +57,13 @@ AM_CPPFLAGS += \
 VULKAN_WSI_SOURCES += $(VULKAN_WSI_X11_FILES)
 endif
 
+if HAVE_PLATFORM_DISPLAY
+AM_CPPFLAGS += \
+   -DVK_USE_PLATFORM_DISPLAY_KHR
+
+VULKAN_WSI_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
+endif
+
 BUILT_SOURCES += $(VULKAN_WSI_WAYLAND_GENERATED_FILES)
 CLEANFILES = $(BUILT_SOURCES)
 
diff --git a/src/vulkan/Makefile.sources b/src/vulkan/Makefile.sources
index a0a24ce7de8..3642c7662c4 100644
--- a/src/vulkan/Makefile.sources
+++ b/src/vulkan/Makefile.sources
@@ -17,6 +17,10 @@ VULKAN_WSI_X11_FILES := \
wsi/wsi_common_x11.c \
wsi/wsi_common_x11.h
 
+VULKAN_WSI_DISPLAY_FILES := \
+   wsi/wsi_common_display.c \
+   wsi/wsi_common_display.h
+
 VULKAN_UTIL_FILES := \
util/vk_alloc.h \
util/vk_debug_report.c \
diff --git a/src/vulkan/wsi/meson.build b/src/vulkan/wsi/meson.build
index bd0fd3cc53e..743631a6113 100644
--- a/src/vulkan/wsi/meson.build
+++ b/src/vulkan/wsi/meson.build
@@ -57,6 +57,16 @@ if with_platform_wayland
   ]
 endif
 
+if with_platform_display
+  vulkan_wsi_args +=

[PATCH 06/21] radv: Add EXT_direct_mode_display to radv driver

[Keith Packard]

Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/amd/vulkan/radv_extensions.py |  1 +
 src/amd/vulkan/radv_wsi_display.c | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 8a079595d40..b04b9bf87b0 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -82,6 +82,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xcb_surface',   6, 
'VK_USE_PLATFORM_XCB_KHR'),
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHR_display',  23, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, '!ANDROID'),
 Extension('VK_EXT_debug_report',  9, True),
 Extension('VK_EXT_discard_rectangles',1, True),
diff --git a/src/amd/vulkan/radv_wsi_display.c 
b/src/amd/vulkan/radv_wsi_display.c
index f98a071513d..deaf61ce0df 100644
--- a/src/amd/vulkan/radv_wsi_display.c
+++ b/src/amd/vulkan/radv_wsi_display.c
@@ -141,3 +141,14 @@ radv_CreateDisplayPlaneSurfaceKHR(VkInstance   
 _instanc
 
return wsi_create_display_surface(_instance, alloc, create_info, 
surface);
 }
+
+VkResult
+radv_ReleaseDisplayEXT(VkPhysicalDevice physical_device,
+  VkDisplayKHR display)
+{
+   RADV_FROM_HANDLE(radv_physical_device, pdevice, physical_device);
+
+   return wsi_release_display(physical_device,
+  >wsi_device,
+  display);
+}
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/21] anv: Add KHR_display extension to anv

[Keith Packard]

This adds support for the KHR_display extension to the anv Vulkan
driver. The driver now attempts to open the master DRM node when the
KHR_display extension is requested so that the common winsys code can
perform the necessary operations.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/intel/Makefile.sources |   3 +
 src/intel/Makefile.vulkan.am   |   7 ++
 src/intel/vulkan/anv_device.c  |  18 -
 src/intel/vulkan/anv_extensions.py |   1 +
 src/intel/vulkan/anv_extensions_gen.py |   5 +-
 src/intel/vulkan/anv_wsi_display.c | 129 +
 src/intel/vulkan/meson.build   |   7 ++
 7 files changed, 165 insertions(+), 5 deletions(-)
 create mode 100644 src/intel/vulkan/anv_wsi_display.c

diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index 9595bf42582..6c142729d94 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -240,6 +240,9 @@ VULKAN_WSI_WAYLAND_FILES := \
 VULKAN_WSI_X11_FILES := \
vulkan/anv_wsi_x11.c
 
+VULKAN_WSI_DISPLAY_FILES := \
+   vulkan/anv_wsi_display.c
+
 VULKAN_GEM_FILES := \
vulkan/anv_gem.c
 
diff --git a/src/intel/Makefile.vulkan.am b/src/intel/Makefile.vulkan.am
index 23fa877e77d..7c428a799d7 100644
--- a/src/intel/Makefile.vulkan.am
+++ b/src/intel/Makefile.vulkan.am
@@ -187,6 +187,13 @@ VULKAN_SOURCES += $(VULKAN_WSI_WAYLAND_FILES)
 VULKAN_LIB_DEPS += $(WAYLAND_CLIENT_LIBS)
 endif
 
+if HAVE_PLATFORM_DISPLAY
+VULKAN_CPPFLAGS += \
+   -DVK_USE_PLATFORM_DISPLAY_KHR
+
+VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
+endif
+
 noinst_LTLIBRARIES += vulkan/libvulkan_common.la
 vulkan_libvulkan_common_la_SOURCES = $(VULKAN_SOURCES)
 vulkan_libvulkan_common_la_CFLAGS = $(VULKAN_CFLAGS)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 86c1bdc1d51..9614907fda3 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -277,14 +277,25 @@ anv_physical_device_init_uuids(struct anv_physical_device 
*device)
 static VkResult
 anv_physical_device_init(struct anv_physical_device *device,
  struct anv_instance *instance,
- const char *path)
+ const char *primary_path,
+ const char *render_path)
 {
VkResult result;
-   int fd;
+   int fd = -1;
+   const char *path;
 
brw_process_intel_debug_variable();
 
-   fd = open(path, O_RDWR | O_CLOEXEC);
+   if (instance->enabled_extensions.KHR_display) {
+  path = primary_path;
+  fd = open(path, O_RDWR | O_CLOEXEC);
+   }
+
+   if (fd < 0) {
+  path = render_path;
+  fd = open(path, O_RDWR | O_CLOEXEC);
+   }
+
if (fd < 0)
   return vk_error(VK_ERROR_INCOMPATIBLE_DRIVER);
 
@@ -652,6 +663,7 @@ anv_enumerate_devices(struct anv_instance *instance)
 
  result = anv_physical_device_init(>physicalDevice,
 instance,
+devices[i]->nodes[DRM_NODE_PRIMARY],
 devices[i]->nodes[DRM_NODE_RENDER]);
  if (result != VK_ERROR_INCOMPATIBLE_DRIVER)
 break;
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 581921e62a1..112dcef5bbd 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -83,6 +83,7 @@ EXTENSIONS = [
 Extension('VK_KHR_wayland_surface',   6, 
'VK_USE_PLATFORM_WAYLAND_KHR'),
 Extension('VK_KHR_xcb_surface',   6, 
'VK_USE_PLATFORM_XCB_KHR'),
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
+Extension('VK_KHR_display',  23, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, True),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
diff --git a/src/intel/vulkan/anv_extensions_gen.py 
b/src/intel/vulkan/anv_extensions_gen.py
index 33827ecd015..84d07f9767a 100644
--- a/src/intel/vulkan/anv_extensions_gen.py
+++ b/src/intel/vulkan/anv_extensions_gen.py
@@ -113,7 +113,7 @@ _TEMPLATE_C = Template(COPYRIGHT + """
 #include "vk_util.h"
 
 /* Convert the VK_USE_PLATFORM_* defines to booleans */
-%for platform in ['ANDROID', 'WAYLAND', 'XCB', 'XLIB']:
+%for platform in ['ANDROID', 'WAYLAND', 'XCB', 'XLIB', 'DISPLAY']:
 #ifdef VK_USE_PLATFORM_${platform}_KHR
 #   undef VK_USE_PLATFORM_${platform}_KHR
 #   define VK_USE_PLATFORM_${platform}_KHR true
@@ -132,7 +132,8 @@ _TEMPLATE_C = Template(COPYRIGHT + """
 
 #define ANV_HAS_SURFACE (VK_USE_PLATFORM_WAYLAND_KHR || \\
  VK_USE_PLATFORM_XCB_KHR || \\
- VK_USE_PLATFORM_XLIB_KHR)
+ VK_USE_PLATFORM_XLIB_KHR || \\
+

[PATCH 05/21] anv: Add EXT_direct_mode_display to anv driver

[Keith Packard]

Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.

Signed-off-by: Keith Packard <kei...@keithp.com>
---
 src/intel/vulkan/anv_extensions.py |  1 +
 src/intel/vulkan/anv_wsi_display.c | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 112dcef5bbd..75b6bf0b41f 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -84,6 +84,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xcb_surface',   6, 
'VK_USE_PLATFORM_XCB_KHR'),
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHR_display',  23, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_KHX_multiview', 1, True),
 Extension('VK_EXT_debug_report',  8, True),
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
diff --git a/src/intel/vulkan/anv_wsi_display.c 
b/src/intel/vulkan/anv_wsi_display.c
index 9b00d7f02e4..e6f67f7dec9 100644
--- a/src/intel/vulkan/anv_wsi_display.c
+++ b/src/intel/vulkan/anv_wsi_display.c
@@ -127,3 +127,14 @@ anv_CreateDisplayPlaneSurfaceKHR(VkInstance
_instance
 
return wsi_create_display_surface(_instance, alloc, create_info, surface);
 }
+
+VkResult
+anv_ReleaseDisplayEXT(VkPhysicalDevice physical_device,
+   VkDisplayKHR display)
+{
+   ANV_FROM_HANDLE(anv_physical_device, pdevice, physical_device);
+
+   return wsi_release_display(physical_device,
+  >wsi_device,
+  display);
+}
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/21] Add KHR_display through GOOGLE_display_timing [v2]

[Keith Packard]

Dave Airlie asked me to split these up so that the core and anv/radv
bits were all in separate patches.

There are no code changes here aside from fixing the KHR_display
version from 1 to 23. I also fixed the indentation in the changes to
the radv driver from spaces to tabs as per convention.

-keith

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel