!dSLljtUMNpdwwnkjGq:matrix.org

Portable Graphics in Rust

236 Members
https://community.mozilla.org/groups/rust-portable-graphics/40 Servers

Load older messages


SenderMessageTime
16 Nov 2020
@kvark:matrix.orgkvarkhttps://www.reddit.com/r/rust/comments/jvfgog/the_big_picture_of_gfxwgpu_ecosystem/21:21:33
@kvark:matrix.orgkvark Please feel free to post elsewhere! I tried to monitor users.rust-lang.org in the past, but eventually the lack of threaded discussions killed it for me. 21:22:41
@kvark:matrix.orgkvark * Please feel free to post elsewhere! I tried to monitor users.rust-lang.org in the past, but eventually the lack of threaded discussions killed it for me. 21:22:58
@kvark:matrix.orgkvark mwelsh: thank you for filing https://github.com/gfx-rs/gfx/issues/3478#issue-744085621 ! I'm curious about the spew, how did you get the validation errors to the console? 23:22:33
@mwelsh:matrix.orgmwelshRedacted or Malformed Event23:26:16
@mwelsh:matrix.orgmwelsh kvark: Debugging in vscode with cppvsdbg, I guess this enables more debug output in dx12? 23:27:06
@kvark:matrix.orgkvarkYeah23:48:46
17 Nov 2020
@msiglreith:matrix.orgmsiglreith kvark: btw it's possible to forward validation output to console but it's a bit scary: https://github.com/msiglreith/ragnarok/blob/master/src/debug.rs 11:40:47
@kvark:matrix.orgkvarkmsiglreith: that's not too bad, looks similar to KHR_Debug handler12:50:26
@kvark:matrix.orgkvarkWhat is this project btw?12:51:25
@msiglreith:matrix.orgmsiglreithold and abandoned :D one more iteration of gpu accelerated 2d path rendering13:08:48
@handicraftsman:matrix.orghandicraftsman joined the room.17:20:56
18 Nov 2020
@fzzr:matrix.orgAlex Koz. (fzzr) changed their display name from fzzr to Alex Koz. (fzzr).15:02:58
@sasalami:matrix.orgsasalami joined the room.21:52:40
19 Nov 2020
@tsahyt:tsahyt.comtsahyt I'm a bit confused about the documentation of image::Kind. It specifies the dimensions "along with the number of mipmap layers". But mip levels are specified separately when you call create_image, using a Level type, whereas image::Kind uses Layer. 09:28:07
@tsahyt:tsahyt.comtsahytShouldn't that be just layers? Or perhaps "array layers", I think that's what it's called in Vk09:28:42
@kvark:matrix.orgkvarkOops, that's a documentation bug12:50:55
@kvark:matrix.orgkvarkIt only has layers, not mipmap levels12:51:10
23 Nov 2020
@meshpotato:matrix.orgmeshpotato joined the room.14:14:30
@z33ky:matrix.orgz33ky joined the room.16:32:24
@z33ky:matrix.orgz33ky

Hello. I'm starting out learning some gfx-hal using the Learning gfx-hal series by False Idol Factory.
I've noticed some usages of unsafe, which is fair for such a library. However I was wondering if there exists some documentation on which guarantees the programmer must uphold in order to avoid memory errors/UB. I imagine that creating a comprehensive list of guarantees needed for the whole API may be a practically insurmountable task - multiplied even due to multiple backends which would need to be checked. However I found that any such specification is mostly missing.
I have found the issue #2453 (Mark most functions as unsafe) with some discussion about unsafety, though that just revolved around the decision of adding the unsafe keyword in various places in the public API. There is the bullet point "Function docs include error, panic, and safety considerations ([C-FAILURE])" in #1254 ([meta] follow Rust API guidelines), amongst a plethora of other suggestions, (presumably) yet unchecked.

With that said, I want to ask what are roughly the current or future plans about unsafe in the public API and safety-documentation? And how do programmers deal with the unsafety in the current API - is it basically just hoping for the best?

I don't mean to come across as being too critical. Safety is a big topic for Rust and I imagine some may have a hard stance on issue, but me, I am merely curious. I can't really judge the development of this project, for I have not followed it well, but I believe your efforts are genuine and well. Thanks for your work :)

17:10:24
@kvark:matrix.orgkvark z33ky: you are right on all accounts. There is a lot of unsafe, and we don't have proper documentation around them. Writing it down would be nearly as difficult as copying half of the Vulkan spec.
And that's part of the appeal of having a Vulkan-like API, the direction we took some time ago and are aligned for the most part. That means, you can open the Vulkan specification, find the relevant function, and check all the Valid Usage statements on it.
17:13:07
@kvark:matrix.orgkvarkFor people working on gfx-rs (and there isn't many today), having such documentation would be nice but not a priority. We mostly keep Vulkan spec by hand as a substitute. If you want to help documenting, the PRs will be welcomed!17:13:57
@z33ky:matrix.orgz33ky

kvark: I see. I've actually been reading the code for the OpenGL and Vulkan backends do. I know some OpenGL and a few Vulkanic concepts, but it seems like a workable approach for now.
I'll be happy to update the documentation with what I've found with a PR when I've finished the tutorial.

Btw, what's the difference between "Valid Usage" and "Valid Usage (Implicit)"?

17:19:58
@cwfitzgerald:matrix.orgcwfitzgeraldthere's also the problem that both gl and dx11 will have parts of the api that won't work correctly because of the difference in abstraction17:22:47
@cwfitzgerald:matrix.orgcwfitzgerald *
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       there's also the problem that both gl and dx11 will have parts of the api that won't work correctly because of the difference in abstraction
17:22:55
@cwfitzgerald:matrix.orgcwfitzgerald * there's also the problem that both gl and dx11 will have parts of the api that won't work correctly because of the difference in abstraction17:23:02
@cwfitzgerald:matrix.orgcwfitzgeraldthose should be documented in some place (maybe a wiki page)17:23:24
@kvark:matrix.orgkvark

Btw, what's the difference between "Valid Usage" and "Valid Usage (Implicit)"?

not exactly sure, I assume "implicit" is about rules inherited from some other scope where they are described, and just duplicated in the places they apply to

17:23:58
@z33ky:matrix.orgz33ky

Ah, it's specified in the spec:

3.7.2. Implicit Valid Usage
Some valid usage conditions apply to all commands and structures in the API, unless explicitly denoted otherwise for a specific command or structure. These conditions are considered implicit, and are described in a block labelled “Valid Usage (Implicit)” following each command or structure they apply to.

Thanks for the quick answer :)

17:27:31

There are no newer messages yet.


Back to Room List