Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Marijn
    @marijns95:matrix.org
    [m]
    Ralith: Should we just go ahead and merge your breaking PR straight to master already?
    Ralith
    @ralith:ralith.com
    [m]
    suits me, it's a big rebase hazard so it'd be nice not to have it lurking
    Marijn
    @marijns95:matrix.org
    [m]
    Then over time, as nonbreaking stuff appears, I'll create a 0.37-stable branch and start cherry-picking stuff (merged to master first) to it that we'd like for a patch release
    And then see if we can do a couple months without a breaking release - but I'm still more than happy to start with 0.38-pre.X releases as soon as we have some tangible UI changes ready we'd like to throw in the wild
    Ralith
    @ralith:ralith.com
    [m]
    fwiw I'm skeptical that it can ever be sound to assume ABI-equivalence between struct Foo { ..., length: usize, ptr: *const T, ... } and struct Foo { ..., field: (usize, *const T), ... }
    Marijn
    @marijns95:matrix.org
    [m]
    Fair enough, I hadn't given that much thought just yet
    And we'd have the edge-case of one length value being shared by multiple pointers, so it might not be worth pursuing this at all
    Ralith
    @ralith:ralith.com
    [m]
    maybe if we explicitly restrict targets to those for which that is true, which might plausibly be all the important ones, but it's an unsettling prospect
    right
    the current approach is pleasantly uniform
    Marijn
    @marijns95:matrix.org
    [m]
    Are you done with #602 btw? As in, #[inline]'ing the rest of the functions shoul;d be done in a separate PR anyways?
    Ralith
    @ralith:ralith.com
    [m]
    yeah, I'm inclined to pursue that in a separate PR; no need to make things too monolithic
    there's even a case to be made for splitting the existing inlining out entirely, but eh :P
    I think the bulk of the remaining inlining work is to go through all the handwritten stuff, which will be tedious
    though I've gotten a ton of mileage out of cheeky regexps so far
    Marijn
    @marijns95:matrix.org
    [m]
    SSR from rust-analyzer has treated me well back in the day too...
    Until needing some very specific stuff with multiple statements, where it all fell apart :D
    Regarding ABI compliance, I guess the only issue here is alignment?
    (/me doesn't remember if sizeof(usize) == sizeof(*const) in Rust)
    (Same for their alignment)
    Right, usize is literally defined as The pointer-sized unsigned integer type.
    But it seems unlikely that their alignment is forced to be the same, which could indeed cause ABI differences between the two
    Ralith
    @ralith:ralith.com
    [m]
    SSR?
    the main issue in my mind is that structs are not semantically transparent in C ABI; placing fields in a struct can in principle change how they interact with the layout algorithm all on its own
    Marijn
    @marijns95:matrix.org
    [m]
    Structured Search and Replace
    Marijn
    @marijns95:matrix.org
    [m]
    On top of your PR, with a literal return None; coded at the beginning of derive_setters() and regenerating:
    $ hyperfine -p 'cargo clean -p ash' 'cargo b -p ash'
    Benchmark 1: cargo b -p ash
      Time (mean ± σ):      5.174 s ±  0.027 s    [User: 5.914 s, System: 0.319 s]
      Range (min … max):    5.101 s …  5.193 s    10 runs
    So removing setters entirely is only ~550ms, and that's going to be less when we can't omit ~half of those for having pointers/slices/other magic sauce
    Curious where we're loosing out now
    Ralith
    @ralith:ralith.com
    [m]
    at a certain point we'll hit rustc issues rather than us issues, if nothing else
    Ralith
    @ralith:ralith.com
    [m]
    fiddling with setters by &mut rather than by value; looks like the big drawback is you can't do let foo = vk::Whatever::default().bar(..).baz(..);, which seems significant
    particularly as that's much less bad an idea now than it was before now that lifetimes don't get erased at the drop of a hat
    Marijn
    @marijns95:matrix.org
    [m]
    @MaikKlein: Can you turn on "branch must be based off of master" in branch protection and/or enable Always suggest updating pull request branches? We just merged a PR that wasn't based off of the recent generator changes resulting in obvious CI breakage because the new code wasn't regenerated
    Easy to fix, but nice if GH can preemptively prevent it :)
    nathan
    @nathan:remexre.xyz
    [m]
    first time using ash since #457 landed, and trying out linked; for some reason rustc is putting -lvulkan before libash-....rlib in the link command; is there a step I'm missing in configuring my crate?
    nathan
    @nathan:remexre.xyz
    [m]
    ah, never mind, this is an unrelated issue with the (non-cargo) build system I'm using
    Ralith
    @ralith:ralith.com
    [m]
    Marijn: don't forget we've got a major breaking change in HEAD already
    marijns95
    @marijns95:matrix.org
    [m]
    Ralith: I'm cherry-picking everything to 0.37-stable ;)
    And keeping up with it so far
    Ralith
    @ralith:ralith.com
    [m]
    👍️
    Dmajster
    @Dmajster
    hey, i'm trying to define a zprepass subpass, how do I provide a 'nullptr' to the GraphicsPipelineCreateInfoBuilder.color_blend_state()?
    Tendsin Mende
    @SiebenCorgie

    hey, i'm trying to define a zprepass subpass, how do I provide a 'nullptr' to the GraphicsPipelineCreateInfoBuilder.color_blend_state()?

    I think this is the default state if you are using ash::vk::GraphicsPipelineCreateInfo::builder. Otherwise you can use std::ptr::null() as the linked source does :)