tynet-lichat/shirakumo - IRC Chatlog
Search
16:54:40
shinmera
This without-scheduling thing looks like it only works with cooperative multithreading, not with system threads.
16:57:19
Grolter
There seems to be some work done on native threads, but seems like they are not included in current releases
18:59:35
|3b|
shinmera: i'd probably reset the pixel store stuff after uploading, and is :pack-* what you want there? thought it would be :unpack-
19:01:25
|3b|
ACTION also wonders whether -images and -rows affect things with lower dimensions... way it is described there doesn't say it doesn't
19:03:39
shinmera
I'm already unhappy with how long loading a single model takes, so I'll have to do some benchmarking soon, I imagine.
19:09:12
|3b|
as noted by the docs they are just pointer increments, and doing it yourself would let you check against your pointer size since you have one
19:13:13
|3b|
you would need a bytes per pixel, since some have odd channel sizes but still pack a pixel into bytes
19:13:42
shinmera
yeah, I forgot that the pixel-type thing determines the number of bytes per pixel and is always octet aligned.
19:14:42
|3b|
hmm, another argument for merging on gpu (or splitting instead of merging), compressed textured would be hard to merge on cpu
19:15:57
shinmera
also isn't compressed stuff only on the internal format, and not the pixel data you upload?
19:17:57
|3b|
from most code you can just treat it as "everything has to be in NxN blocks" and "an NxN block takes M bytes"
19:18:44
|3b|
but you have to make texture multiple of block size, and align copies/uploads/etc to blocks
19:19:23
|3b|
if you want to actually compress/decompress them, there are specs, which aren't actually that bad just lots of bit fiddling
19:20:14
shinmera
I kinda doubt I'll ever reach a point where texture space issues are gonna be a big deal
19:21:08
|3b|
there are libraries that have a more general compressed texture format that can be quickly translated into the formats hardware supports for cases where you need to support lots of hardware across desktop+mobile
19:21:52
|3b|
probably more important on mobile, both from lower ram and for transfer, but still can be nice on desktop
19:22:40
shinmera
I mean, I certainly wouldn't turn down anyone's work if they were interested in working on that ;)
19:23:46
|3b|
aside from size i think it can also help with memory bandwidth a bit, though like size that is just shifting your hardware requirements a bit
19:24:20
shinmera
I remember I was hitting memory bandwidth while implementing the geometry clipmap stuff.
19:25:08
|3b|
yeah, predictable size and decompression time is also nice compared to normal formats on disk for streaming
19:36:39
selwyn
if only i had your writing skills maybe i would have more time to actually do things
19:37:49
shinmera
meh, my experience with a job was that I had zero energy to do anything I wanted to do
19:46:21
selwyn
next week i will spend some time out of hours working on a paper i started towards the end of my phd
20:41:33
|3b|
even not getting it could improve your work... if more unqualified people just stay home, reduced competition could make it more likely to get a job you like
20:42:04
|3b|
also more people staying home might make for a better commute (if applicable), which could also help
20:49:09
shinmera
cl-fbx is done, but I can't scrounge up the motivation to do the final translation step to actually import into trial.
20:51:54
shinmera
getting some of these fixed up would also be nice https://github.com/Shirakumo/cl-mixed/issues/3
21:09:52
shinmera
I'm fine with the wav output, since that can be trivially reencoded by ffmpeg to whatever we need.
21:16:48
shinmera
I did look at that briefly, but honestly AAudio should be supported on like 90% of devices
21:17:34
shinmera
Cause honestly those remaining 8% are probably crappy enough not to run things for other reasons, too