<geist>
dunno if thats a common trick but i can see why it works fairly well
<zid>
all data is big endian..?
<zid>
what is this, 1983?
<moon-child>
ah yeah I saw that
<moon-child>
nice they added a slot for colourspace
<geist>
heh, well you sometimes gotta give em that
<moon-child>
zid: meh it's just in the file header, no biggie
<klange>
That has been a common thing in all the places this was posted.
<geist>
but really it's only the header, since all the fields from then on out are 8 byte fields
<zid>
RLE + delta + zip
<zid>
seems pretty normal
Oli has joined #osdev
Oli has quit [Client Quit]
<geist>
yah, indeed. nothing new, but it seems pretty efficient
<moon-child>
'top to bottom, left to right' that means: first top to bottom, then left to right? Strange if so
<zid>
yea they've written that backwards I hope
Oli has joined #osdev
<geist>
the hash + index thing seems interesting, but that may be how the dictionary works on zip? i honestly never looked into how dictionaries work in those compression format
<zid>
cus that's *awful* for cache, obviously
<geist>
you could read that as 'overall it's top to bottom, and within each line left to right'
<geist>
but yeah badly worded. i got the impression they were trying to cram it into a single page a bit too hard
<moon-child>
zid: well, only cuz framebuffers are laid out that way
<moon-child>
but you could easily do a fully column-based thing and transpose only at final blit. Wouldn't be _that_ bad
<geist>
i remember nvidia textures use this hilbert curve like zig zag format thats kinda a brain teaser
<geist>
but i think it has really good cache locality in some clever way
<moon-child>
huh neat
<zid>
yea but it also renders images in tiles
<zid>
so it makes sense
<geist>
righ
<geist>
i think it also is based on some notion that texture fetches are usually clustered
<moon-child>
that makes sense but seems like kinda annoying to convert from tex coord space
<zid>
You're more likely to be able to grab a cache line that represents a nearby tile if you're hilberting
<geist>
so the way it works at any point inside the texture you are nearby pixels in all directions
<zid>
because images tend to have similar stuff near each other
<zid>
in 3D space
<geist>
it's not exactly a hilbert but iirc it's a Z shaped fetch that is recursive
<moon-child>
making it work well for NPOT sizes seems annoying too
<zid>
So like, a scene with a sky and a floor and an object in the middle
<geist>
ie, divide into 4 quadrants, draw a Z through that. within each quadrant subdivide it into a quadrant, all the way down
<geist>
power of 2 sizes
<moon-child>
only pot?
<zid>
that object in the middle will be on a bunch of scanlines on random columns
<zid>
but with the hilberty thing you tend to render the whole object in one go
<zid>
which means the texture you loaded to map that object with is all you need to grab from cache for huge stretches of time, that way
<geist>
moon-child: i think only POT because textures are POT
<geist>
though this was PS3 era tech, so around 2007. no idea if they still do it
<moon-child>
geist: you can get npot textures these days. ps3 yeah maybe not
<geist>
but i remember it was A Thing when doing PS3. it was much more efficient than linear textures, so there was an actual tradeoff if you rendered into a texture and then fed it into the GPU as an input texture. ie, shadow maps
<geist>
ie, you might want to get a SPU to actually convert as a background job before the next frame or so
<geist>
if you blatted it into the SPUs ram it had 256K of zero wait state to run out of, so it was pretty ideal for doing a translation
Oli has quit [Quit: leaving]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
tryte has joined #osdev
tryte has quit [Quit: leaving]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
amine has quit [Quit: Ping timeout (120 seconds)]
amine has joined #osdev
xenos1984 has quit [Quit: Leaving.]
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
xenos1984 has joined #osdev
* kingoffrance
watches 584 line script generate 55M script...and growing...130M...probably will end up 250M lol. its just lots of long filenames. will compress down to like 5M most likely
riv has left #osdev [WeeChat 3.3]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
xenos1984 has quit [Quit: Leaving.]
xenos1984 has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
GeDaMo has joined #osdev
bauen1 has joined #osdev
adachristine has joined #osdev
adachristine is now known as gog`
ravan has quit [Remote host closed the connection]
ravan has joined #osdev
bauen1 has quit [Ping timeout: 240 seconds]
gog has quit [Quit: byee]
bauen1 has joined #osdev
stosby has joined #osdev
nyah has joined #osdev
gog` is now known as gog
freakazoid343 has quit [Read error: Connection reset by peer]
<robyndrake>
hey gog
<gog>
oh hey lol
stosby has left #osdev [WeeChat 3.4]
<robyndrake>
gog, mind a PM?
<robyndrake>
brb anyway
<gog>
robyndrake: sure go ahead
bauen1 has quit [Read error: Connection reset by peer]
CaCode has joined #osdev
bauen1 has joined #osdev
ahalaney has joined #osdev
CaCode_ has joined #osdev
sicrs has joined #osdev
CaCode has quit [Ping timeout: 256 seconds]
sicrs is now known as stosby
stosby has quit [Client Quit]
bauen1 has quit [Ping timeout: 240 seconds]
bauen1 has joined #osdev
dennis95 has joined #osdev
dude12312414 has joined #osdev
CaCode_ has quit [Quit: Leaving]
stosby has joined #osdev
stosby has left #osdev [#osdev]
bauen1 has quit [Ping timeout: 245 seconds]
sonny has joined #osdev
mctpyt has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
mctpyt has quit [Ping timeout: 240 seconds]
sonny has quit [Ping timeout: 240 seconds]
ElectronApps has quit [Remote host closed the connection]
ajoberstar has joined #osdev
freakazoid343 has joined #osdev
sonny has joined #osdev
freakazoid343 has quit [Ping timeout: 260 seconds]
<j`ey>
for LLVM I build my own clang/lld, thought it might be useful to build gcc too
<geist>
yah llvm is i think a tougher order. my experience with building it is even without LTO you need a pretty beefy machine. an 8GB rpi4 probably can do it, but a 2 or 4GB might have swapping issues in some of the compiles
<geist>
LTO is Right Out
<geist>
even on like a 32 or 64G machine you can run out of ram with LTO clang builds
<j`ey>
yeah I dont bother with LTO
<j`ey>
I build llvm from git, but since I dont update very often, incremental builds dont really help
<geist>
yah i dunno precisely how to build clang with LTO. seems like it should be possible to use ninja's pool feature to put links in a smaller pool of only say 4 at a time, but the build system doesn't seem to take advantage of that
<geist>
and/or there's some switches you're supposed to Just Know how to set
<kazinsal>
supercomputer rental
<geist>
but yeah my guess is it's mostly just supercomputers. we have build machines in fuchsia for example that have 1TB ram
dennis95 has quit [Quit: Leaving]
<kazinsal>
you can rent a linode with 16 vCPUs and 300GB of RAM for a buck and a half per hour
<kazinsal>
so I guess if you want to fully LTO your clang build you just spend a few bucks and remember to deactivate the VM after your build is done
<j`ey>
1 TB ram is pretty nice
<geist>
yah
<geist>
i think regular builds aren't 1TB, but i seem to remember the toolchain folks topping off some of the thunderx workstations with 1TB so they can do MAXIMUM PARALLEL builds. with 256 cores actually 1TB is only 4GB per thread
<geist>
or conversely, 256 cores + 128GB you can oversubscribe pretty easily
freakazoid333 has joined #osdev
CryptoDavid has quit [Quit: Connection closed for inactivity]
freakazoid12345 has quit [Ping timeout: 240 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
sprock has quit [Ping timeout: 245 seconds]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
biblio has quit [Quit: Leaving]
<Ameisen>
o_O
<Ameisen>
you know the 'normal' way of definine something like #define _assume(expr) do { if (!(expr)) __builtin_unreachable(); } while (0) on GCC?
<Ameisen>
it has the issue that if the 'expr' has side-effects, the assume will actually still execute said code
<Ameisen>
I think I found a way to make it _not_ do that in some cases
<Ameisen>
only if the expr relies on a function, though :(
<Ameisen>
using __attribute__((const, copy(func)))
wand has quit [Remote host closed the connection]
wand has joined #osdev
<geist>
i thought there was some sort of built in eval once without side effects thing
<geist>
i dont remember what
wolfshappen has quit [Ping timeout: 240 seconds]
sprock has joined #osdev
<graphitemaster>
null-coalescing operator
<graphitemaster>
expr ?: value, will evalu expr once without side effects
<Ameisen>
evaluating expr itself, if expr _may_ have side effects, causes the evaluation to still be emitted
<Ameisen>
where in this case we do not want it emitted at all