Nicholas Chapman
@NickChapmn
Followers
166
Following
6K
Media
120
Statuses
1K
programming / c++ / graphics / physics / functional languages blog: https://t.co/Y926PCnkhY Working on https://t.co/3U2GavxvQH and more
Wellington, NZ
Joined July 2023
The web view now keeps the frames on the GPU without any GPU->CPU->GPU copy. Results in much smoother playback without stutter.
3
2
26
Got hardware-accelerated video playback working, piping frames directly into the Glare engine as OpenGL textures. Uses Windows Media Foundation for video decoding.
2
0
5
So I tried @grok . It seems it’s not as heavy censoring in place as in Sora. Which is a good place to create from. Good move by Elon. — OP
4
1
2
Multi-threaded the Winter script evaluation in @SubstrataVr. Fairly pointless - Amdahl's law strikes again (note the part labelled 'serial work')
0
0
3
Was thinking of writing a little on using a custom arena allocator with STL objects (string, vector, set etc.) but it looks like it has been adequately covered before.
0
0
5
Not sure If I can have my cake and eat it too - safety and performance. Possibly C++ is just a bit underpowered for that.
0
0
1
Trying a custom STL allocator which references an arena allocator. It works, and is faster than before, but is very dangerous - if an STL allocator outlives the arena scope/lifetime then get a crash.
1
0
3
Interestingly the CPU time is rounded by chrome to the nearest ms, but GPU times, as they are elapsed times, so presumably aren't as useful in timing attacks, aren't noticeably rounded.
Got the CPU and GPU frame time graphs working in the web client as well.
0
0
5
Timestamp queries not available in webgl on chrome, arrhghh:
0
0
1
I'm gonna propose a name for this kind of thing, something like 'latched performance cliff'
Found something very lame while investigating a performance anomaly. Making an OpenGL context current on another thread (and not even using it), results in an increase in render time from 5.36 ms to 5.66 ms, e.g. a drop from 186 fps to 176 fps.
0
0
2
It's an in-memory database, so the question of how fast does the database run is really how fast is your RAM?
0
0
1
How fast does the substrata server render pages: with some unoptimised code: page rendering took 29100 ns That includes the database lookups. So that's 29 microseconds or 0.029 ms.
2
0
3
On the plus side, hitting 200 fps in the middle of the substrata world, or 320 fps without SSGI!
0
0
3
Also looks like multi-draw elements indirect isn't a win any more in Substrata, due to the chunking optimisations I made a while ago. Basically fewer draws needed means the overhead of MDI becomes too large.
1
1
3
This is with a RTX 3080. This is very annoying as Nvidia's advice and debug output encourages you to use another thread for geometry and texture uploads to the GPU.
0
0
2
Found something very lame while investigating a performance anomaly. Making an OpenGL context current on another thread (and not even using it), results in an increase in render time from 5.36 ms to 5.66 ms, e.g. a drop from 186 fps to 176 fps.
1
0
4
NZ should have a public holiday in honour of free speech martyrs, we could call it Mass Debate Day.
3
2
27