| 25 Jul 2021 |
 Kangz | Again, having combined FS and VS in the same shadermodule is supposed to work. If it doesn't, then it's a bug. | 20:44:33 |
 pyrotechnick | Unfortunately my shader is quite unwieldily. I can try to distil it down to a minimal now with help from the toggles | 20:46:06 |
| pyrotechnick | OK I've reduced it significantly: | 21:25:22 |
| pyrotechnick | [[block]] struct ProjectionViewUniforms {
matrix: mat4x4<f32>;
};
[[group(0), binding(0)]] var<uniform> projection_view: ProjectionViewUniforms;
[[block]] struct ModelUniforms {
matrix: mat4x4<f32>;
};
[[group(1), binding(0)]] var<uniform> model: ModelUniforms;
[[stage(vertex)]]
fn vs(
[[location(0)]] position: vec3<f32>
) -> [[builtin(position)]] vec4<f32> {
return projection_view.matrix * model.matrix * vec4<f32>(position, 1.0);
}
[[stage(fragment)]]
fn fs() -> [[location(0)]] vec4<f32> {
return vec4<f32>(1.0);
}
| 21:25:32 |
| pyrotechnick | * [[block]] struct ProjectionViewUniforms {
matrix: mat4x4<f32>;
};
[[group(0), binding(0)]] var<uniform> projection_view: ProjectionViewUniforms;
[[block]] struct ModelUniforms {
matrix: mat4x4<f32>;
};
[[group(1), binding(0)]] var<uniform> model: ModelUniforms;
[[stage(vertex)]]
fn vs(
[[location(0)]] position: vec3<f32>
) -> [[builtin(position)]] vec4<f32> {
return projection_view.matrix * model.matrix * vec4<f32>(position, 1.0);
}
[[stage(fragment)]]
fn fs() -> [[location(0)]] vec4<f32> {
return vec4<f32>(1.0);
}
| 21:25:40 |
| pyrotechnick | error: | 21:25:55 |
| pyrotechnick | Unable to create library object: Compilation failed:
program_source:24:170: error: 'buffer' has a duplicate index '0'
vertex tint_symbol_10 tint_symbol_5(tint_symbol_9 tint_symbol_8 [[stage_in]], constant tint_symbol& tint_symbol_2 [[buffer(0)]], constant tint_symbol_3& tint_symbol_4 [[buffer(0)]]) {
^
at CreateFunction (../../third_party/dawn/src/dawn_native/metal/ShaderModuleMTL.mm:349)
at Initialize (../../third_party/dawn/src/dawn_native/metal/RenderPipelineMTL.mm:375)
at Create (../../third_party/dawn/src/dawn_native/metal/RenderPipelineMTL.mm:326)
at GetOrCreateRenderPipeline (../../third_party/dawn/src/dawn_native/Device.cpp:627)
| 21:25:58 |
| pyrotechnick | I'd appreciate anyone checking I'm not doing something silly before I submit a ticket | 21:26:35 |
| pyrotechnick | Simply removing the fragment stage causes it to compile and be used as a vertex shader module | 21:28:38 |
| pyrotechnick | But I am of the understanding that this should not be necessary | 21:29:07 |
| Kangz | Interesting, definitely is a Dawn bug. Can you file on crbug.com/dawn? I can look at it tomorrow. | 21:33:01 |
| pyrotechnick | Thank you Kangz . I'll file once I have a bit more info from MacOS 11.0+. I really appreciate the info re: toggles and for all of your time | 21:34:01 |
| Kangz | Np, good bug reports are always super useful! | 21:36:24 |
| 26 Jul 2021 |
 jasperrlz | Also, continuing on the "tiled" stuff I mentioned yesterday, someone pointed out to me that Qualcomm uses the term "deferred" in their GPU documentation: https://developer.qualcomm.com/docs/adreno-gpu/developer-guide/gpu/overview.html#flexrender-technology-hybrid-deferred-and-direct-rendering-mode , which just really throws a wrench in the works. | 00:42:19 |
| jasperrlz | They use it to mean "draws are deferred by first binning them into tiles, and then drawing each tile separately". But this is not the same meaning of "deferred" as "tile-based deferred rendering" aka TBDR. | 00:43:22 |
| jasperrlz | Yeesh. | 00:43:42 |
 kvark | How is it different? TBDR also bins into tiles and draws each tile separately | 00:58:59 |
| jasperrlz | TBDR is per-pixel, is the usual answer. | 00:59:21 |
| jasperrlz | I don't know exaaactly how it works but that's what they claim. After binning, they then do fine rasterization and sort triangles into per-pixel buckets, and then shade each triangle so it only writes to the pixels that it's visible on. No overdraw. Effectively a free per-tile pre-Z. | 01:01:42 |
| jasperrlz | That's what their public marketing says, at least. There's probably a lot of trickery to get that right, I don't believe it runs the VS for a triangle three times, it likely has some buffering that happens. | 01:02:41 |
| jasperrlz | Ah, https://docs.imgtec.com/Architecture_Guides/PowerVR_Architecture/topics/powervr_architecture_tile_based_deferred_rendering__tbdr.html has a bit more details. It says there's a buffer between the tiler and the rasterizer where post-VS data is stored, and then the VS is run again for shading. | 01:05:27 |
| kvark | Sounds like there's just 50 shades of tiling | 01:05:28 |
| jasperrlz | I wonder how alpha test is handled. Or if it literally craters the whole scene. | 01:06:59 |
| jasperrlz | https://docs.imgtec.com/Architecture_Guides/PowerVR_Architecture/topics/rules/c_GoldenRules_do_not_use_discard.html heh, yep. "Prefer alpha blending over discard" | 01:07:47 |
| jasperrlz | I guess the easy way to put it is that "tile-forward" makes per-tile lists of triangles (deferred to "tile granularity"), and "TDBR" makes per-pixel lists of triangles (deferred to "pixel granularity") | 01:12:24 |
| jasperrlz | But the lines are blurry (heh). Qualcomm has a low-res Z buffer that removes triangles on low-res Z granularity, which I assume is a bit better than tile granularity. So it gets some of the benefits of TBDR. | 01:14:34 |
 scoopr | One of the recent WWDC sessions explained that the apple chips render primitive-id + depth to a tile buffer | 05:08:51 |
|  jonboj changed their display name from Jonas Bojesen to jonboj. | 06:20:43 |
 Ben Clayton |
I believe this if is backwards https://dawn.googlesource.com/dawn/+blame/refs/heads/main/src/dawn_native/metal/ShaderModuleMTL.mm#128
pyrotechnick The logic here is correct. By default the tint::transform::Renamer transform renames all symbols. When that flag is enabled, we reduce the renaming down to just the reserved keywords, which is the minimum level of renaming we need to do.
| 11:41:16 |
|  niklaskorz joined the room. | 14:22:02 |
