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
Daniel Vetter writes:
> Hm, I think we should just clean up wiat_req in ->atomic_destroy_state
> instead of littering cleanup code all over. But this gets the job done, so
> applied.
Thanks. It's required for the DRM patch I posted that makes moving the
cursor not block on rendering. I'm hoping
Daniel Vetter writes:
> Hm, I can't see v1 anywhere, but I think it'd be better. You can't store
> any transient state related to the current update in struct drm_plane. In
> this case the cleanup_buffers from a previous update might overlap (for
> nonblocking atomic commits) with the prepare_pla
Daniel Vetter writes:
> We still need to clean up the reference in case of failure, which
> means latest in intel_plane_destroy_state(). Also hanging onto a
> request isn't that evil really, why can't we just only clean up in the
> destroy function?
Sticking a cleanup there as well is good insur
Daniel Vetter writes:
> Rebased onto 4.8 while applying, which did simplify the patch a lot (4.8
> is already using for_each_plane_in_state, but slightly differently).
Your rebase looks great, thanks!
--
-keith
-- next part --
A non-text attachment was scrubbed...
Name:
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
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:
> 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
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
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
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
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
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
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
Here's a first cut of the proposed mode resource leasing code. What
this does is allow an application to create a new drm_master which
"leases" resources from an existing drm_master. This new drm_master
can do whatever it likes with the resources it was granted, including
setting modes, performing
Separate out lease debugging from the core.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_drv.c | 3 ++-
include/drm/drmP.h| 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 6594b4088f11
Krh hacked up kmscube into vkcube which can run vulkan directly on kms,
but that doesn't use any of the WSI apis and VK_KHR_display
extension. Is anyone thinking that might be a good idea to do, or should
we just keep on hacking things like vkcube does?
--
-keith
signature.asc
Description: PGP
leasing objects from an owner (either
directly, or indirectly through another lessee), can be searched from
an idr in the drm_master of the owner.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/Makefile| 3 +-
drivers/gpu/drm/drm_auth.c | 22 +-
drivers/gpu/drm/drm_lease.c | 485 +
leased objects for a particular lessee
drm_mode_change_lease
Adjust the terms of a lease, adding or removing resources or
switching from masking to non-masking.
This should suffice to at least create, query and manage available
leases.
Signed-off-by: Keith Packard
---
drivers/gpu
Attempts to modify un-leased objects are rejected with an error.
Information returned about unleased objects is modified to make them
appear unusable and/or disconnected.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_atomic.c | 3 +++
drivers/gpu/drm/drm_auth.c| 2
jim.get...@hp.com
@@ -9,9 +9,7 @@
Hewlett Packard Company
Keith Packard
- keith.pack...@intel.com
-Open Source Technology Center
- Intel Corporation
+ kei...@keit
Daniel Vetter writes:
> I think it'd be good if we could consolidate all the lease checking into
> drm_mode_object_find (respectively __drm_mode_object_find). We'd need to
> wire up the fpriv to be able to do that, but we could upstream that patch
> right away before anything else. That should ta
Daniel Vetter writes:
> Should we just use fd for this? Essentially lessors would be required to
> keep track of all their pending leases, and just dup() them over to the
> client. Would reduce the uapi scope a bit, and if a lessor can't keep
> track of it's leases there's a problem.
Right now,
Daniel Vetter writes:
> Still not sure we want to restrict objects on the lessor side. Feels like
> unecessary complexity (i.e. more bugs in kernel, that's never good), and
> at best only needed for lessors who can't keep track of stuff.
It's been useful when hacking existing code, and will help
Daniel Vetter writes:
> On Sat, Apr 01, 2017 at 10:08:39AM -0700, Keith Packard wrote:
>> +BUG_ON(__mutex_owner(&master->dev->mode_config.idr_mutex) != current);
>
> Forgot to reply on this:
>
> lockdep_assert_held + enable lockdep.
Thanks. Will fix.
--
-ke
Daniel Vetter writes:
> The multi-seat thing sounds like vapourware, I think we should care about
> the vr use-case for now, and only that one.
Ok, I can live with that, even if I like the idea of a slightly more
general solution.
> For VR itself I'd go as far as saying that probably our "creat
Daniel Vetter writes:
> Hm, if you restrict getresources and getplanes, you'll get your leased
> objects query api. Iirc that part was missing in your kernel patch. And it
> gives you exaclty what you want: per-type list of object ids.
Hrm. I think that's one Dave didn't want to restrict so that
Jason Ekstrand writes:
> Interesting question. To my knowledge, no one has actually implemented the
> Vulkan WSI direct-to-display extensions. (I tried to prevent them from
> getting released with 1.0 but failed.) I believe the correct answer is to
> use the external memory dma-buf stuff that
Chad Versace writes:
> The real path forward should be implemented on top of
> VK_KHX_external_memory. If you want to start experimenting now with
> Vulkan+KMS, you may want to look at
> VK_EXTERNAL_MEMORY_HANDLE_OPAQUE_FD_KHX.
It seems like the Vulkan spec for WSI with devices has a bunch of wh
Daniel Vetter writes:
> Also if this confuses VR, then another reason why we want to make leases
> invariant and only allow pure revoke, not changing the list.
I'm not sure why you want this to be asymmetrical, nor why you would
expect lessees to be any more competent at dealing with hotplug tha
Daniel Vetter writes:
> On that, I think we could just unconditionally hand leases all encoders.
> Encoders turned out to be a bit an uapi mistake.
Well, given the complexity of hardware these days, even crtcs would
probably best have been hidden...
> Neither setcrtc nor atomic use it, the kern
Daniel Vetter writes:
> Yeah I think that's a pretty neat idea to reduce the lease complexity even
> more. If the VR compositor is unhappy and wants a different mode, it can
> simply nuke the lease and as for a new one. Forgot to say that :-)
Not sure it changes the lease complexity, but it redu
Michel Dänzer writes:
> When no such special client (Steam?) is running, the desktop environment
> will try to use the HMD anyway, right? So the expected use case would be
> for the user to start a special client first and only plug in the HMD
> afterwards? That seems a bit inconvenient.
I'd lov
Pekka Paalanen writes:
> we need some kind of a database to recognize HMDs in any case, right?
> It would be best if the database was shared, so that everyone could
> recognize all HMDs, at least as far as one can do that based on EDID.
Yeah, I think you've got some good ideas here. Here are som
Daniel Vetter writes:
> I think it'd be good if we could consolidate all the lease checking into
> drm_mode_object_find (respectively __drm_mode_object_find). We'd need to
> wire up the fpriv to be able to do that, but we could upstream that patch
> right away before anything else. That should ta
Mario Kleiner writes:
> as input from a highly interested future user of such api's:
Thanks much for taking a look at this.
> My use cases run about 98% of the time in fullscreen
> exclusive mode and want as little interference from the windowing system
> / desktop environment as possible, wi
Alex Deucher writes:
> I think there is a definite use case there.
I agree. What we're missing right now is someone interested in driving
an implementation of that use case to help define the right
interfaces. Lacking that, we're not likely to come up with a good
solution on our own. I think tha
Mario Kleiner writes:
> Great! Haven't looked at your patches yet, only at this thread and your
> blog, but this sounds all very promising.
I'll write up another blog post when I finish with the first round of
review. That should describe the kernel API at least. I think the X API
will be prett
Daniel Vetter writes:
> freedesktop.org has adopted a formal&enforced code of conduct:
Acked-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.or
"Manufacturer" : "LGD",
"Product" : 437,
"desktop" : true
}
]
"copyright" : "Copyright © 2017, Keith Packard",
"license" : "GPLv3&q
Keith Packard writes:
With the changes to the kernel interface, and discussion about how to
mask HMD outputs from X applications still ongoing, I've ripped the
grabs out of the protocol and will add whatever we come up with back at
some point.
In any case, there are just two request
e controlled by the lessor; the
'mask_lease' flag has been removed
* Checking for leased status has been simplified, replacing
the drm_lease_check function with drm_lease_held.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/Makefile
Here's a second try at mode resource leasing. The differences from v1
are mostly deleting functionality that isn't currently useful.
There are no more sub-leases; there's the owner, the owner is the only
lessor and so the only one who can create leases and hand those out.
The lessor can now manip
ned-off-by: Keith Packard
---
drivers/gpu/drm/drm_ioctl.c | 3 +
drivers/gpu/drm/drm_lease.c | 220
include/drm/drm_lease.h | 9 ++
include/uapi/drm/drm.h | 3 +
include/uapi/drm/drm_mode.h | 55 +++
5 files changed, 290 insertion
This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.
Suggested-by: Daniel Vetter
Signed-off-by: Keith Packard
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
drivers/gpu/drm/amd/amdgpu/dce_virtual.c
, we can now centralize most of the lease-based access
checks in that function.
A few places skip that API and require in-line checks.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_auth.c| 2 +-
drivers/gpu/drm/drm_connector.c | 8 +++---
drivers/gpu/drm/drm_encoder.c | 8
Separate out lease debugging from the core.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_drv.c | 3 ++-
include/drm/drmP.h| 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 6594b4088f11
Pekka Paalanen writes:
> I was under the impression that if you have a VR application running on
> the HMD, it necessarily also implies that you have a VR compositor
> running, which means that there is always some process providing a valid
> image to the HMD. (At least in end-user setups.)
Yes,
Pekka Paalanen writes:
> do you mean to list all kinds of display devices in the database? I was
> assuming it would list only HMDs, so not in database would imply it's a
> normal display and good for extending the desktop to.
I intended for it to be a general database to which we could add almo
, rather than when delievered. This way, delivery doesn't
need to have the crtc ID available.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_atomic.c | 7 ---
drivers/gpu/drm/drm_plane.c | 2 +-
drivers/gpu/drm/drm_vblank.c | 27 ---
dr
These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_internal.h | 6 ++
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu
necessary to widen that value
was already included to handle devices returning fewer than 32-bits.
This will provide the necessary datatypes for the Vulkan API.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
drivers
This patch series provides a new interface which fixes three issues
with the current VBLANK_WAIT ioctl:
1) CRTC indices to select a target.
2) 32-bits of count resolution.
3) Microsecond time resolution.
The first makes it quite difficult to use this interface from a leased
DRM device; without
This allows an application to discover what display resources are
available before requesting a lease from the X server.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm
lease' value has been removed
* change ioctl has been removed.
Changes for v3 suggested in part by Dave Airlie
* Add revoke ioctl.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_ioctl.c | 4 +
drivers/gpu/drm/drm_lease.c | 270
i
d by
removing all of the objects they have access to. The lease itself
hangs around as it's hanging off a file.
* Free the leases IDR when the master is destroyed
* _drm_lease_held should look at lessees, not lessor
* Allow non-master files to check for lease status
Signed-off-by:
Here's a third version of my DRM mode object leases series. Since v2:
* Add revocation. This allows leases to be effectively revoked by
removing all of the objects they have access to. The lease itself
hangs around as it's hanging off a file.
* Allow non-master files to lo
This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.
Suggested-by: Daniel Vetter
Signed-off-by: Keith Packard
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
drivers/gpu/drm/amd/amdgpu/dce_virtual.c
Separate out lease debugging from the core.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_drv.c | 3 ++-
include/drm/drmP.h| 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b5c6bb46a425
, we can now centralize most of the lease-based access
checks in that function.
A few places skip that API and require in-line checks.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_auth.c| 2 +-
drivers/gpu/drm/drm_connector.c | 5 +++--
drivers/gpu/drm/drm_encoder.c | 8
Dave Airlie writes:
> I think this needs a pad ^.
> And this.
Yup. Thanks!
>> +struct drm_mode_revoke_lease {
>> + /** Unique ID of lessee
>> +*/
>> + __u32 lessee_id;
>
> And this.
None of the other bare 32-bit ioctl structures are padded; I think
that's probably fine as
Daniel Vetter writes:
> Extending the reported/sw vblank counter to u64 makes sense imo, but do we
> have to extend the driver interfaces too? If there's no 64 bit hw vblank
> currently I think I'd be good to postpone that part, simply because I'm
> too lazy to audit all the drivers for correctly
Michel Dänzer writes:
> Subtle breakage here: vblwait->request.sequence must still get updated
> for _DRM_VBLANK_RELATIVE, in case we're interrupted by a signal.
Thanks for finding this.
I think it might be better to just not modify the request.type field
instead, so that on re-entry it gets re
Michel Dänzer writes:
> BTW, this got me thinking that we should probably treat
> _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating
> vblwait->request.sequence. Otherwise there could theoretically (though
> unlikely) be an infinite loop:
I was thinking that we should just r
Daniel Vetter writes:
> A few nits below, but looks good otherwise.
Thanks.
>> static struct drm_pending_vblank_event *create_vblank_event(
>> -struct drm_device *dev, uint64_t user_data)
>> +struct drm_device *dev, struct drm_crtc *crtc, uint64_t
>> user_data)
>
> Nit
Daniel Vetter writes:
> I very much like this since the old ioctl really is a rather bad horror
> show. And since it's tied in with ums drivers everything is
> complicated.
Thanks for your kind words.
> I started a discussion a while back whether these should be restricted to
> DRM_MASTER (i.e.
Ville Syrjälä writes:
> Maybe, or maybe we want to turn the interrupt on in that case? That's
> what the old ioctl does.
That's what I suggested in my reply to Daniel's review. Even if we add
the accurate function, we'll still need the interrupt-enable case as a
fallback for drivers which don't
Ville Syrjälä writes:
> I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern
> where we can avoid doing the full update more than once if we enable
> the interrupt already during the query.
Don't we still wait 5 seconds before disabling vblank? In that case, the
chances of hittin
Ville Syrjälä writes:
> With the disable_immediate thing we only wait until the next vblank
> before disabling the irq again.
Ok, still sounds like we'll be doing fine if the application does a
get immediately followed by a queue event. At least most of the time.
--
-keith
signature.asc
Desc
Pekka Paalanen writes:
> Ooh, a much much larger scope than I assumed. Nice.
Well, it's more out of a sense of fear than future planning. If all we
ever use it for is as a list of monitors that the desktop should ignore,
that'd be fine.
> That means you need an explicit key to denote HMDs. More
Pekka Paalanen writes:
> I disagree on the details, more below.
> Such a RandR request is something I would not like to have to replicate
> on Wayland. The display server contains the policy, it should not just
> expose everything up for grabs. This is a fundamental difference
> between X11 and
Mario Kleiner writes:
> Just please make sure that one (user configurable/opt-in if necessary)
> policy from the beginning is to allow leasing out any output to
> applications, not just HMDs.
That's entirely a given -- the leasing API is under the control of the
application which can lease any
Pekka Paalanen writes:
> I forget if I mentioned this to you personally yet:
> https://gist.github.com/ppaalanen/e0d2744ff71188e9a294726a37ca83c2
Thanks, that's a helpful bit of thinking. It looks like most of that is
still relevant, the only piece we'd swap out is how the bits actually
get to t
ded to gain access to the
VK_KEITHP_kms_display extension (thanks, Vulkan, for not exposing vendor
instance extensions by default)
git://people.freedesktop.org/~keithp/Vulkan-LoaderAndValidationLayers.git
drm-leases
From 06088071af2a396ce58b0490ceb228e3aa079a09 Mon Sep 17 00:00:00 2001
From: Keith
c: Daniel Vetter
cc: David Airlie
cc: intel-gfx at lists.freedesktop.org
cc: dri-devel at lists.freedesktop.org
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu
know which to
cleanup. Otherwise, failure paths and success paths would need
different tests in the cleanup code as the plane state points to
different places in the two cases.
cc: dri-devel at lists.freedesktop.org
cc: David Airlie
Signed-off-by: Keith Packard
---
drive
Dave Airlie writes:
> Hi,
>
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
>
> The standard scenario I have is
>
> CRTC 0: eDP monitor connected
>
> hotplug 30" monito
18:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(256)]
Failed to initialize command buffer.
This made it pretty easy to diagnose the problem in the referenced bug report.
Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681
Signed-off-by: Keith Packard
---
src
Matt Turner writes:
> Reviewed-by: Matt Turner
>
> Should we add a Cc: for the stable branch?
Also seems like a good plan. I've added that and pushed.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: applicat
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/
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
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
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
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
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:
> 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
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:
> 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
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
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
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
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
_
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
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:
> 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
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
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
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
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
1 - 100 of 1055 matches
Mail list logo
