how will multi-threading work about blend2d HOT 11 CLOSED

Multithreaded rendering context will use multiple worker threads to process render commands within the same context. It will work like the following:

• Each render command will be enqueued instead of rendered synchronously
• When the command queue reaches certain limit the engine would signal worker threads
• Each thread will render the whole queue in bands, when done it will move to the next available band

This means that the rendering will be asynchronous.

There are few challenges here, but the idea is solid and I have already started working on it. The idea of bands makes rendering very cache friendly as each worker pass (rendering the whole queue of single band) will be limited to only a certain part of the destination image. In addition, if there are bands where nothing happens these could be skipped quickly so the work should be evenly distributed across workers.

So yeah, I plan to have something ready for experimenting very soon.

from blend2d.

great. I'm a bit skeptical as to whether worker threads will improve over what a single processor pinned thread can do. Are you concerned with context switch time being a waste vs the benefits of multiple threads? Are you going to pin threads on different cores? What about memory bus conflicts? I've never really tried having multiple threads write into same memory, so I'm not too familiar with how performant it's going to be, or how contentious.

from blend2d.

The idea is that threads will not write into the same memory. The reason I use bands is that workers will only access bands, and each worker will only access specific bands, so it should theoretically not happen that two threads would write into the same memory.

The reason of command queue is to minimize synchronization. If one worker processes for example 256 batched commands at once and then synchronize it's much better than synchronizing after each command.

from blend2d.

by 'same memory' I really mean at a systems level. There's only one RAM, and one bus (or maybe two) to get from the CPU to it. Having multiple threads trying to write to RAM at the 'same' time might cause some contention? Maybe that kind of contention is so much less these days as you state, you intend to be cache friendly, so most likely no real contention that any human will notice.

I get the apparent speedup of the queue of commands. This is essentially parallel vs serial. The only caveat is i'll have to rely on flush, or sync if I care to ensure my buffer is actually complete, or at least that all the outstanding commands have been written.

I'm thinking you might need a barrier of some sort that I can grab so that I can sync to that barrier. Otherwise, new commands might come in while I'm waiting? And I'll never sync? Or do you just check lengths of queues at time of sync call, and process that many commands?

from blend2d.

oh, and I love command queues. Very multi-task friendly, scalable, and remotable.

from blend2d.

A main memory read is about 10 times faster than a context switch which requires to store the whole register set. Nowadays done by a shadowing unit to speed things up.

from blend2d.

Are you suggesting single thread will outperform? Im guessing with threads pinned to cores, this is essentially true parallelism, with minimal context switch? T least if that's what's sought, i can believe it will outperform single thread. Otherwise, context switching on single core doesnt sound particularly speedy, dependwing on mix of compute vs pure memory manipulation.

But, im no asmjit expert, im curious to see how it works out.

from blend2d.

I don't plan pinning threads to particular cores btw, here I think that OS should distribute the work better, imagine 5 apps pinning a particular thread to the first core, they would fight for it. The idea of MT in Blend2D is to distribute the work evenly across N threads with minimized synchronization (ideally the sync would only happen after X commands like 128, 256, etc).

It will work out, I have done it once, now I'm gonna do it even better, just need a bit of time to finish :)

from blend2d.

Yah, I'm definitely not the expert on multi-threaded drawing, so I'll trust your experience. My line of questioning here shows my naivete, and I'm happy to be schooled in the finer arts of modern day multi-core programming. I am so looking forward to this working as it will be a great learning moment.

from blend2d.

Are you suggesting single thread will outperform?

No, my answer relates to your fear about multiple threads accessing RAM. Since there is a hierarchical memory architecture anyway, context switches are much worse than trying to access the RAM. Which means: I don't share your fear ;-)

from blend2d.

Ill close this as it was just a discussion

from blend2d.