profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/AlonzoTG/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

AlonzoTG/7-billion-humans-solutions 0

Solutions for the game 7 Billion Humans

AlonzoTG/palindromes23 0

Some useless number theory code to find the elusive dual palindromes in binary and Ternary.

AlonzoTG/Vulkan-Docs 0

The Vulkan API Specification and related tools

AlonzoTG/VulkanSharp 0

Open source .NET binding for the Vulkan API

PR closed KhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

Hi, this pull request is the continuation of the work started by Drew Devault and by Lubosz Sarnecki and superseded both #1001 and #1450

I rebased the patch against main and upgraded the protocol drm_lease_v1 by Xaver Hugl to the latest version (staging). I will go through the issues that were raised on #1001 and #1450 to get the merge request in a good shape.

I will also take care of the Mesa 2 3 and Monado 4 5 implementation, I'll update the status of the merge request in time.

This is my first contribution to a Vulkan extensions, your patience will be greatly appreciated.

+141 -4

16 comments

6 changed files

bl4ckb0ne

pr closed time in 10 hours

PR opened KhronosGroup/Vulkan-Docs

Add VK_EXT_acquire_drm_display

This pull request is a continuation of the work done in https://github.com/KhronosGroup/Vulkan-Docs/pull/1525, where it was discussed that instead of having a Wayland-centered approach to DRM leasing to handle VR headset (see #1001 and #1450), we would change the design to have a more generic FD-based approach.

I will start the implementation in Mesa as soon as the first feedback comes.

On another note, the CI is currently failing on this, I have a patch for it.

+103 -3

0 comment

6 changed files

pr created time in 10 hours

pull request commentKhronosGroup/Vulkan-Docs

Fix some -> markup and stuff

@oddhack pls merge before it has conflicts again.

krOoze

comment created time in 12 hours

issue openedKhronosGroup/Vulkan-Docs

Build acceleration VU contains "may"

> [[VUID-{refpage}-pInfos-03767]]
For each element of pname:pInfos, if its pname:mode member is
ename:VK_BUILD_ACCELERATION_STRUCTURE_MODE_UPDATE_KHR, then for each
sname:VkAccelerationStructureGeometryKHR structure referred to by its
pname:pGeometries or pname:ppGeometries members, if pname:geometryType
is ename:VK_GEOMETRY_TYPE_TRIANGLES_KHR, if its
pname:geometry.triangles.transformData member was not NULL when
pname:srcAccelerationStructure was last built, then it may not be NULL

May there at the end. Possibly a duplicate of VUID-{refpage}-pInfos-03766?

Plus bad markup for NULL and not sure if NULL is even appropriate as it looks like a VkBuffer. Generally it is kinda hard to read and not sure what it says.

created time in 12 hours

issue closedKhronosGroup/Vulkan-Docs

Task list for VK_EXT_vertex_input_dynamic_state release

One of the states that contributes to the combinatorial explosion of pipeline state objects that need to be created, is the vertex input binding and attribute descriptions. By allowing them to be dynamic applications may reduce the number of pipeline objects they need to create.

This extension adds dynamic state support for what is normally static state in VkPipelineVertexInputStateCreateInfo.

The task list for the VK_EXT_vertex_input_dynamic_state release is:

  • [x] Vulkan Specification: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_vertex_input_dynamic_state.html
  • [x] Conformance tests released: https://github.com/KhronosGroup/VK-GL-CTS/releases/tag/vulkan-cts-1.2.6.1
  • [x] SDK released: Vulkan SDK 1.2.176.0
    • [x] Validation layer: https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/2725

As each component is made public, the task will be checked off. When all tasks have been completed this issue will be closed and the extension will be fully released.

closed time in 13 hours

pdaniell-nv

issue commentKhronosGroup/Vulkan-Docs

Task list for VK_EXT_vertex_input_dynamic_state release

Task list complete, closing.

pdaniell-nv

comment created time in 13 hours

issue commentKhronosGroup/Vulkan-Docs

Task list for VK_EXT_vertex_input_dynamic_state release

NVIDIA beta driver support can be found here: https://developer.nvidia.com/vulkan-driver

pdaniell-nv

comment created time in 13 hours

issue openedKhronosGroup/Vulkan-Docs

Task list for VK_EXT_provoking_vertex release

When flat shading, one of the vertices in a primitive supplies the flat-shaded attribute value. This vertex is known as the provoking vertex. Vulkan and some other APIs use a first-vertex convention, while OpenGL ES uses a last-vertex convention, and OpenGL supports both (last-vertex is default).

This extension allows changing the provoking vertex convention between Vulkan’s default convention (first vertex) and OpenGL’s convention (last vertex). It is intended for use by API-translation layers that implement APIs like OpenGL on top of Vulkan and need to match the source API’s provoking vertex convention. Applications using Vulkan directly should use Vulkan’s default convention.

When transform feedback is available, this extension also provides more guarantees about the order that vertices within a primitive will be written to transform feedback buffers, so that flat shading can be preserved through transform feedback cycles.

The task list for the VK_EXT_provoking_vertex release is:

  • [x] Vulkan Specification: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_provoking_vertex.html

  • [ ] Conformance tests released: <!-- link(s) to VK-GL-CTS GitHub releases -->

  • [ ] SDK released: <!-- link to SDK (list version number) -->

    • [ ] Validation layer: <!-- link to Vulkan-ValidationLayers GitHub pull request -->
  • [ ] Vulkan Guide: <!-- Link to Vulkan-Guide chapter -->

As each component is made public, the task will be checked off. When all tasks have been completed this issue will be closed and the extension will be fully released.

created time in 14 hours

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

Up to you on where to draft it. I find it's easier to track history if it stays in the same pull request. It's not uncommon for extensions to be heavily rewritten in the same pull request just to preserve the conversation.

I'm not clear what action you're suggesting on the X extension. I agree the new extension supersedes its functionality, but obsolete extensions can't be removed from the API if they're in use. This is why I advocate so strongly against unnecessary iteration. Of course new code should be directed at the new API if it doesn't need to support older X11 drivers.

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

I'll start drafting the API tomorrow, how do you want to tackle the issue @cubanismo? Should I close this pull request? And should I take care of retiring the X-based extension?

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

No - I'm saying more that the X-based system becomes obsolete once an FD-based mechanism is available.

OK, understood. I still think the FD-based approach is the right design direction. I'm all for generalization.

bl4ckb0ne

comment created time in a day

CommitCommentEvent

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

Why is that? Are you saying it wouldn't be technically feasible to implement the Xrandr VK extension on top of the FD-based import mechanism + wayland protocol? If so, why?

No - I'm saying more that the X-based system becomes obsolete once an FD-based mechanism is available.

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

I think that a FD based approach would necessitate the simultaneous deprecation of the Xrandr vk extension

Why is that? Are you saying it wouldn't be technically feasible to implement the Xrandr VK extension on top of the FD-based import mechanism + wayland protocol? If so, why?

Also, can you speak a bit more to the specific scenario your clients are facing when they will need more control over DRM leases?

Consider a bundle of Vulkan renderer processes that each want to control individual displays on a single GPU directly, much like the VR use case but with no "desktop." A master process would hold the DRM primary status and hand out leases to the child processes. There's no need for composition, so there's no need for a wayland compositor or X11 instance in this scenario.

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

Do you still want to be listed as the primary contact for this extension?

Yeah, I should still be listed here. I'm not participating directly but I am still overseeing the work (@bl4ckb0ne is working on sourcehut's behalf).

I explained why the design considerations for that extension were different above: Basically NVIDIA wanted to be able to use our internal KMS API with X11, so we needed more abstraction. This extension likely ends up with "DRM" in the name either way, so that's not going to be a consideration here.

I understand that this is not going to be an issue here, but just to be clear, I have very little patience for listening to Nvidia's concerns regarding their private driver implementation. It's just that: private. If you want a spot on the Linux graphics table, then please join us on our terms, not yours. This extension is designed with the open source graphics stack in mind.

I don't think it's going to be a huge delta in client code either way (not that Vulkan has historically raised minimal lines of client code over other design principles) and the FD-based approach makes the extension more flexible. We've already heard from a few customers who want to do their own custom thing with DRM leases. We'll just end up defining the more flexible version soon if we can't agree on it now, making the wayland-specific one redundant functionality we'll have to support forever.

Yeah, I understand. I think that a FD based approach would necessitate the simultaneous deprecation of the Xrandr vk extension, which increases the scope of the proposal, discussion, and bikeshedding potential considerably. If you think we should push for that, then I'm not entirely opposed to it, but I'm also not opposed to moving forward with this proposal now and deprecating it alongside the Xrandr extension if and when a more general proposal comes to the table.

Also, can you speak a bit more to the specific scenario your clients are facing when they will need more control over DRM leases?

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

Thanks for chiming in Drew. While you're engaged, just want to ask: Do you still want to be listed as the primary contact for this extension? Fine by me either way, just wanted to check since I noticed it while reviewing and understood you hadn't been actively involved for a while.

This mirrors the approach used for X11 with the Xrandr leasing extension,. so there is prior art. There are other parts of VkDisplay which incorporate the Wayland display directly into Vulkan, so this design is not unusual.

I explained why the design considerations for that extension were different above: Basically NVIDIA wanted to be able to use our internal KMS API with X11, so we needed more abstraction. This extension likely ends up with "DRM" in the name either way, so that's not going to be a consideration here.

An fd-based approach would also work, and I understand your comments in favor of it. I'm not opposed to this, but I think that it's not any more or less effective than this design, and this design more closely mirrors the code that a Vk client may already have in place (or will add alongside) for X11 support.

I don't think it's going to be a huge delta in client code either way (not that Vulkan has historically raised minimal lines of client code over other design principles) and the FD-based approach makes the extension more flexible. We've already heard from a few customers who want to do their own custom thing with DRM leases. We'll just end up defining the more flexible version soon if we can't agree on it now, making the wayland-specific one redundant functionality we'll have to support forever.

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

Hiya, original author of the VK ext proposal here.

This mirrors the approach used for X11 with the Xrandr leasing extension,. so there is prior art. There are other parts of VkDisplay which incorporate the Wayland display directly into Vulkan, so this design is not unusual.

An fd-based approach would also work, and I understand your comments in favor of it. I'm not opposed to this, but I think that it's not any more or less effective than this design, and this design more closely mirrors the code that a Vk client may already have in place (or will add alongside) for X11 support.

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

I'm not disputing wayland needs to be involved in the case of an application leasing a display from a wayland compositor. My question is why do wayland structures need to be baked into the Vulkan extension?

My understanding of the FD-based design is an application would use the wayland protocol to obtain a lease FD from the wayland compositor, then pass it into Vulkan to make use of the leased display there. However, if someone wanted to use it without wayland, it could also acquire a lease FD from some other DRM-master source. How is that in conflict with VR, compositor, or any other use cases? What is overly complex about the design of it?

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

The FD-based extension would miss the point, the specific use case here is VR. Not any kind of display. I feel it would be too complex to make a generic FD extension that satisfies everybody (compositors, VR, etc).

The wayland compositor is the DRM master, it needs to agree to lease some of its display, it needs to be involved.

bl4ckb0ne

comment created time in a day

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

Can you be more specific about which cases you feel would not be covered by the FD-based extension? By nature of the Vulkan design, the system integration portions of which abstract native platform APIs to provide some useful common functionality, some wrapping of libdrm is necessary. It seems like the FD-based extension would be a more minimal wrapper than the wayland structure-based one, which seems advantageous to me, rather than a negative.

bl4ckb0ne

comment created time in 2 days

issue openedKhronosGroup/Vulkan-Docs

`VkCuFunctionCreateInfoNVX::pName` should be a `null-terminated` string

The pName string member of VkCuFunctionCreateInfoNVX lacks a len="null-terminated" annotation, leading to our binding generator failing to understand how long the pointed-to array is supposed to be. I believe this should be treated like any other string (char*) in vk.xml, null-terminated instead of fixed length?

https://github.com/KhronosGroup/Vulkan-Docs/blob/dfe3bcd0e1b7239e2d6ae8b6afe563780a711854/xml/vk.xml#5820:

        <type category="struct" name="VkCuFunctionCreateInfoNVX">
            <member values="VK_STRUCTURE_TYPE_CU_FUNCTION_CREATE_INFO_NVX"><type>VkStructureType</type> <name>sType</name></member>
            <member>const <type>void</type>* <name>pNext</name></member>
            <member><type>VkCuModuleNVX</type>          <name>module</name></member>
            <member>const <type>char</type>*            <name>pName</name></member>
        </type>

created time in 2 days

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

I think the extension solves a very specific problem, handling leased DRM resources for wayland, instead of proposing a generic, and often not complete enough, solution to a bigger set of problems. The FD-based import extension has its reason to exist, but it will not cover all of the cases at first and it will end up being a wrapper of libdrm as an extension. Which is not something I'm too fond of.

bl4ckb0ne

comment created time in 2 days

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

This doesn't seem to address my comments on either of the two prior instances of this series. I still don't see a good reason to tie this to wayland specifically. It seems like at this point the API would be better served by a simple lease FD import, perhaps supplemented by a correlation API in a separate extension at some point, leaving the protocol out of Vulkan to the extent possible.

The only reasonable rebuttal to this I've seen thus far seems to boil down to "We've already gone too far down this road, we need to ship," which given the rate at which this has been actually pushed, not to mention the small amount of code required to implement either direction, doesn't seem like a real concern. The only other reason I could see to pursue a solution that puts the protocol inside the driver is to abstract which protocol and permissions transfer mechanism would be used. That's why we went that direction for the X11 version, and when the wayland protocol was still experimental, that would have made sense if the extension didn't directly re-use the wayland protocol structs anyway, which is why I originally pushed to divorce the two APIs a bit more in the other direction (Hide more in the driver, not less) but I see no valid reason for this with the present design and solidified Wayland protocol. What we have here is seemingly the worst of both worlds.

Is anyone actually opposed to an FD-based import direction from a design point of view? The design benefits seem very clear to me.

bl4ckb0ne

comment created time in 2 days

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

@oddhack CI is passing and the commit is rebased on top of main, I'm will update the status to ready for review.

bl4ckb0ne

comment created time in 2 days

Pull request review commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

+[open,refpage='vkWaylandDrmLeaseDisplayEXT',desc='Gives access to a VkDisplayKHR using Wayland DRM lease',type='protos']+--++To acquire permission to directly lease a display in Vulkan from a Wayland+compositor, call:++include::{generated}/api/protos/vkWaylandDrmLeaseDisplayEXT.txt[]++  * pname:physicalDevice is the handle to the physical device the display is on.+  * pname:display A code:wl_display associated with the Wayland compositor that+    the application wishes to acquire the display(s) from.+  * pname:leaseDevice A wp_drm_lease_device_v1 connected to the Wayland compositor+    that associated with the connectors.+  * pname:pConnectorCount The number of valid pointers in the pname:pConnectors+    array.+  * pname:pConnectors Array of slink:VkWaylandDrmLeaseConnectorEXT to be acquired.++All permissions necessary to control the display are granted to the Vulkan+instance associated with pname:physicalDevice until the display is released, the+Wayland connection specified by pname:display is terminated, or the compositor+revokes the lease.+If the Wayland server declines to grant the lease or the granted lease does not+include the requested connectors, the call must: return the error code+ename:VK_ERROR_INITIALIZATION_FAILED.+If the Wayland server later revokes the lease, requests using the+acquired slink:VkDisplayKHR resources must: fail with+ename:VK_ERROR_SURFACE_LOST_KHR.++include::{generated}/validity/protos/vkWaylandDrmLeaseDisplayEXT.txt[]+--++[open,refpage='VkWaylandDrmLeaseConnectorEXT',desc='Resource for relating Wayland connectors to VkDisplayKHRs',type='structs']+--++The sname:VkWaylandDrmLeaseConnectorEXT structure is defined as:++include::{generated}/api/structs/VkWaylandDrmLeaseConnectorEXT.txt[]++  * pname:pConnector A Wayland wp_drm_lease_connector_v1 to include in the+    lease.+  * pname:pDisplay The corresponding slink:VkDisplayKHR handle will be+    returned here.++The implementation will make a best-effort attempt to match each

Moved above

bl4ckb0ne

comment created time in 2 days

Pull request review commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

+// Copyright 2018-2021 The Khronos Group Inc.

I run into trouble from Vulkan-Hpp without that copyright (here)

bl4ckb0ne

comment created time in 2 days

pull request commentKhronosGroup/Vulkan-Docs

[RFC] Add VK_EXT_wl_drm_lease_display

See https://github.com/KhronosGroup/Vulkan-Docs/pull/1525, renaming the branch closed the pull request

bl4ckb0ne

comment created time in 2 days

pull request commentKhronosGroup/Vulkan-Docs

[RFC] Add VK_EXT_wl_drm_lease_display

Does this close #1001 and/or #1450?

bl4ckb0ne

comment created time in 2 days

pull request commentKhronosGroup/Vulkan-Docs

Add VK_EXT_wl_drm_lease_display

CLA assistant check <br/>Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.<br/>1 out of 2 committers have signed the CLA.<br/><br/>:white_check_mark: ddevault<br/>:x: bl4ckb0ne<br/><sub>You have signed the CLA already but the status is still pending? Let us recheck it.</sub>

bl4ckb0ne

comment created time in 2 days

issue closedKhronosGroup/Vulkan-Docs

Special Use breaks Contact rendering in extension manual page

1: visit https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_transform_feedback.html (or the page of any other extension with special usages) 2: notice the broken == Contact grafik

closed time in 2 days

DadSchoorse