Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ralith
    @ralith:ralith.com
    [m]
    (my main project is pure VR)
    Ralith
    @ralith:ralith.com
    [m]
    I'd kinda like to have a command buffer helper that internally captures an &ash::Device and a vk::CommandBuffer and has the various methods defined on it directly
    breaks down a bit with extension stuff though
    Marijn
    @marijns95:matrix.org
    [m]
    I guess we could have a bunch of such helpers
    Including perhaps refcounting for resources? Would be a separate crate on top of ash though
    Ralith
    @ralith:ralith.com
    [m]
    definitely wouldn't want resource management stuff, I have my own systems that are able to be much simpler by way of baking in architectural decisions (which I think is one of the great advantages of Vulkan)
    I feel like having a different helper per extension would be too much trouble; the only benefit to start with is avoiding the repetition in device.cmd_foo(cmd, ...); device.cmd_bar(cmd, ...); device.cmd_baz(cmd, ...);
    cmd.foo(...); cmd.bar(...); cmd.baz(...); is nice, having to construct three different cmds and determine which to use when is less nice
    Ralith
    @ralith:ralith.com
    [m]
    I think this is a drawback of the per-extension fn structs paradigm, though maybe solveable at a higher level by bundling things up?
    another thing that's on my mind a bit is that the prevalence of Vulkan feature flag gated functions kinda undermines the upsides of per-extension fn structs, since many core functions may or may not be available
    Michael Pollind
    @pollend
    @MaikKlein I've been working on a parser for the opengl registery. I was thinking about writing a similar binding for opengl. I was thinking of trying to reuse parts of the generator for ash.
    Ralith
    @ralith:ralith.com
    [m]
    problem: RenderPassMultiviewCreateInfo does not implement ExtendsRenderPassCreateInfo2
    Ralith
    @ralith:ralith.com
    [m]
    it (like most such things) only implements ExtendsRenderpassCreateInfo
    Marijn
    @marijns95:matrix.org
    [m]
    Ralith: is that a shortcoming in vk.xml?
    Ralith
    @ralith:ralith.com
    [m]
    looks that way, there's exactly one instance of structextends="VkRenderPassCreateInfo,VkRenderPassCreateInfo2"
    Marijn
    @marijns95:matrix.org
    [m]
    Indeed, and it isn't on VkRenderPassMultiviewCreateInfo at least. Perhaps this is already reported as an upstream bug, otherwise worth reporting it or contributing a fix over at Vulkan-Docs?
    Ralith: What about current open PRs, shall we merge the whole bunch of breaking PRs soon-ish and cut Ash 0.37?
    1 reply
    Haven't seen any activity on ash_window::enumerate_required_extensions usability issue #595, but that's ash-window which can live on its own release schedule
    Ralith
    @ralith:ralith.com
    [m]
    I'd rather merge breaking PRs sooner rather than later and open a backport branch for nonbreaking stuff if needed, it's hard to keep track of a bunch of unmerged stuff and conflicts can be an issue
    Marijn
    @marijns95:matrix.org
    [m]
    Yeah we can probably merge anyway and cut a backport branch if we really see a need to
    Just want to avoid releasing multiple breaking versions in short succession
    Though OTOH it makes the "migration" process smoother for those affected by multiple breaking changes
    Ralith
    @ralith:ralith.com
    [m]
    bunching them up? yeah, but you can do that regardless with backports, just a matter of policy
    and whether you want to do more work tracking unmerged stuff and resolving conflicts or writing backports
    Marijn
    @marijns95:matrix.org
    [m]
    Not afraid for backports anyway, once we cut a new release we can just do non-breaking followup releases with new nonbreaking features
    But we generally haven't needed those, it's not like any release really broke
    It's only for the odd case where someone really insists on needing a certain fix/feature on a specific version because they can't upgrade to the newer ash, but that has never happened thus far
    Ralith
    @ralith:ralith.com
    [m]
    I mean as a matter of routine practice, we could consider master to always be the next breaking release, and also merge non-brekaing PRs to the latest backport branch
    Marijn
    @marijns95:matrix.org
    [m]
    Not sure how I feel about preliminary picking of non-breaking changes to a backport branch
    In any case, my worry was more about doing lots of breaking releases in quick succession, but I think we can do one now
    But yes, maintaining a backport branch and eagerly merging breaking changes to master would alleviate that somewhat... 🤔
    Ralith
    @ralith:ralith.com
    [m]
    higher constant overhead, lower per-PR overhead, unclear where we're at on that axis
    have seen it work well for really really big repos but we arguably are not there yet
    just food for thought
    so long as you're the one keeping track of what needs to be merged I'm not gunna complain :D
    Marijn
    @marijns95:matrix.org
    [m]
    :P
    Yeah I definitely hope we're not big enough for that :D
    I guess I'll just go start merging PRs then
    Shall we get MaikKlein/ash#597 in first and keep that as the last non-breaking commit in the event that we'd like some backports?
    Ralith
    @ralith:ralith.com
    [m]
    sgtm
    Marijn
    @marijns95:matrix.org
    [m]
    You'll probably have to rebase your PR a bit then, new functions and all...
    Perhaps @MaikKlein should change the PR settings to require everything to be based off of main before we can click merge
    (That should also automatically show an "update branch" button in GH UI)
    Because then at least we'll have the CI - in particular the generator run - against main always
    Otherwise it'll only start erroring about missed generated changes after being squash-merged on top
    And so I saw the wrong 1.3.207 title (should have been .208) as I clicked merge
    Oh well :D
    Ralith
    @ralith:ralith.com
    [m]
    close enough >_>
    Marijn
    @marijns95:matrix.org
    [m]
    Happens too often tbh 😂
    Ralith
    @ralith:ralith.com
    [m]
    rebased 599, and added a second commit with some cosmetic internal cleanup