DDraceNetwork - developer

I also had this problem, but on linux

00:00

switching to opengl3.3 worked for me

unusual

00:01

i noticed that somehow, on my 2GB vram GT 1030, the game was able to load my plethora of skins on OpenGL 3 but not on Vulkan

00:01

does GL have some sort of automatic system memory backing for textures (edited)

yes

00:04

opengl manages the memory by itself

that's gotta be possible in vulkan right

00:11

you just have to do it yourself

furo321

[ddnet/ddnet] Pull request opened: #7069 Add a searchbar for demos.

https://github.com/ddnet/ddnet/assets/141338449/9be8b1bc-168f-458e-a9d7-488844fef917

Checklist

[x] Tested the change ingame
[x] Provided screenshots if it is a visual change
[x] Tested in combination with possibly related configuration options
[ ] Written a unit test (especially base/) or added coverage to integration test
[x] Considered possible null pointers and out of bounds array indexing
[ ] Changed no physics that affect existing maps
[ ] Tested th...

Yağız

Click to see attachment 🖼️

What's your hardware

Ewan

that's gotta be possible in vulkan right

Yes but swapping memory around can potentially be problematic

Jup how to make async skin and asset loading work good

06:27

Still stuck with the wait x ms on main thread approach

Why do u wait. What's the context for waiting?

If I don't wait then it just goes again and the other thread misses its chance to do its work. This happens a bunch of times until eventually, the main thread's and other thread's window of having finished line up to where the other thread starts, and then it hogs the thread

06:32

By waiting I'm expanding this window so that the other thread can do what it needs to pretty much every time

06:33

but it's fickle because it will have to be a different amount of time depending on speeds of stuff that we can't predict. i want to avoid it entirely

06:33

make it smart

So your problem is that new tasks are given too late?

well, the other thread is responsible for loading the file from disk, decompressing the png, and preparing the CImageInfo. that CImageInfo is added to a fifo which is protected by a mutex, and the main thread takes the CImageInfo and slices it & uploads its texture to the GPU whenever it gets a chance

Yep, and your problem is that the other thread blocks this mutex too often?

Yes

06:38

The other thread just works until its done, waiting only on the mutex. the main thread is obviously bound to the game refresh rate

Sounds Like you want to introduce condition variables

like a semaphore or smth?

But the problem is not that you simply have two million tasks? Xd

Ewan

like a semaphore or smth?

It's more like a notifier

they are not running in parallel, there are 2 tasks running at once

06:40

main & other

06:40

2 threads

06:40

im not using a thread pool or anything that would warrant one

Notify as soon as I can continue work . It frees the mutex while waiting

Ewan

they are not running in parallel, there are 2 tasks running at once

In this case i meant the tasks scheduled for the file loading. Not threads^^

ohhh ya i was gonna try that, and then i discovered that i couldn't do it without inheriting my other thread stuff from IJob iirc??

06:41

but now i am using a job

As in: the file thread is always busy

yeah

06:42

maybe i could try and make the cimageinfo atomic as well

06:42

so it just reads whenever it needs to without waiting

That doesn't work

sad