| 19 May 2020 |
| 15:44:44 |  kvark | jcapucho: jrmuizel so if I read you correctly, we could write a parser by hand that would not need to care about the older GLSL syntax and thus be smaller than the current nom-based one? |
| 15:45:30 | kvark | AFAIK, that backwards compat is what cripples glslang translator today. It wound be nice if our from-the-ground design had this advantage on the start, instead of taking the same baseline. |
| 15:45:41 |  jrmuizel | kvark: I think just writing it while thinking about code-size is what would make the difference |
| 15:46:06 | jrmuizel | kvark: I don't think older syntax costs much space in the glsl crate |
| 15:47:30 | jrmuizel | glslang also does a lot more during parsing than the glsl crate does which probably gives it size advantage |
| 15:47:50 |  jcapucho | No the glsl crate is mostly nom |
| 15:48:05 | jrmuizel | it also probably doesn't have the mov-pocalypse that rust code tends to generate |
| 15:50:01 | jcapucho | But the glsl crate also isn't feature complete for example all the layout qualifier parsing is left to the user |
| 15:51:11 | jrmuizel | I could imagine that not having a separate lexing phase also contributes to code bloat because the lexing needs to be duplicated in a bunch of places in the parser |
| 15:51:50 | jcapucho | I already had to rewrite the preprocessor part and the lexer by extension since glsl doesn't handle it |
| 20 May 2020 |
| 05:57:51 |  pjoe | what is the strategy for tests? glslang has a s**tload of tests, glsl source files, expected AST (as text dumps), and expected spirv output |
| 05:59:04 | pjoe | https://github.com/KhronosGroup/glslang/tree/master/Test |
| 05:59:42 | pjoe | they actually capture the output of the compilation, i.e. they also test for errors being output correctly |
| 06:00:25 | pjoe | see e.g. https://github.com/KhronosGroup/glslang/blob/master/Test/baseResults/450.frag.out |
| 06:09:36 | pjoe | would be great to re-use some of that, but not sure about licensing ... looks to me like glslang proper is under BSD 3 clause |
| 09:48:35 | pjoe | btw. are there any good alternatives to nom? a quick search found me: https://github.com/softdevteam/grmtools |
| 10:07:00 | jcapucho | The wgsl lexer is pure rust and just about 100 line |
| 10:39:11 | pjoe | ok .. was just thinking if could re-use some of glslang lexer/parser ... but maybe more trouble than it's worth |
| 10:40:37 | pjoe | glslang has bison based lexer/parser (.y file): https://github.com/KhronosGroup/glslang/blob/master/glslang/MachineIndependent/glslang.y |
| 12:55:54 | kvark | pjoe: we haven't thought all the testing through. We are going to have some shaders (in test-data folder) converted back and forth by a test that runs with cargo test. We also want to have https://github.com/gfx-rs/naga/issues/41.
Generally, I think testing as granular as possible would be great, i.e. snapshotting IR as well as testing expectations for certain errors - all of that would be good to have, in reasonable amounts (as long as maintaining the tests is not more burden than the actual logic). |
| 17:48:00 |  scoopr | bindgen does something similar to snapshot testing, if that helps as a reference |
| 23 May 2020 |
| 10:17:55 | jcapucho | kvark: I've finished implementing the preprocessor (with the exception of token pasting) but it's very inefficient as it has to transform everything to a string again to the glsl crate, the best solution would be to write a custom parser and it would also help with the code hell generated by nom but I don't think I can do it (at least not alone) |
| 13:59:34 | kvark | Agreed! |
| 16:26:28 | jcapucho | @kvark:matrix.org: I'm going to start working on the parser then |
| 19:50:17 | kvark | It's exciting to finally being able to throw glslang out! |
| 20:02:29 | jcapucho | shaderc in my case but I agree |
| 24 May 2020 |
| 17:25:59 | |  kriztw joined the room. |
| 25 May 2020 |
| 06:36:59 | | * pjoe added PR with inital wasm build: https://github.com/gfx-rs/naga/pull/55 |
| 06:37:23 | pjoe | must admit travis build ouptut is rather verbose, maybe should consider minimizing that a bit |
| 06:38:36 | pjoe | though after looking at .travis.yml I'm guessing that is more of an issue with travis default config :) |
