| 10 Aug 2020 |
 jcapucho | I actually need both a 450 and 300 es backend for what im doing (sort of a transpiler) hence why i split everything into a common module | 15:03:39 |
| jcapucho | kvark: I answered some of your comments and im implementing the others but otherwise the backend is mostly ready and i'll start on the 300 backend as soon as everything is addressed i left ShiftRightLogical unimplemented because there's no one-to-one translation | 15:07:49 |
 kvark | jcapucho: I think I'm confused now about why you need the typifier | 15:35:07 |
| kvark | it was supposed to be used in front-ends | 15:35:13 |
| jcapucho | kvark: I use it in the imagesample to get dimensions and the kind and also the sampler to see if its comparison or not | 15:37:29 |
| kvark | wait, you have the IR module. It has types and handles to types already. Typifier is meant to fill up those types, but you already have all the types in the module you get. | 15:38:30 |
| jcapucho | Yes but in Expression::ImageSample I only have handles to the expression arena | 15:40:25 |
| kvark | those expressions are expected to be GlobalVariable. In fact, maybe we should change the IR to do this. I had those as expressions just because I wasn't sure if we'll need to be able to use local variables for textures/samplers and stuch, but so far it's not possible in WGSL or Naga | 15:42:13 |
| kvark | so what you should be doing is just matching the expressions and expecting them to be GlobalVariable, then looking at the types for those global vars
this is what the typifier is doing, anyway, as well as other backends | 15:42:55 |
| jcapucho | kvark: i was working on removing the typifier from the glsl backend and noticed that it's also used in AccessIndex to decide whether it's indexing or field access and that glsl es has no implicit conversions so a method on typifier for backends to get the type of an expression might be a good idea | 20:04:49 |
| kvark | in other words, you are saying that similar logic may be needed in other backends? | 20:06:37 |
| kvark | did you check MSL for the reference? | 20:06:42 |
| jcapucho | no im saying it might be needed for es, i havent checked msl yet | 20:07:29 |
| jcapucho | the msl backend returns the type i might do the same for the glsl backend | 20:12:41 |
 Matúš | 
Download image.png | 22:28:48 |
| Matúš | Fully classified with constructs as well now. | 22:29:07 |
| Matúš | No promises when I can continue to work on It. I have to back get to my thesis now :) (making my demo cool, porting AMD SSAO). | 22:30:11 |
| kvark | Lovely! | 22:30:19 |
| Matúš | But this was the most difficult part I guess. From this a final Naga IR can be generated. | 22:30:46 |
| Matúš | Remaining major part is resolution of OpPhi instructions. | 22:31:00 |
| Matúš | * But this was the most difficult part I guess. From this a final Naga IR can be generated. | 22:33:35 |
| Matúš | I am kind of proud of myself. I don't know if anybody is able to generate such beautiful graphs of SPIR-V :D. I fell in love with the dot format and the new online playground http://magjac.com/graphviz-visual-editor/; highly recommend! | 22:35:59 |
| kvark | Looking forward to have this landed! | 22:43:01 |
| 11 Aug 2020 |
| jcapucho | kvark: I fixed all the comments you made | 09:01:32 |
| jcapucho | Just some things that the glsl backend is ignoring:
- the module header (shouldn't be anything necessary here)
- Pointer storage class
- Array stride
- Struct members origin
- Constant specialization
- Function global usage (Shouldn't have anything needed here)
- Entry points are completely ignored as glsl only supports one entry point (main) and it doesn't have decorators with shader stage
| 09:07:17 |
| jcapucho | somethings that aren't implemented:
- image loads on multi sampled samplers
- logical right shift
- reordering of structs, globals and functions
| 09:09:01 |
| kvark | Awesome, thank you! | 11:54:17 |
| kvark | jcapucho: there are 2 things to note
- the style is mixed between free functions
fn write_xxx and methods, i.e. fn write_glsl in impl Statement. Can we align everything to be consistent?
- some commits failed CI. Would you be ok if we squash it on merge?
| 13:01:16 |
| jcapucho | kvark: I pushed a change to fix 1 and for me squashing is fine I did run clippy but forgot to pass --all-features so some warning passed in the beginning | 14:59:57 |
| 12 Aug 2020 |
| kvark | pjoe: might be interested in https://github.com/suhr/sana | 02:57:03 |
