Michel Dänzer writes:
> I assume 2. refers to the case of a single late frame, where the next
> frame hitting the original absolute target would result in a second
> visible stutter. While writing
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234
> , it occurred
Austin Shafer writes:
> I'm just curious if there is a technical reason why blending isn't
> allowed, as the vulkan spec seems to permit it.
Just not implemented yet.
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
Michel Dänzer writes:
> Should this extension specify how it interacts with the various
> VK_PRESENT_MODE_* modes?
Yes. It needs to be clear on how this extension interacts with all
existing display stuff. Thanks for pointing out one pretty important
interaction.
> For one example: With
Michel Dänzer writes:
> I think at least the following needs to happen first:
>
> * At least a prototype of plumbing through this information to the
> amdgpu kernel driver (or another one which may grow VRR support) and
> making use of it for adjusting the refresh periods to allow hitting
> the
Michel Dänzer writes:
> With variable refresh rate, it could certainly be useful for the kernel
> to have this information as early as possible. It shouldn't make any
> difference with fixed refresh though, since the kernel should always be
> able to hit the next refresh in that case as long as
Michel Dänzer writes:
>> actual_period = n * r - ε
>
> Is that still an issue if the (minimal) length of a vertical blanking
> period is subtracted from the computed period?
What you're doing is defining a 'window' of times which match the
desired frame -- any time within 'length of vertical
Michel Dänzer writes:
> Hmm, I didn't fully realize this in my reading of the draft, thanks
> Matias for pointing it out!
>
> That the timing of frame N+1 has to be specified when submitting frame
> N for presentation is odd to me TBH. While I can imagine this might be
> suitable for some apps
"Matias N. Goldberg" writes:
> I read your article.
Thanks!
> What I feel are missing are just minor pesky details:
Yes, it's definitely a rough draft at best. Figuring out the right words
to make it do precisely what we want is hard, and I'm hoping we can
first figure out what we want, then
Michel Dänzer writes:
> Instead of rounding to the nearest upcoming frame, should it round to
> the earliest frame after the specified period has passed? As written, it
> seems to contradict the next paragraph below:
Sorry for the poor wording; let me describe what I want informally here.
For
I spent some time over the last week experimenting with a different way
of doing frame timing.
Instead of specifying *when* a particular frame should be displayed, how
about we specify how *long* a particular frame should be made visible
to the user?
This has a couple of advantages over the
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
Eric Engestrom writes:
> Fixes: da997ebec92942193955 "vulkan: Add KHR_display extension using DRM
> [v10]"
> Cc: Keith Packard
> Signed-off-by: Eric Engestrom
Reviewed-by: Keith Packard
I checked to ensure that this is sufficient to clean all allocated
objects:
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
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
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
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
___
mesa-dev mailing list
mesa-dev@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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
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
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
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
>
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
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
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
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
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.
>
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
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
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/
Eric Engestrom writes:
> - struct list_head connectors;
> + struct list_head connectors; /* list of all discovered
> connectors */
Yeah, definitely not the list of all connectors.
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP
Eric Engestrom writes:
> Signed-off-by: Eric Engestrom
(I'll have to let someone familiar with the formats and modifiers stuff
review this one; I'm not comfortable with that at all).
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev
Eric Engestrom writes:
> + /* if there's a plane is active on the connector's crtc, pick it */
> + for (size_t i = 0; i < plane_res->count_planes; i++) {
> + drmModePlane *plane = drmModeGetPlane(wsi->fd, plane_res->planes[i]);
> + if (!plane)
> + continue;
I think you can
Eric Engestrom writes:
> Instead of setting it up when the swapchain is presented, set it up when
> creating the swapchain. This means that multiple swapchains might use
> the same crtc, but only one can be active at a time, and the connectors
> are now refcounted.
>
> This is necessary for the
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
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
v2
Here's an updated version of the extension to get GPU timestamps. This
version returns both CPU and GPU timestamps which could (in theory) be
more tightly correlated than just getting the time of one and then the
other sequentially. The idea is that we'd eventually add a suitable
kernel ioctl to
of our backends
use CLOCK_MONOTONIC, so there's nothing actually doing
conversions, but it seemed best to put the infrastructure in
place so that I could validate the extension interface would
work if that became necessary.
Signed-off-by: Keith Packard
---
include
and
surface timestamps.
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 | 30 ++
4 files changed, 47
Jason Ekstrand writes:
> 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
of our backends
use CLOCK_MONOTONIC, so there's nothing actually doing
conversions, but it seemed best to put the infrastructure in
place so that I could validate the extension interface would
work if that became necessary.
Signed-off-by: Keith Packard
---
include
and
surface timestamps.
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 | 30 ++
4 files changed, 47
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
v2
Jason Ekstrand writes:
> Is this the same thing that happens on VT switch? If so, we may want to
> return SURFACE_LOST for leases and OUT_OF_DATE for things running directly
> on the display.
No, on VT switch, my code currently sits in the driver and waits for the
VT to return. The errors here
to
get another lease and create a new surface for that.
Signed-off-by: Keith Packard
Cc: Jason Ekstrand
---
src/vulkan/wsi/wsi_common_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/vulkan/wsi/wsi_common_display.c
b/src/vulkan/wsi
Danylo Piliaiev writes:
> Thanks, then should this dependency be expressed in autoconf and
> meson?
Yup; looks like we missed a step.
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Danylo Piliaiev writes:
> Hello Keith,
>
> I am not able to build Mesa after this patch:
>
> wsi/wsi_common_display.c:991:4: error: unknown field ‘sequence_handler’
> specified in initializer
> .sequence_handler = wsi_display_sequence_handler,
Sounds like you need a newer libdrm that
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
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
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
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
Bas Nieuwenhuizen writes:
> Reviewed-by: Bas Nieuwenhuizen
>
> Thanks!
Thanks to you as well; I've rebased and pushed to master.
Two down, two to go (extensions that is)
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing
Jason Ekstrand writes:
>> Looks good. With that, patches 1-3 are
>
> Reviewed-by: Jason Ekstrand
Thanks.
> I'll let Dave or Bas review your fence hackery in radv.
Sounds fine. I'll prod them if I don't get any response in the next day
or so.
--
-keith
signature.asc
Description: PGP
Jason Ekstrand writes:
>> + if (!ret)
>> + return VK_SUCCESS;
>> +
>> + if (errno != ENOMEM) {
>
> This strikes me as a bit odd. What does ENOMEM mean if not "out of
> memory"?
ENOMEM means that the queue is full and that we should drain it and try
again; that's what the
Jason Ekstrand writes:
>> + fence = vk_alloc2(>instance->alloc, allocator, sizeof (*fence),
>> 8,
>> + VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
>
> zalloc?
Yes, definitely. Thanks for catching this. Updated and pushed the series.
--
-keith
signature.asc
Description: PGP
Jason Ekstrand writes:
>> + /* Look for a DPMS property if we haven't already found one */
>> + for (int p = 0; connector->dpms_property == 0 && p <
>> drm_connector->count_props; p++) {
>
> I'm guessing this is well over 80 characters
Sorry I missed this -- I haven't managed to configure
: wsi_register_display_event and wsi_register_device_event now
use the default allocator when NULL is provided, so remove the
computation of 'alloc' here.
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_private.h | 4 ++
src/intel/vulkan
function order in the file to place
routines in an easier to find order.
Suggested-by: Jason Ekstrand
v7:
Adapt to API changes for surface_get_capabilities
v8:
Use wsi->alloc in register_display_event so that callers
don't have to dig out an allocator for us.
Signed-off-by: Ke
and wsi_register_device_event now
use the default allocator when NULL is provided, so remove the
computation of 'alloc' here.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_device.c | 70 -
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_private.h | 1
.
Signed-off-by: Keith Packard
Reviewed-by: Jason Ekstrand
---
src/intel/vulkan/anv_queue.c | 108 +--
1 file changed, 90 insertions(+), 18 deletions(-)
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 6fe04a0a19d..6e275629e14 100644
Here's the latest version of this series with only a few minor
changes. It adapts to the API changes for surface_get_capabilities and
changes how the allocator is found for fences.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
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,
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:
> I just sent a v2 which allocates a temporary array, calls properties2, and
> then copies it back over. It doesn't duplicate the iteration code and
> instead just leverages propertie2. On the down side, it's a bit more
> allocation and data motion but, compared to the
Jason Ekstrand writes:
All looks good to me.
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Eric Engestrom writes:
> On Tuesday, 2018-06-19 16:06:14 -0700, Keith Packard wrote:
>> When VK_USE_PLATFORM_XLIB_XRANDR_EXT is defined, vulkan.h includes
>> X11/extensions/Xrandr.h for the RROutput typedef which is used in
>> the vkGetRandROutputDisplayEXT interface.
>
Jason Ekstrand writes:
> You can have a full reviewed-by
You're too kind :-)
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
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
Jason Ekstrand writes:
> They're being used as helpers and they're actually kind-of nice for
> that.
Sounds good. I hadn't actually looked at the details; just saw the
functions going away in the initializers.
--
-keith
signature.asc
Description: PGP signature
're good to go. With the addition of the
explicit initialization, this patch is
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Jason Ekstrand writes:
> Thoughts?
You've looked at the code more closely than I have; please feel free to
leave it if you think it would seem worse as separate functions.
--
-keith
signature.asc
Description: PGP signature
___
mesa-dev mailing
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,
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
Jason Ekstrand writes:
> Sometimes the best way to review a patch is with another patch. :-) I'm
> not sure what you think of this approach but I didn't really relish the
> idea of having 3 get_capabilities entrypoints. With these two patches,
> we're now down to one. In order to implement
Jason Ekstrand writes:
> Instead, we can just use get_capabilities2. This way back-ends only
> have to implement one hook.
Yeah, this looks nice. Are you going to remove the unused functions at
some point?
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP sig
style you pick, but I think they should be the
same. I have a mild preference for the second style as I think it's
easier to read the code without all of the conditionals.
As for the actual implementation of each function, it looks good, so
I'll actually mark this as
Reviewed-by: Keith Packard
.
We don't need to link against the library as we don't use any
functions from there, so don't add the _LIBS value in the autotools
build.
Signed-off-by: Keith Packard
---
configure.ac | 2 ++
meson.build | 2 ++
src/amd/vulkan/Makefile.am | 3 ++-
src/amd/vulkan
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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
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
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
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
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
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
-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
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
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
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
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
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
Jason Ekstrand writes:
>> Signed-off-by: Keith Packard
>>
>> fixup for acquire
>>
>> fixup for RROutput type
>>
>> Signed-off-by: Keith Packard
>>
>> fixup
>>
>
> Lots of "fixup". Did you mean to actually c
Jason Ekstrand writes:
>> Signed-off-by: Keith Packard
>>
>> fixup
>>
>
> Did you mean to leave this in here?
Nope; just rebasing/squashing noise. I noticed this in passing and have
already removed it.
--
-keith
signature.
ghtly earlier in the function.
Also, close the DRM master FD when the driver is being shut down.
v2:
Use anv_gem_get_param to detect working master_fd
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_device.c | 34 --
1 file changed, 16 insertions(+), 18 deletio
Jason Ekstrand writes:
> I'm trusting that not much changed other than what was explicitly called
> out. I didn't want to re-read in *that* much detail again. :-)
You are correct, all of the changes from the previous patch were listed
in the commit message.
> Reviewed-by: Jason Ekstrand
1 - 100 of 290 matches
Mail list logo
