1890348863287943363, 1886572405176345062, 1885175713638076657, 1884282476195110998, 1881908248544166159, 1877208278632955949, 1876093937632600106,
This commit is contained in:
ed committed
1 parent
aca7150c9e
commit
8bf65fca7b
23 files changed
+1178
-62
No files matched your search
+55
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "@NOTimothyLottes Some optimization ideas:"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/JBrooksBSI/status/1876298864736801016"
|
||||
author: "John Brooks"
|
||||
handle: JBrooksBSI
|
||||
post_id: "1876298864736801016"
|
||||
date: 2025-01-06
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@NOTimothyLottes Some optimization ideas:"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1875583660545732960"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/JBrooksBSI/status/1876298864736801016
|
||||
- Author: John Brooks (@JBrooksBSI)
|
||||
- Posted: 2025-01-06 16:04:43
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@NOTimothyLottes Some optimization ideas:
|
||||
|
||||
1) For RDNA2 simd, insn-dependency stalls make it unlikely to achieve 100% VALU utilization. Try unrolling 2x or 4x
|
||||
|
||||
2) bit-per-thread data like float signs can often be done as 64x SALU var at 2x VALU speed
|
||||
|
||||
3) If FP16 range is ok, gives 2x VALU speed
|
||||
|
||||
**2/**
|
||||
|
||||
@JBrooksBSI Lack of ABS modifiers on V_PK ops basically kills FP16 benefit here unfortunately. I do unroll when not VGPR limited (favorite optimization). Wary though of SALU/VALU crossings due to latency + scheduling behavior (loss of operand cache, etc). VCC probably has special forwarding
|
||||
|
||||
**3/**
|
||||
|
||||
@NOTimothyLottes I did an approx equal-area mapping to a 2D texture in 2018
|
||||
|
||||
Approach was to map sphere to Archimedean solid rhombicuboctahedron (triangles and squares) packed into a 2D texture
|
||||
|
||||
https://en.wikipedia.org/wiki/Rhombicuboctahedron
|
||||
|
||||
Lookup of 3D unit vec used small static cubemap to convert to 2D texture U,V
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs]]
|
||||
+2
@@ -39,6 +39,8 @@ At some point the standard Octahedron mapping leaves a lot to be desired due to
|
||||
|
||||
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs/2025-01-06-JBrooksBSI-some-optimization-ideas-1-for-rdna2-simd-insn]]
|
||||
|
||||
**3/**
|
||||
|
||||
AMD's latest driver actually does mostly a good job compiling that (32 op clocks compiled, just 1 more instruction somewhere). I'm surprised actually it's now picking up 'cos(x*2pi)' and pattern matching that to just V_COS_F32!
|
||||
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "One of the downsides of V_CNDMASK_B32 on AMD is that you burn the SGPRs on the VCC bool, so if you are selecting between constants, those require extra V_MOV_B32 ops."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1876093937632600106"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1876093937632600106"
|
||||
date: 2025-01-06
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "One of the downsides of V_CNDMASK_B32 on AMD is that you burn the SGPRs on the VCC bool, so if you are selecting between constants, those require extra V_MOV_B32 ops."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1876093937632600106
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-01-06 02:30:25
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
One of the downsides of V_CNDMASK_B32 on AMD is that you burn the SGPRs on the VCC bool, so if you are selecting between constants, those require extra V_MOV_B32 ops. Would be much better to have fused cmp+mask so this limitation would be lifted!
|
||||
|
||||
|
||||
|
||||
**2/**
|
||||
|
||||
Another night, another round of AMD compiler bugs. Sometimes AMD fails 'uint32_t packFloat2x16(f16vec2 v)' ... I'm seeing the 16-bit MSB cleared in this constant (yeah it's the slow V_CNDMASK_B32 case in the prior tweet)
|
||||
|
||||
|
||||
|
||||
**3/**
|
||||
|
||||
Workaround is to use 'pack32(halfBitsToUint16(a))' instead (ie first convert the packed 16-bit float to packed 16-bit integer, then convert to 32-bit integer) ...
|
||||
|
||||
|
||||
|
||||
**4/**
|
||||
|
||||
One of my favorite AMD instructions V_BFI_B32 is unfortunately one that no intrinsic exists for on PC, and one that the AMD compiler often messes up the pattern matching for, sometimes it reduces to {AND,ADD} instead
|
||||
|
||||
|
||||
|
||||
|
||||
**5/**
|
||||
|
||||
Just looking at the next 5 lines of disassembly shows another 2 perf bugs: the compiler transforms 3 operations into 5 operations because it cannot handle mixed packed and unpacked stuff. The 2 V_ANDs can be merged, and the LSHL and CVT should just be one op
|
||||
|
||||
|
||||
|
||||
**6/**
|
||||
|
||||
No way to work around those problems. Looks like bitfieldExtract 'v4' back-propagates something where the compiler ignores the .y in the packed logic, and then makes a mess of things scalarizing it. BFE only uses the 5-bit LSB of 'v4', so it's safe to leave junk in the other bits
|
||||
|
||||
|
||||
+102
@@ -0,0 +1,102 @@
|
||||
---
|
||||
title: "Just for Fun: Started to look into \"Cardinal Cubic O-MOMS\" for resampling, some refs:"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1877208278632955949"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1877208278632955949"
|
||||
date: 2025-01-09
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "Just for Fun: Started to look into \"Cardinal Cubic O-MOMS\" for resampling, some refs:"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1877208278632955949
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-01-09 04:18:25
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
Just for Fun: Started to look into "Cardinal Cubic O-MOMS" for resampling, some refs:
|
||||
https://hhoppe.com/proj/filtering/supp/
|
||||
https://hhoppe.com/proj/filtering/supp/sample_code.cpp
|
||||
The source paper is math salad:
|
||||
https://www.ee.cuhk.edu.hk/~tblu/monsite/pdfs/blu0101.pdf
|
||||
|
||||
**2/**
|
||||
|
||||
Results are quite nice in repeated reprojection:
|
||||
https://w3.impa.br/~diego/publications/NehHop14.pdf
|
||||
[BLUE] From that PDF
|
||||
Lanczos is of course not stable (if you reproject enough with a fast lanczos approximation, it will converge to a black and white image) so it needs non-linear control
|
||||
|
||||
|
||||
|
||||
**3/**
|
||||
|
||||
However O-MOMS appears to need a pre-pass on the data before running the simple cubic filter. That simple cubic would otherwise blur bad (no negative lobes). So this is about where I stopped dissecting the math salad, and started looking at the code salad
|
||||
|
||||
|
||||
|
||||
**4/**
|
||||
|
||||
That prepass seems to work with 9 coefs in 1 dimension. So this starts to look mighty expensive??? for GPU-side implementation (compared to the existing option of limiting lanczos to make it stable).
|
||||
|
||||
|
||||
|
||||
**5/**
|
||||
|
||||
Anyway if anyone knows of a less salad-like example of cubic O-MOMS, please post
|
||||
|
||||
**6/**
|
||||
|
||||
So if you reproject rotate in linear using a bilinear filter, after 16 reprojections you get this slop (very blurry), which is why the old simple TAA's started to look bad very fast
|
||||
|
||||
|
||||
|
||||
**7/**
|
||||
|
||||
Compared to say this with a clamped approximate lanczos (same 16 reprojections, and linear filtering). The min/max for the clamp is of the inner 2x2 quad of the 4x4 filter window
|
||||
|
||||
|
||||
|
||||
**8/**
|
||||
|
||||
So even after 16 frames, clamped lanczos approximation is already significantly less sharp than source (below). Thing most of the shader TAAs screw up is that even with great reprojection filtering, still need error-correction sharpening on the reprojection to keep it dialed in
|
||||
|
||||
|
||||
|
||||
**9/**
|
||||
|
||||
Some don't limit the kernel approximation that has negative lobes, because it's not differentiable, leading to the classic trailing edge halo (dark outline typically seen in DLSS2 at least). After close to 64 frames of reprojection (rotation), easy to see that effect
|
||||
|
||||
|
||||
|
||||
**10/**
|
||||
|
||||
Letting that go too long and well it converges to a high contrast black and white mess
|
||||
|
||||
|
||||
|
||||
**11/**
|
||||
|
||||
The non-linear limiter (simple clamping) keeps it mostly stable in color, even if the detail still converged to noodles
|
||||
|
||||
|
||||
|
||||
**12/**
|
||||
|
||||
Also if you overcook your negative lobes in the approximation (using the RED curve below), it speeds up the noodling process (that is the same 16 reprojections as prior)
|
||||
|
||||
|
||||
|
||||
+112
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: "Simple napkin analysis of that high-end CRT scalar (monochome one) ..."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1881908248544166159"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1881908248544166159"
|
||||
date: 2025-01-22
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "Simple napkin analysis of that high-end CRT scalar (monochome one) ..."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1881908248544166159
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-01-22 03:34:25
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
Simple napkin analysis of that high-end CRT scalar (monochome one) ... notes about cleaning up the code.
|
||||
|
||||
I track state usage throughout the code to ballpark expected max VGPR count. This needs around 57 VGPRs mid way through. Note <=64 VGPRs is often important.
|
||||
|
||||
|
||||
|
||||
**2/**
|
||||
|
||||
So yeah packed 16-bit is the reason complex shaders like this are possible on PC GPUs. It is the way to single pass and avoid multiple trips through DRAM.
|
||||
|
||||
**3/**
|
||||
|
||||
This code does 2 parallel kernels, but also breaks the computation of each kernel into 4 weighted sums. This is done for 2 reasons: (a.) possibly higher precision, (b.) to enable parallel work to hide VALU latency (ILP)!
|
||||
|
||||
|
||||
|
||||
**4/**
|
||||
|
||||
This shader needs roughly
|
||||
410 VALU op clocks
|
||||
And 253 of those (more than half)
|
||||
are in the load latency window
|
||||
So this shader will trivially hide a lot of latency without getting to high wave/CU counts
|
||||
|
||||
**5/**
|
||||
|
||||
BUT
|
||||
Traditionally this has been a curse, because AMD's oldest wave first scheduling breaks down when the oldest is ultra high VALU load without stalls! The other waves often cannot get forward progress to get loads out to debubble the memory sub-system
|
||||
|
||||
**6/**
|
||||
|
||||
Worst case (no scaling, no compression) this would use 6-bytes/pixel of bandwidth (damn), and amortize closer to 4-bytes/pixel with scaling. And GPUs have capacity often for 32 VALU op clocks per byte. So this is certain to be VALU bound (410+ VALU clocks)
|
||||
|
||||
**7/**
|
||||
|
||||
But things like Strix Halo (laptops) are quite a bit more bandwidth starved, so generally I try to stay VALU bound to be friendly towards scaling down
|
||||
|
||||
**8/**
|
||||
|
||||
Estimation that something like a 7900 XT would be able to do over 10,000 of these passes at 4K per second, so this technique is good for 480 Hz! Of course I don't have a 7900 XT, and my only working AMD GPU laptop (the other has bad HDMI port) refuses to profile, so numbers later
|
||||
|
||||
**9/**
|
||||
|
||||
Writing code (below, note FMA_MIX is the hot ticket for free FP32->FP16 conversion) with instruction intrinsic macros (that unfortunately map to high-level shader code). But it at least enables me to ballpark instruction counts. With one exception I count transcendentals as 4 ops
|
||||
|
||||
|
||||
|
||||
**10/**
|
||||
|
||||
Can compare guesses with actuals on the disassembly/
|
||||
|
||||
76 VGPRs! haha, decade+ and AMD still cannot manage basic VGPR allocation well. This is using roughly 30% more VGPRs than needed. Historically AMD HW has bumped up the VGPR count and added NSA to fix their SW problems ...
|
||||
|
||||
|
||||
|
||||
**11/**
|
||||
|
||||
I use 13 transcendentals so adjusting my 410 count by -13*3 I get 371 VALU ops. The actual shader uses 438 (and is VALU bound) an extra 18% extra slop somewhere. Some of that is that I didn't count the CS swizzle logic (but that won't account for most of the extra 67 ops) ...
|
||||
|
||||
**12/**
|
||||
|
||||
Some of the slop, it's not using NSA (this is GFX9), so lots of extra V_MOV_B32s. The gather offsets are packed in an extra VGPR so even if the base {v34,v35} are shared across all the gather4s, it's duplicating those VGPR pairs 8 extra times (no NSA here).
|
||||
|
||||
|
||||
|
||||
**13/**
|
||||
|
||||
GFX9 is Vega, so no NSA here, and 1 SGPR read per operation. It was RDNA1 that introduced the good stuffs (NSA and 2 SGPRs/op).
|
||||
|
||||
Can see below cases where 2 SGPRs are needed Vega will introduce extra V_MOV_B32 ops to put one in a VGPR.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**14/**
|
||||
|
||||
Now some actual compiler bugs,
|
||||
(1.) Vega has V_MAD_MIX, but the compiler won't use it, instead it wastes extra V_CVT_PKRTZ_F16_F32 ops
|
||||
(2.) Compiler fails basic pattern matching with {x,-x} and instead issues extra V_PACK_B32_F16 ops
|
||||
|
||||
|
||||
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: "Just raw spatial scaling in a custom resolve/"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1884283764068737420"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1884283764068737420"
|
||||
date: 2025-01-28
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "Just raw spatial scaling in a custom resolve/"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1884282476195110998"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1884283764068737420
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-01-28 16:53:52
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
Just raw spatial scaling in a custom resolve/
|
||||
4xMSAA at 2.25x area is 2.66xAA on edges
|
||||
8xMSAA at 2.25x area scale is 5.33xAA on edges
|
||||
8xMSAA at 4x area scale is 4xAA on edges <--- bingo
|
||||
|
||||
**2/**
|
||||
|
||||
Take 8xMSAA with a view-port jitter pattern (or even PSL) which always maintains the same sample vs axis intersections! <--- double bingo
|
||||
|
||||
Sub-pixel detail is now mostly stable, will show up in all frames in the local neighborhood = stable temporally
|
||||
|
||||
**3/**
|
||||
|
||||
Bottom line/
|
||||
8xMSAA + smart jitter (or PSL)
|
||||
+ temporal feedback
|
||||
+ 4x area spatial scaling
|
||||
ALL in one custom resolve pass
|
||||
|
||||
Something one could make temporally stable without ghosting and still maintain 4xAA (on edges at output resolution) on the worst case in disocclusions
|
||||
|
||||
**4/**
|
||||
|
||||
It would destroy DLSS4 in terms of classic image quality
|
||||
|
||||
**5/**
|
||||
|
||||
Note one can inline something like CAS/RCAS (what I did at AMD) into the custom MSAA resolve, by modulating a negative lobe based on a local min/max kernel's min distance to signal peak {0 or 1}. Meaning it's possible to get really sharp output from this combo.
|
||||
|
||||
**6/**
|
||||
|
||||
@NOTimothyLottes Is there an example shader that does that custom resolve?
|
||||
|
||||
**7/**
|
||||
|
||||
@dankbaker Probably not in the config you are interested in (I'm assuming spatial with no scaling?) Feel free to DM me. Most of these things need adaption specific to the config. Last one I did was huge spatial scaling for a CRT-styled scalar using this kernel,
|
||||
|
||||
|
||||
|
||||
**8/**
|
||||
|
||||
@dankbaker My project is monochome so the kernel blending logic is single channel, and the content is designed to handle a huge amount of negative lobe well so I don't constrain ringing (BLUE, replace with 'm.y*RINGING'), and everything in linear of course ... but it should provide an idea
|
||||
|
||||
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the]]
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "@MichalDrobot My mindset is more tuned towards rendering without minSampleShading and using the temporal component to get the shading resolution up since base frame rate will be high anyway."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1884361733537509538"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1884361733537509538"
|
||||
date: 2025-01-28
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "@MichalDrobot My mindset is more tuned towards rendering without minSampleShading and using the temporal component to get the shading resolution up since base frame rate will be high anyway."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1884360689093091618"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1884361733537509538
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-01-28 22:03:41
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@MichalDrobot My mindset is more tuned towards rendering without minSampleShading and using the temporal component to get the shading resolution up since base frame rate will be high anyway. So no soft VRS in my line of thinking either (other than whatever falls out of 8xMSAA render)
|
||||
|
||||
**2/**
|
||||
|
||||
@NOTimothyLottes That’s pretty much exactly the mindset and what ended up shipping in Killzone Shadow Fall (4xMSAA -> 2x scaling + TAA) and in FarCry4 8xMSAA FMask only + analytical resolve + TAA
|
||||
Doing sub samples in FC4 was challenging due to all that AT foliage.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the]]
|
||||
+89
@@ -0,0 +1,89 @@
|
||||
---
|
||||
title: "So we (the industry) really ever went back to the MSAA based TAA combinations and applied everything we learned in the past decade ..."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1884282476195110998"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1884282476195110998"
|
||||
date: 2025-01-28
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "So we (the industry) really ever went back to the MSAA based TAA combinations and applied everything we learned in the past decade ..."
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1884282476195110998
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-01-28 16:48:45
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
So we (the industry) really ever went back to the MSAA based TAA combinations and applied everything we learned in the past decade ...
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-just-raw-spatial-scaling-in-a-custom-resolve]]
|
||||
|
||||
**2/**
|
||||
|
||||
@NOTimothyLottes Hey that’s literally what our VRS is doing with all those tricks and more. We just don’t call it an upsampler ; )
|
||||
On PC we resolve MSAA to texture2DArray to retain plane separation benefits for bandwidth and coherency
|
||||
|
||||
**3/**
|
||||
|
||||
@MichalDrobot Larger differences are
|
||||
(1.) Your VRS is PSL'ing to a regular grid? (need the actual 8x pattern for what I'm suggesting)
|
||||
(2.) Sounds like you are getting benefit from FMASK due to the soft VRS, but for what I'm suggesting the NV flat+DCC layout is way better
|
||||
|
||||
**4/**
|
||||
|
||||
@NOTimothyLottes 1) it’s 4xMSAA but we DRS only on X axis which is matching your case I believe. Similar how it was done it Killzone Shadowfall.
|
||||
8xMSAA we could explore XY scaling
|
||||
2) depends. On PC it’s flat /w DCC. On gen8 it’s fmask packed. Gen9 is FMask with DCC plane0/1
|
||||
|
||||
**5/**
|
||||
|
||||
@NOTimothyLottes But sure I agree that 8x is the way to go for 4K. Our challenge is that we still have gen8 with 1k target and at those resolutions 8x scales really sub linear due to quad occupancy
|
||||
|
||||
**6/**
|
||||
|
||||
@MichalDrobot I guess the question then is if you implement variable spatial scaling in the custom resolve, is the 8xMSAA loss something that can easily be covered by increased spatial scale on the low end HW? 8x area scaling at 8xMSAA is still likely good for 3xAA on edges at spatial-only
|
||||
|
||||
Branches: [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the/2025-01-28-NOTimothyLottes-my-mindset-is-more-tuned-towards-rendering]]
|
||||
|
||||
**7/**
|
||||
|
||||
@NOTimothyLottes If low end hw is decent with MSAA AND you can control triangle density effectively to combat quad occupancy loss (we can’t) - that’s the best there is imo.
|
||||
FWIW that’s why we use stencil even for geo edges for MSAA - because we get too many interior edges that don’t do anything
|
||||
|
||||
**8/**
|
||||
|
||||
@MichalDrobot I see, yes once authoring pushes tri/pix density then what makes sense changes. I was thinking more of the way things had been authored in the relief mapping era.
|
||||
|
||||
**9/**
|
||||
|
||||
@NOTimothyLottes Then you need invest heavily into visbuffer for “simple draws” and pay setup price to compensate those deficiencies. involved pipeline that is not portable
|
||||
I can totally see your plan working for specific art styles or more retro gaming. There is a huge Indy market for this
|
||||
|
||||
**10/**
|
||||
|
||||
@MichalDrobot If tri/pix density is high, even if there are some huge triangles left, without substantially good multi-scale LOD (meaning cluster count scaling), I think soft culling alone falls off the !/$ curve for scaling - hints perhaps past the crossover for non-triangle rendering
|
||||
|
||||
**11/**
|
||||
|
||||
@MichalDrobot At that stage I'd have transitioned to direct final view reconstruction from object space domain. Walking object space, atomicMin(MSB{z,ref}LSB) at some good enough density into the final projected space, then use a neighborhood of 'refs' to get back to object space neighborhoods
|
||||
|
||||
**12/**
|
||||
|
||||
@MichalDrobot ... for the filtering. One can effectively cancel atomics per lane based on local projected screen-space density to deal with domain stretch (skinning), so it gets to be highly scalable.
|
||||
|
||||
**13/**
|
||||
|
||||
@MichalDrobot The TAA reconstructions all crossed that threshold of cost where it's easy to swap in reconstruction from something other than screen-space. And with no disocclusion trouble, object space is much less of a challenge to go from.
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Comparing matrix to quaternion code:"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1885175713638076657"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1885175713638076657"
|
||||
date: 2025-01-31
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "Comparing matrix to quaternion code:"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1885175713638076657
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-01-31 03:58:09
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
Comparing matrix to quaternion code:
|
||||
(A.) https://d3cw3dd2w32x2b.cloudfront.net/wp-content/uploads/2015/01/matrix-to-quat.pdf
|
||||
(B.) https://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToQuaternion/index.htm (Alternative Method)
|
||||
|
||||
A with conditional moves is probably faster on CPU
|
||||
B probably faster on GPU? (sqrt = 4 clk, copysign=BFI)
|
||||
Anything better than those?
|
||||
|
||||
|
||||
|
||||
**2/**
|
||||
|
||||
The (B.) alternative method might be just 32 VALU clocks on AMD, wrote up the code below (but warning didn't test it yet).
|
||||
|
||||
|
||||
@@ -0,0 +1,137 @@
|
||||
---
|
||||
title: "__/ \"GELATINOUS PIXEL SOUP!\" \\__"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1886572405176345062"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1886572405176345062"
|
||||
date: 2025-02-04
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "__/ \"GELATINOUS PIXEL SOUP!\" \\__"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1886572405176345062
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-02-04 00:28:06
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
__/ "GELATINOUS PIXEL SOUP!" \__
|
||||
Another spicy Threat Interactive video
|
||||
https://www.youtube.com/watch?v=KEtb0punTHk
|
||||
|
||||
Someone willing to challenge the status quo
|
||||
Lets talk about some of his topics ...
|
||||
|
||||
**2/**
|
||||
|
||||
Finally someone posting ms/frame breakdown!
|
||||
Appears to be using an actual mid-range GPU
|
||||
|
||||
[BLUE]
|
||||
Ray-reconstruction [RR] is 13x more expensive than the CNN TAA
|
||||
And already over the 120Hz frame budget
|
||||
Even at 60Hz you'd be giving up the majority of your frame budget to AI
|
||||
|
||||
|
||||
|
||||
**3/**
|
||||
|
||||
[ORANGE]
|
||||
Transformer model being almost 2x the cost of the prior CNN model. Double the cost for less ghosting.
|
||||
|
||||
Note STP (non-ML) was targeting 1/3 to 1/2 of the cost of that old CNN model with an analytical model which removed the ghosting on opaque geometry with motion vectors.
|
||||
|
||||
|
||||
|
||||
**4/**
|
||||
|
||||
It is certainly possible to engineer a bunch of very low cost and high quality human written shader solutions for scaling-TAAs that do better than the ML ones in !/$ for the non-ray-reconstruction cases
|
||||
|
||||
**5/**
|
||||
|
||||
NV banking on poorly optimized PC titles though is NOT a new thing: lets rewind to 2012!
|
||||
|
||||
2011> AMD 7970 = 3.8 Tflop/s 264 GB/s
|
||||
2012> NV 680 = 3.1 Tflop/s 192 GB/s
|
||||
|
||||
NV is way under-powered!
|
||||
Yet NV wins because of game-ready drivers
|
||||
|
||||
|
||||
|
||||
**6/**
|
||||
|
||||
NVIDIA was always about enabling dev laziness, the RT+AI+Fake era is just the ultimate form of that, where the lazy dev is marginalized to a few % of the total frame budget with AI taking the majority.
|
||||
|
||||
**7/**
|
||||
|
||||
Others playing "follow-the-leader" unfortunately still didn't catch on to the most important point, that Jensen's plan forces consumers to buy into only high-end cards to fix all the PC game problems. Nothing about the AI future scales down!
|
||||
|
||||
|
||||
|
||||
**8/**
|
||||
|
||||
Jensen's "Low-End" = 5070 is 1/3 the VALU of a 5090
|
||||
|
||||
But something like SteamDeck vs 5070
|
||||
is 1/19 the VALU and 1/7.6 the bandwidth
|
||||
|
||||
Already today, without scaling-TAAs on 5080, many "high-end" PC games either struggle to hit 60Hz at 4K or cannot make it to 120Hz ... ouch
|
||||
|
||||
**9/**
|
||||
|
||||
So Jensen's AI future depends on big GPU$$$$
|
||||
|
||||
And all other non-NV IHVs and OEMs build substantially smaller GPUs (Apple) or focus on value (everyone else)
|
||||
|
||||
Following Jensen's path is suicide, because they won't have the baseline GPU mass required to play
|
||||
|
||||
**10/**
|
||||
|
||||
Should feel extra sorry for someone like Qualcomm who though they could just make an RT core and follow the baseline HW requirements, but completely missed the point that NV would just raise the ray-reconstruction cost to a place Qualcomm could never get to
|
||||
|
||||
**11/**
|
||||
|
||||
AMD/others can easily extend out 1-fake frame to N-fake frames, and they all have timewarp for VR experience, so doing the fake latency thing is trivial too. And maybe FSR4/etc ML based non-RR scaling-TAAs hit DLSS parity soon
|
||||
|
||||
But NVIDIA has already pivoted to ray reconstruction
|
||||
|
||||
**12/**
|
||||
|
||||
At the end of the day, it is actually unreasonable to expect IHVs to do anything other than follow NVIDIA if PC engines just eat up RT and get bottle-fed on AI. Even if AMD or anyone makes awesome divergent tech, if it isn't mass market engine adoption it will go no where
|
||||
|
||||
**13/**
|
||||
|
||||
Likewise how can we expect major AAA engines to take on the uncertainty and insane R&D challenge of getting off their current NV evolution paths and do something radically different, it's just too high risk
|
||||
|
||||
**14/**
|
||||
|
||||
So the industry is somewhat in a live lock condition where it won't make forward progress
|
||||
|
||||
**15/**
|
||||
|
||||
Related story. So the reason I left AMD for Unity was because Unity was spinning up an R&D team for scalable high-end graphics. And our target was mobile through high-end PC. And left alone we would have got there. But the stock crashed and we got axed or forced out.
|
||||
|
||||
**16/**
|
||||
|
||||
I think ultimately those in the industry who don't like the current status quo, it's on you to build the tech yourself and ship it in an game to prove it is possible. Because it isn't likely that anyone has the pockets deep enough to fund a new general purpose engine on risky R&D
|
||||
|
||||
**17/**
|
||||
|
||||
@NOTimothyLottes What are some problem areas you think need to be tackled? I’ve read some of what you’ve written in response to some of the gripes of modern day temporal supersampling/AA. What else? Anything that IHVs would be uniquely positioned to do?
|
||||
|
||||
**18/**
|
||||
|
||||
@0xpatrickhan There is a laundry list of things IHVs dont expose or expose very poorly for basic compute shaders, making it quite difficult or impossible to get a compiler to do the right thing. Fix those and devs like myself could easily build better than AI tech options
|
||||
-62
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: "https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related read, also I'm a little late to the https://ntdoc.m417z.com/system_hypervisor_user_shared_data party, but will have that sorted soon as well"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/2060191401883619479"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "2060191401883619479"
|
||||
date: 2026-05-29
|
||||
archived: 2026-08-23
|
||||
draft: true
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- NOTimothyLottes
|
||||
description: "https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related read, also I'm a little late to the https://ntdoc.m417z.com/system_hypervisor_user_shared_data party, but will have that sorted soon as well"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/2060191401883619479
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2026-05-29 02:48:01
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related read, also I'm a little late to the https://ntdoc.m417z.com/system_hypervisor_user_shared_data party, but will have that sorted soon as well
|
||||
|
||||
**2/**
|
||||
|
||||
Other thought, I typically mmap an extra LOG file, and write via atomic to grab a fixed width line. No stdout. The log wraps around and exists for multiple executions or even parallel processes. It's the way to do it ... BUT ...
|
||||
|
||||
**3/**
|
||||
|
||||
... I think I'm going to just move the LOG file into the first N KiB of the CART file. So mmap'ed on CPU and GPU, and I can just bank on how "less" doesn't actually load the entire file while printing, so I can still see output on a console if needed for debug.
|
||||
|
||||
**4/**
|
||||
|
||||
And another random thought, can you force de-power the CPU by abusing the https://www.felixcloutier.com/x86/pause instruction for things that are not spin-loops :) Going to have to try this one at some point.
|
||||
|
||||
**5/**
|
||||
|
||||
Pushing data to GPU is really a no-brainer (write-combined stores), minus possibility of non-atomic write visibility, so I do simple stuff like always having a ring buffer of packets available where the GPU can validate each entry with a HASH, taking the latest valid one to use
|
||||
|
||||
**6/**
|
||||
|
||||
Also AMD exports non-cached memory in VK, so it's possible to poll on data the CPU pushes (via write combined stores to VRAM) on AMD a few times per frame even.
|
||||
|
||||
**7/**
|
||||
|
||||
The workaround for NVIDIA is if one wants to read N times per frame, then the CPU needs to duplicate the packet ring to N separate lines. Then the GPU is free to poll, but using separate cachelines each time.
|
||||
|
||||
**8/**
|
||||
|
||||
The route back for IO that needs to be routed through the CPU {audio out, network out} is a lot more unfun. AMD again has the nice uncached memory support, so that part is easy. NVIDIA well, would have to take the crappy mid-frame L2 writeback (likely) making CPU-read available
|
||||
|
||||
**9/**
|
||||
|
||||
Those who have tread here before with driver side logic (DMA transfers/etc) got screwed, Win+Linux driver idiots and their CPU interrupt based scheduling = completely useless. So getting the driver out of the picture is the way to go
|
||||
@@ -41,7 +41,13 @@ tags:
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-16-then-there-are-rough-edges-to-texel-buffer]]
|
||||
- [[archive/threads/NOTimothyLottes/2024-12-21-not-sure-if-this-is-the-end-of-this-story-yet-but]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-04-for-the-love-of-octahedrons-https-fileadmin-cs]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-06-one-of-the-downsides-of-v-cndmask-b32-on-amd-is]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-09-just-for-fun-started-to-look-into-cardinal-cubic]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-22-simple-napkin-analysis-of-that-high-end-crt]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-26-often-overlooked-aspect-of-gpu-perf-scaling]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-28-so-we-the-industry-really-ever-went-back-to-the]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-01-31-comparing-matrix-to-quaternion-code]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-02-04-gelatinous-pixel-soup]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-04-16-cs-optimization-brain-dumping]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-04-30-3-i-got-side-tracked-by-building-a-language-that]]
|
||||
- [[archive/threads/NOTimothyLottes/2025-04-30-i-laugh-when-people-say-c-is-like-assembly-they]]
|
||||
|
||||
@@ -25,5 +25,6 @@ Example of the note shape (single spine, no branches): [[archive/threads/How to
|
||||
- [[archive/threads/kenpex]]
|
||||
- [[archive/threads/mmalex]]
|
||||
- [[archive/threads/rianflo]]
|
||||
- [[archive/threads/simplex_fx]]
|
||||
- [[archive/threads/valigo]]
|
||||
- [[archive/threads/winning_tactic]]
|
||||
+122
@@ -0,0 +1,122 @@
|
||||
---
|
||||
title: "@simplex_fx @SebAaltonen Yeah it's a common problem, thin wrapper interfaces reduced to the worst platform's caps then called at high frequency ..."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/NOTimothyLottes/status/1890421311962239323"
|
||||
author: "NOTimothyLottes"
|
||||
handle: NOTimothyLottes
|
||||
post_id: "1890421311962239323"
|
||||
date: 2025-02-14
|
||||
archived: 2026-08-25
|
||||
draft: true
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "@simplex_fx @SebAaltonen Yeah it's a common problem, thin wrapper interfaces reduced to the worst platform's caps then called at high frequency ..."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1890348863287943363"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/NOTimothyLottes/status/1890421311962239323
|
||||
- Author: NOTimothyLottes (@NOTimothyLottes)
|
||||
- Posted: 2025-02-14 15:22:17
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@simplex_fx @SebAaltonen Yeah it's a common problem, thin wrapper interfaces reduced to the worst platform's caps then called at high frequency ... it's the recipe for poor software engineering
|
||||
|
||||
**2/**
|
||||
|
||||
@simplex_fx @SebAaltonen Arguments like: we cannot do bindless at the engine interface level because our Intel iGPU binding limits are too low, etc. Just another sign the engine interface failed when all platforms are crippled for the LCD, better if only the LCD platforms are crippled
|
||||
|
||||
**3/**
|
||||
|
||||
@simplex_fx @SebAaltonen My interfaces are like @simplex_fx perhaps, I only do either extremely high-level, or extremely low-level. So my graphics API is just this below ...
|
||||
|
||||
|
||||
|
||||
**4/**
|
||||
|
||||
@NOTimothyLottes @SebAaltonen what is the mark-unmark thing?
|
||||
|
||||
**5/**
|
||||
|
||||
@simplex_fx @SebAaltonen It is a 1:1 map to VkEvents. Mark:set signal after all prior launched dispatches have completed, unmark:clear signal, wait: wait for signal
|
||||
|
||||
**6/**
|
||||
|
||||
@NOTimothyLottes @SebAaltonen Do you have plans to publish your render?
|
||||
|
||||
Seems like some super nice and lightweight stuff.
|
||||
|
||||
**7/**
|
||||
|
||||
@simplex_fx @SebAaltonen The game/rendering side of my current project is too wild/game-specific to be of general usage, but the shell of the engine without the content, that I might release at some point into open source as an example
|
||||
|
||||
**8/**
|
||||
|
||||
@NOTimothyLottes @simplex_fx @SebAaltonen What’s the game?
|
||||
|
||||
**9/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen Across many years of working for IHVs and ISVs, I've been doing my own side project personal R&D prototypes geared towards solving all the key systems of a game I'd like to actually put into production some day
|
||||
|
||||
**10/**
|
||||
|
||||
@NOTimothyLottes @simplex_fx @SebAaltonen A combat flight sim MMO?
|
||||
|
||||
**11/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen Probably split it up into two: a single player vs world (low scope), then use that to fund what I really want to do which involves multi-player (high scope).
|
||||
|
||||
**12/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen FPS-like (more like 3D Descent [DOS], instead of fixed planar), trying to break ground more in world-scope simulation/thinking/destruction but not just thin on-planet-surface stuff, more like full planetoid interior [BLAME! style, an out-of-control world-building machine]
|
||||
|
||||
**13/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen Rewinding time, there have been some interesting milestones in PC gaming
|
||||
(1.) Command HQ (and similar) - Modem connected real-time multi-player world scale battle simulation with fog of war ...
|
||||
|
||||
|
||||
|
||||
**14/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen (2.) Starflight https://www.filfre.net/2014/10/starflight/ - procedural universe generation, but with persistent interaction, they actually saved game state back to the floppy disk ... might say today "No Man's Sky" is like a modern version of that procedural universe generation
|
||||
|
||||
|
||||
|
||||
**15/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen Forwarding in time a lot
|
||||
(3.) Teardown - expanding the lego-style chunky voxel engine with fully dynamic destruction, while still maintaining a high quality render
|
||||
|
||||
|
||||
|
||||
**16/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen But there are a lot of barriers that feel like speed-of-sound barriers (possible) vs speed-of-light (impossible) with PC game tech, examples
|
||||
(1.) Voxel games - they stay mostly chunky (you have games like Voxile pushing this a little, with in-voxel details)
|
||||
|
||||
|
||||
|
||||
**17/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen (2.) Physical simulation. NV PhyX had some absolutely amazing demos of destruction, but not really anything that went all in on massive destruction BECAUSE the game is still on the CPU, and the GPU is limited to just graphics ... seems like still a massive opportunity
|
||||
|
||||
**18/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen (3.) And the biggest one IMO: many do procedural generation and stop there. But it is the MIX of procedural rules and simulation that actually generates interesting behavior and content, that is very under-explored
|
||||
|
||||
**19/**
|
||||
|
||||
@AgileJebrim @simplex_fx @SebAaltonen So the inflection point IMO was GPUs getting fast enough compute where triangle rendering wasn't required, and then getting large enough memory, where one could devote it to {high/low frequency simulation,persistence,etc} instead of "textures"
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
+59
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "@simplex_fx @NOTimothyLottes I briefly discussed this topic in my SIGGRAPH 2022 talk."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/SebAaltonen/status/1890383966600888652"
|
||||
author: "Sebastian Aaltonen"
|
||||
handle: SebAaltonen
|
||||
post_id: "1890383966600888652"
|
||||
date: 2025-02-14
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "@simplex_fx @NOTimothyLottes I briefly discussed this topic in my SIGGRAPH 2022 talk."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1890348863287943363"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/SebAaltonen/status/1890383966600888652
|
||||
- Author: Sebastian Aaltonen (@SebAaltonen)
|
||||
- Posted: 2025-02-14 12:53:53
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@simplex_fx @NOTimothyLottes I briefly discussed this topic in my SIGGRAPH 2022 talk. The problem is that if you write a completely custom renderer for each platform, you have LOTS of platform specific code, which is super hard to maintain when your requirements change. 5x work for refactor is not fun.
|
||||
|
||||
**2/**
|
||||
|
||||
@simplex_fx @NOTimothyLottes Also with good design, you can almost 1:1 wrap Vulkan/Metal/DX12 under the same thin wrapper, so you don't end up wasting performance in a wrapper. Now you can write your low level rendering code once.
|
||||
|
||||
**3/**
|
||||
|
||||
@simplex_fx @NOTimothyLottes Good design == use placement heaps everywhere, use argument buffers (also in Metal) so that your memory management and binding model is identical. This way you don't need to send any data though the API wrapper. Write data directly to GPU memory, then call the wrapper to draw.
|
||||
|
||||
**4/**
|
||||
|
||||
@simplex_fx @NOTimothyLottes Also separating CPU->GPU data upload completely from drawing allows you to upload data at change frequency instead of draw frequency. Many big engines are slow as they upload data per draw call. That's bad design. Couples upload/draw tightly together. Must pay for both.
|
||||
|
||||
**5/**
|
||||
|
||||
@SebAaltonen @simplex_fx @NOTimothyLottes I've seen advised to use graphics queue (supporting transfer) for cpu write once gpu draw once data (immediate data recreated every frame).
|
||||
Then use separate data upload for data that suffers less frequent update (like per-instance scene data of a level editor).
|
||||
Is it bad advice?
|
||||
|
||||
**6/**
|
||||
|
||||
@SebAaltonen @simplex_fx @NOTimothyLottes Would this work for mobile phones?
|
||||
I thought that keeping the scene resident on the GPU relies on indirect draws with a count buffer (filled by a GPU culling computer shader) and bindless resources.
|
||||
IIRC, these two are not well supported on mobile phones.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "@simplex_fx @SebAaltonen @NOTimothyLottes Every time I abstract at a higher-level I end up precluding some use-case that I didn't anticipate, perhaps because I'm still learning and lack the whole picture."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/count_mascetti/status/1890351256641712490"
|
||||
author: "Conte Mascetti"
|
||||
handle: count_mascetti
|
||||
post_id: "1890351256641712490"
|
||||
date: 2025-02-14
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "@simplex_fx @SebAaltonen @NOTimothyLottes Every time I abstract at a higher-level I end up precluding some use-case that I didn't anticipate, perhaps because I'm still learning and lack the whole picture."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1890348863287943363"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/count_mascetti/status/1890351256641712490
|
||||
- Author: Conte Mascetti (@count_mascetti)
|
||||
- Posted: 2025-02-14 10:43:55
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@simplex_fx @SebAaltonen @NOTimothyLottes Every time I abstract at a higher-level I end up precluding some use-case that I didn't anticipate, perhaps because I'm still learning and lack the whole picture. I find it very hard to write high-level graphics abstractions that are performant and flexible enough.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "@simplex_fx @SebAaltonen @NOTimothyLottes You can do whatever you want the API."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/matiasgoldberg/status/1890396648662073353"
|
||||
author: "Matías N. Goldberg"
|
||||
handle: matiasgoldberg
|
||||
post_id: "1890396648662073353"
|
||||
date: 2025-02-14
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "@simplex_fx @SebAaltonen @NOTimothyLottes You can do whatever you want the API."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1890348863287943363"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/matiasgoldberg/status/1890396648662073353
|
||||
- Author: Matías N. Goldberg (@matiasgoldberg)
|
||||
- Posted: 2025-02-14 13:44:17
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@simplex_fx @SebAaltonen @NOTimothyLottes You can do whatever you want the API. Just because you can read from a GPU buffer you just wrote doesn't mean you should.
|
||||
|
||||
A thin wrapper allows enforcing certain guarantees and good practices to avoid race conditions or common corruption pitfalls
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "@simplex_fx @SebAaltonen @NOTimothyLottes I don't disagree..."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/RyDawgE256/status/1890554187336872420"
|
||||
author: "Nintendo DS"
|
||||
handle: RyDawgE256
|
||||
post_id: "1890554187336872420"
|
||||
date: 2025-02-15
|
||||
archived: 2026-08-25
|
||||
draft: true
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "@simplex_fx @SebAaltonen @NOTimothyLottes I don't disagree..."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1890348863287943363"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/RyDawgE256/status/1890554187336872420
|
||||
- Author: Nintendo DS (@RyDawgE256)
|
||||
- Posted: 2025-02-15 00:10:17
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@simplex_fx @SebAaltonen @NOTimothyLottes I don't disagree... but the reason is that 99% of programmers don't gaf about the specifics of their renderer... which is a shame... but an unambiguous fact nonetheless
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Usually the key benefit is two fold, making the code truly cross platform and decoupling user level code from a specific rendering api/backend."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/matthewcraig42/status/1890635763819446764"
|
||||
author: "Matthew Craig"
|
||||
handle: matthewcraig42
|
||||
post_id: "1890635763819446764"
|
||||
date: 2025-02-15
|
||||
archived: 2026-08-25
|
||||
draft: true
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "Usually the key benefit is two fold, making the code truly cross platform and decoupling user level code from a specific rendering api/backend."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1890348863287943363"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/matthewcraig42/status/1890635763819446764
|
||||
- Author: Matthew Craig (@matthewcraig42)
|
||||
- Posted: 2025-02-15 05:34:27
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
Usually the key benefit is two fold, making the code truly cross platform and decoupling user level code from a specific rendering api/backend. Without that if you change the underlying render API it will break all your user level code, and adding additional render backends is also challenging.
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "@simplex_fx @SebAaltonen @NOTimothyLottes the render pipeline is basically a full piece of software trapped in inside of another software"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/pagedeux/status/1890719137904709668"
|
||||
author: "Jing"
|
||||
handle: pagedeux
|
||||
post_id: "1890719137904709668"
|
||||
date: 2025-02-15
|
||||
archived: 2026-08-25
|
||||
draft: true
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "@simplex_fx @SebAaltonen @NOTimothyLottes the render pipeline is basically a full piece of software trapped in inside of another software"
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1890348863287943363"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/pagedeux/status/1890719137904709668
|
||||
- Author: Jing (@pagedeux)
|
||||
- Posted: 2025-02-15 11:05:44
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@simplex_fx @SebAaltonen @NOTimothyLottes the render pipeline is basically a full piece of software trapped in inside of another software
|
||||
|
||||
i guess that's why they call the compiled shader a "program"
|
||||
|
||||
it's kinda like mitochondria, it's also the powerhouse
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "@simplex_fx @SebAaltonen @NOTimothyLottes I have exactly that."
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/vanderschnarzen/status/1890804090046689518"
|
||||
author: "flo | paryonix3d"
|
||||
handle: vanderschnarzen
|
||||
post_id: "1890804090046689518"
|
||||
date: 2025-02-15
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "@simplex_fx @SebAaltonen @NOTimothyLottes I have exactly that."
|
||||
in_reply_to: ""
|
||||
parent_post_id: "1890348863287943363"
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/vanderschnarzen/status/1890804090046689518
|
||||
- Author: flo | paryonix3d (@vanderschnarzen)
|
||||
- Posted: 2025-02-15 16:43:19
|
||||
|
||||
## Branch
|
||||
|
||||
**1/**
|
||||
|
||||
@simplex_fx @SebAaltonen @NOTimothyLottes I have exactly that. My abstraction is basically just mesh and material. If you abstract on a low level you usually have to go with the smallest common denom- which prevents you from really taking advantage of a specific api. Opinions might differ, but that's just my two cents...
|
||||
|
||||
## Related
|
||||
|
||||
- Spine: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Hey, gpu guys like @SebAaltonen @NOTimothyLottes why do rendering guys usually wrap 3d apis at low level in engines, creating some generic mid-low level API?"
|
||||
type: archive
|
||||
source: twitter
|
||||
source_url: "https://x.com/simplex_fx/status/1890348863287943363"
|
||||
author: "Simplex"
|
||||
handle: simplex_fx
|
||||
post_id: "1890348863287943363"
|
||||
date: 2025-02-14
|
||||
archived: 2026-08-25
|
||||
draft: false
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
description: "Hey, gpu guys like @SebAaltonen @NOTimothyLottes why do rendering guys usually wrap 3d apis at low level in engines, creating some generic mid-low level API?"
|
||||
in_reply_to: ""
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
- URL: https://x.com/simplex_fx/status/1890348863287943363
|
||||
- Author: Simplex (@simplex_fx)
|
||||
- Posted: 2025-02-14 10:34:24
|
||||
|
||||
## Thread
|
||||
|
||||
**1/**
|
||||
|
||||
Hey, gpu guys like @SebAaltonen @NOTimothyLottes why do rendering guys usually wrap 3d apis at low level in engines, creating some generic mid-low level API?
|
||||
|
||||
My 3d engine have a few super high level functions for stuff I actually do, and the rest is totally up to platform/api specific code.
|
||||
|
||||
Unless you go with some super generic game engine (bad idea on it's own anyway), 3d engine should be also just specific to the use case.
|
||||
|
||||
Branches: [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-count_mascetti-every-time-i-abstract-at-a-higher-level-i-end-up]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-SebAaltonen-i-briefly-discussed-this-topic-in-my-siggraph]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-matiasgoldberg-you-can-do-whatever-you-want-the-api-just-because]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-14-NOTimothyLottes-yeah-its-a-common-problem-thin-wrapper-interfaces]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-RyDawgE256-i-dont-disagree-but-the-reason-is-that-99-of]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-matthewcraig42-usually-the-key-benefit-is-two-fold-making-the]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-pagedeux-the-render-pipeline-is-basically-a-full-piece-of]], [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why/2025-02-15-vanderschnarzen-i-have-exactly-that-my-abstraction-is-basically]]
|
||||
|
||||
**2/**
|
||||
|
||||
@simplex_fx @SebAaltonen @NOTimothyLottes Exactly the question I was asking myself lol. Always felt like 3D apis SHOULD be specific. But I’m just a noob
|
||||
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: simplex_fx
|
||||
type: note
|
||||
draft: false
|
||||
description: Archived threads by simplex_fx.
|
||||
tags:
|
||||
- archive
|
||||
- twitter
|
||||
- simplex_fx
|
||||
---
|
||||
|
||||
- [[archive/threads/simplex_fx/2025-02-14-hey-gpu-guys-like-sebaaltonen-notimothylottes-why]]
|
||||
Reference in new issue
Block a user