Vulkan vs Rust

Vulkan. You know what it is. But why isn't it out yet?

Oh, what do you know, it's because Rust programmers are complaining it's difficult to interface with their FFI because of Rust's lack of unions, so these SJWs are bitching about it to try to change Vulkan's data structures to be less optimized in order to favour Rust.

Rust is fucking garbage and these rustcucks are fucking up what could be a good API.

https://www.khronos.org/message_boards/showthread.php/9649-Official-Vulkan-Feedback-API-for-High-efficiency-Graphics-and-Compute-on-GPUs?p=38243&viewfull=1#post38243

>>10,12-13
I think the issue here is that Rust's enum types can store composite data like a tagged union in C, but don't have a binary representation that's compatible with arbitrary tagged unions in C. Rust code that doesn't use the native Rust enum type works against the type system.

I think it ought to be possible to write a little unsafe wrapper code in Rust to serialize and deserialize Rust enums to and from the C types the FFI uses, but I'm not a Rust weenie. I'm sure there could be performance concerns but I'd hope rustc is smart enough to eliminate unnecessary copying and repeated checking of type tags if the programmer is a little careful.

>>23
AMD and nVidia have been shitting up the constellation of all the standards they care about by introducing oddball features they hope will give them an edge over the other. If Intel drives Vulkan I think we'll get a better interface out of it.

Intel's GPU stuff is better than I used to think it was. Their drivers are getting better too. Vulkan is the right thing to do. That die space isn't going to do as much good going to CPU cores as it would going to a highly parallel compute system. You don't need to run graphics on it, and with Vulkan the hope is doing GP compute on it will become more common. Of if you don't have IGP or want to shove it off to your DGPU, a cat is fine too.

>>24

The program code, you fartknocker

If you can't resolve a variant in the interface you have a big problem, like not being able to tell which variant the interface gave you.

>>14,24

oh wwwwww

I didn't comment on this the first time around but I doubt there is any ADT-specific 'smartness' built into the optimizer that would cover this. In the case at hand, the perf cost isn't so much in checking the value as it is in repackaging it, then checking it again. But maybe this could optimize very nicely:

enum FooBar {
Foo(footype),
Bar(bartype),
}

#[inline(always)]
fn check_variant(foobar: some_c_struct) -> FooBar {
match garbage.tag {
FOO => Foo(foobar.value),
BAR => Bar(foobar.value),
_ => unreachable!()
}
}

fn uses_check_variant(...) {
// ...

match check_variant(foobar) {
Foo(foo) => {...},
Bar(bar) => {...},
}

// ...
}

Since the patterns correspond well, the constructed variants don't outlive the match block and the code will be inlined, the optimizer should be able to rewrite it so that the code in the match arms replaces the variant constructors in check_variant().

You would probably also stick check_variant(); in an impl for some_c_struct so the check would just look like: match foobar.check_variant() { ... }.

What's more, I haven't kept up on the ins and outs of Deref and it is probable implementing Deref for some_c_struct could turn that match into this: match foobar { ... }. That's fucking slick, yeah?

This is a reasonable optimization, subject to the constraints above. If it doesn't exist in rustc/llvm, you could file an issue on it and be confident someone will take it seriously. This pattern should perform as well as (or better than) the C code that forces the programmer to do case analysis on the descriminant directly.