marcan changed the topic of #asahi-gpu to: Asahi Linux: porting Linux to Apple Silicon macs | GPU / 3D graphics stack black-box RE and development (NO binary reversing) | Keep things on topic | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-gpu
<bloom>
marcan: When you have a chance, could you send the notes you have about the magic.bin data structure (with the render targets and depth/stencil attachments at the bottom)? Thanks c:
jannau has joined #asahi-gpu
<bloom>
note to self: bi_emit_load_frag_coord broken with multisampling
<bloom>
dougall: any objection to relicensing applegpu to MIT for mesa consumption?
<xerpi[m]>
That's still amazingly fast progress, considering you are reverse engineering it :)
<bloom>
:)
<bloom>
gl_FragCoord coming in a few min, need to get some water and let my brain rest
<xerpi[m]>
gl_FragCoord are the coordinates of the current invoked fragment that came out of rasterization, right? So will they probably be preloaded in some register/special memory address?
<xerpi[m]>
Oh, I see that they are in screen space and not NDC
<xerpi[m]>
That's interesting, this means the fragment shader has both interpolated and flat varyings available to pick from, isn't this a waste of memory/regs? (I was expecting only one of them would be generated, depending on a flag)