Re: [Mesa-dev] Freenode fallout
On Friday, May 21st, 2021 at 1:49 AM, Lyude Paul wrote: > After considering Libera and OFTC as options, the board settled on > recommending OFTC. The primary reason for this is because OFTC is > associated with our parent foundation SPI, and has a long and well known > history of involvement with the open source community. As well, the > board believes OFTC's current Governance model is a lot more clear then > Libera's. I'd personally prefer Libera Chat. They don't yet have a published formal governance model, but I hope this will come soon. As the former Freenode staff, I trust them to make sure mistakes from the past won't be repeated. Apart from politics, Libera also offers a more modern feature set. This can ease daily usage, with features such as reliable authentication, account tracking, and many other IRC protocol improvements. OFTC has plans to eventually migrate to Solanum, but they don't have the time to do it for now. For reference, on OFTC: CAP LS 302 :kinetic.oftc.net CAP * LS :multi-prefix And on Libera: CAP LS 302 :ruthenium.libera.chat CAP * LS :account-notify away-notify chghost extended-join multi-prefix sasl=PLAIN,ECDSA-NIST256P-CHALLENGE,EXTERNAL tls userhost-in-names account-tag cap-notify echo-message solanum.chat/identify-msg solanum.chat/realhost ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
On Wednesday, April 28th, 2021 at 2:21 PM, Daniel Vetter wrote: > Yeah I think we have pretty clear consensus on that goal, just no one yet > volunteered to get going with the winsys/wayland work to plumb drm_syncobj > through, and the kernel/mesa work to make that optionally a userspace > fence underneath. And it's for a sure a lot of work. I'm interested in helping with the winsys/wayland bits, assuming the following: - We are pretty confident that drm_syncobj won't be superseded by something else in the near future. It seems to me like a lot of effort has gone into plumbing sync_file stuff all over, and it already needs replacing (I mean, it'll keep working, but we have a better replacement now. So compositors which have decided to ignore explicit sync for all this time won't have to do the work twice.) - Plumbing drm_syncobj solves the synchronization issues with upcoming AMD hardware, and all of this works fine in cross-vendor multi-GPU setups. - Someone is willing to spend a bit of time bearing with me and explaining how this all works. (I only know about sync_file for now, I'll start reading the Vulkan bits.) Are these points something we can agree on? Thanks, Simon ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
On Tuesday, April 27th, 2021 at 8:01 PM, Alex Deucher wrote: > It's an upcoming requirement for windows[1], so you are likely to > start seeing this across all GPU vendors that support windows. I > think the timing depends on how quickly the legacy hardware support > sticks around for each vendor. Hm, okay. Will using the existing explicit synchronization APIs make it work properly? (e.g. IN_FENCE_FD + OUT_FENCE_PTR in KMS, EGL_KHR_fence_sync + EGL_ANDROID_native_fence_sync + EGL_KHR_wait_sync in EGL) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach wrote: > > Ok. So that would only make the following use cases broken for now: > > > > - amd render -> external gpu > > - amd video encode -> network device > > FWIW, "only" breaking amd render -> external gpu will make us pretty > unhappy I concur. I have quite a few users with a multi-GPU setup involving AMD hardware. Note, if this brokenness can't be avoided, I'd prefer a to get a clear error, and not bad results on screen because nothing is synchronized anymore. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)
>From a user-space point-of-view, this looks super useful! The uAPI sounds good to me. Acked-by: Simon Ser Would be nice to have some short docs as well. Here's an example of a patch adding some docs for an ioctl [1], if you aren't familiar with that. I think just some basic stuff (description, which parameters are in/out, what the flags are) would be great. [1]: https://patchwork.freedesktop.org/patch/401951/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Monday, March 16, 2020 5:04 PM, Jason Ekstrand wrote: > Hopefully, that will provide some motivation for other compositors > (kwin, gnome-shell, etc.) because they now have a real user of it in > an upstream driver for a major desktop platform and not just a few > weston examples. However, someone is going to have to drive the > actual development in those compositors. I'd be very happy if more > people got involved, :-) FWIW, a wlroots pull request is in progress [0]. The plan is first to accept fence FDs from clients, then send them our fences as a second step. [0]: https://github.com/swaywm/wlroots/pull/2070 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2
> > +struct gbm_bo * > > +gbm_bo_create_with_modifiers2(struct gbm_device *gbm, > > + uint32_t width, uint32_t height, > > + uint32_t format, > > + const uint64_t *modifiers, > > + const unsigned int count, > > + uint32_t flags); > > Declaration here says 'flags' while definition says 'usage'. Yeah, I tried to be consistent with gbm_bo_create, which sometimes uses flags and sometimes usage. I'm not sure which terminology is better. I guess flags would be more appropriate since the enum is called gbm_bo_flags? > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did > have usage at first but it was removed during the review. I'm having > trouble digging what was the reason for this? I'm not sure either. Daniel said it was a mistake. Adding the 63bd2ae7452d4 folks to the discussion. Ben, do you remember the details? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2
gbm_{bo,surface}_create_with_modifiers is missing the usage flags. Add a new
function which lets library users specify it.
Signed-off-by: Simon Ser
---
src/gbm/main/gbm.c | 38 ++
src/gbm/main/gbm.h | 17 +
2 files changed, 55 insertions(+)
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 38480ca966c6..ca68a3292327 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -491,6 +491,27 @@ gbm_bo_create_with_modifiers(struct gbm_device *gbm,
return gbm->bo_create(gbm, width, height, format, 0, modifiers, count);
}
+GBM_EXPORT struct gbm_bo *
+gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
+ uint32_t width, uint32_t height,
+ uint32_t format,
+ const uint64_t *modifiers,
+ const unsigned int count,
+ uint32_t usage)
+{
+ if (width == 0 || height == 0) {
+ errno = EINVAL;
+ return NULL;
+ }
+
+ if ((count && !modifiers) || (modifiers && !count)) {
+ errno = EINVAL;
+ return NULL;
+ }
+
+ return gbm->bo_create(gbm, width, height, format, usage, modifiers, count);
+}
+
/**
* Create a gbm buffer object from a foreign object
*
@@ -616,6 +637,23 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
modifiers, count);
}
+GBM_EXPORT struct gbm_surface *
+gbm_surface_create_with_modifiers2(struct gbm_device *gbm,
+ uint32_t width, uint32_t height,
+ uint32_t format,
+ const uint64_t *modifiers,
+ const unsigned int count,
+ uint32_t flags)
+{
+ if ((count && !modifiers) || (modifiers && !count)) {
+ errno = EINVAL;
+ return NULL;
+ }
+
+ return gbm->surface_create(gbm, width, height, format, flags,
+ modifiers, count);
+}
+
/**
* Destroys the given surface and frees all resources associated with
* it.
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 9b5288710a5b..0bb2e4443f97 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -263,6 +263,15 @@ gbm_bo_create_with_modifiers(struct gbm_device *gbm,
uint32_t format,
const uint64_t *modifiers,
const unsigned int count);
+
+struct gbm_bo *
+gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
+ uint32_t width, uint32_t height,
+ uint32_t format,
+ const uint64_t *modifiers,
+ const unsigned int count,
+ uint32_t flags);
+
#define GBM_BO_IMPORT_WL_BUFFER 0x5501
#define GBM_BO_IMPORT_EGL_IMAGE 0x5502
#define GBM_BO_IMPORT_FD0x5503
@@ -390,6 +399,14 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
const uint64_t *modifiers,
const unsigned int count);
+struct gbm_surface *
+gbm_surface_create_with_modifiers2(struct gbm_device *gbm,
+ uint32_t width, uint32_t height,
+ uint32_t format,
+ const uint64_t *modifiers,
+ const unsigned int count,
+ uint32_t flags);
+
struct gbm_bo *
gbm_surface_lock_front_buffer(struct gbm_surface *surface);
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
