he 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
omplete 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/ws
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
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
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
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 li
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 decid
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
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 quir
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
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
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 |
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
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_ext
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
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 **obj
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) {
>
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
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
ion 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 |
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 togethe
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
_
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 t
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
> thi
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 qu
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
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 th
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.
> Wit
AX2 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 Pack
AX2 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/vul
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 s
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
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
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 fi
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/
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
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
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 timestam
x27;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/v
This extension fetches the current GPU timestamp from the hardware,
just like the OpenGL API glGetInteger64v(GL_TIMESTAMP, ×tamp)
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
x27;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/v
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). 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
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, wh
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
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
Jason Ekstrand writes:
>> + if (allocator)
>> + alloc = allocator;
>> + else
>> + alloc = &device->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 co
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
signat
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, a
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
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-s
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.fre
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 return
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
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
vkGetPhysicalD
space 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/v
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 |
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
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/
xtra 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 +
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/
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
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.o
e 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_co
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 pat
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 disp
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 minute
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
(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 implemen
-by: Keith Packard
---
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
"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 r
ent.
>
> Signed-off-by: Charles Lohr
This seems like a reasonable idea to me.
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
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 i
Jason Ekstrand writes:
> On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard 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 m
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 o
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 answerin
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 a
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
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 changi
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 nod
This adds support for the VK_GOOGLE_display timing extension.
Signed-off-by: Keith Packard
---
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
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). 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
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
---
configure.ac| 32 +++
meson.build | 17
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
---
src/intel/Makefile.vulkan.am | 7 +++
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan
This adds support for the VK_GOOGLE_display timing extension.
Signed-off-by: Keith Packard
---
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
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
---
src/vulkan/wsi/wsi_common.c | 11 +++
src/
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
---
src/vulkan/wsi/wsi_common.h | 9 ++
src/vulkan/wsi/wsi_common_display.c
familiar with those systems and
should not require any additional device-specific code.
Signed-off-by: Keith Packard
---
src/vulkan/wsi/wsi_common.c | 254 +++-
src/vulkan/wsi/wsi_common.h | 24
src/vulkan/wsi/wsi_common_display.c | 143
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
---
src/amd/vulkan/Makefile.am| 7 +++
src/amd/vulkan/meson.build| 7 +++
src/amd/vulkan/radv_extensions.py
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). 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
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
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_private.h | 11
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_private.h | 4
This extension adds a single function to query the current GPU
timestamp, just like glGetInteger64v(GL_TIMESTAMP, ×tamp). 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
Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.
Signed-off-by: Keith Packard
---
src/vulkan/wsi/wsi_common_display.c | 17 +
src/vulkan/wsi/wsi_common_display.h | 5 +
2 files changed, 22 insertions(+)
diff --git
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
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_wsi.c | 12
2 files changed
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
---
configure.ac|1 +
meson.build |4 +-
src/amd/vulkan/radv_wsi.c |3
Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.
Signed-off-by: Keith Packard
---
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
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
---
src/intel
Add support for the EXT_direct_mode_display extension. This just
provides the vkReleaseDisplayEXT function.
Signed-off-by: Keith Packard
---
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
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.
-kei
1 - 100 of 1055 matches
Mail list logo
