next »

[Orz]

Is there any fundamental reason why you can't, say, use 4 threads to render each quarter of the screen, and get a performance boost?  I'm talking about 2D graphics that are *not* accelerated by a graphics card. 

I guess each thread would need access to the game data (which entities are at which locations), and you would need to lock them until all of them were finished before you flipped the frame buffer.  But I haven't really thought this through.  Has anyone been down this road before?

[Layl]

For 2D not accelerated, there's no reason you couldn't do this, but the bonus speed won't be as good as just going accelerated. For 2D accelerated, perhaps in vulkan or dx12, definitely not in OpenGL.

[InfiniteStateMachine]

If you draw to some rgb array by yourself then pass it to the OS then it might work. Even with hardware rendering a similar approach is taken when building up your render context submissions. You are still bottlenecked when piping the built up data though.

[Cheesegrater]

It works. There are a number of raytracers that do this.

[InfiniteStateMachine]

In the raytracers case the relative amount of time it takes to render a bucket is massive compared to the actual drawing time.

[Cheesegrater]

Yes, which is their motivation for dividing up the screen (or in some cases, scanlines to fill in over time like an old-school progressive JPEG).

For a typical 2D game, this is massive overkill and not going to be worth the implementation time. But maybe someone is trying to do some other kind of global image processing. Radiosity? Hough voting? There are non-game apps that would do it.

[InfiniteStateMachine]

Oh for sure, there's a ton of valid cases to use it. I was speaking from the context of the original post where the actual drawing is relatively trivial and probably not worth the implementation time.

[Orz]

My motivation is that I have a game running with 2D unaccelerated graphics.  I have gotten to like it because it cuts out a lot of layers of lasagna code and simplifies the programming, especially for things like reflective surfaces or translucent objects.

It runs OK, but there is a noticeable drop in frame rate if I run it at, say, 1080p.  If I could halve the render time by multithreading, it would give me more wiggle room for other parts of the render loop where I don't want the extra code complexity.

[InfiniteStateMachine]

Do you know where you're losing time? If you profile is the cause of performance issues drawing to your canvas?

[Shashwah]

I actually tried working on something similar to this, it means that you would need to track what area of the screen that each rendered object is in; I found that it's not too hard if you have a world to screen coordinate system and base it all off that, after that you just render normally but only swap the screen buffer once all four threads have returned, or that's just what I did, you can probably have them all update asynchronously but I never attempted that.

[Orz]

Do you know where you're losing time? If you profile is the cause of performance issues drawing to your canvas?

I have no idea where the bottleneck is.  It is proportional to viewport size and not number of entities, so I assume it has to do with drawing to the canvas, but it could also be downstream of that (and out of my hands).  Just tossing this idea out there to see what my options are.

[Garthy]

In my current project I am splitting some of the CPU-based graphics workload between multiple threads before combining them at the end. It isn't really say rendering a quarter of the screen exactly, but it is based on doing certain calculations concurrently based on splitting the game world. Basically, I queue up a large bundle of tasks, and I have multiple threads grabbing a task from the queue until the queue is empty and they are all finished.

So, if I can loosen the criteria to splitting the game world rather than the display specifically, then yes, you most certainly can do that.

You do need tasks that are fairly coarse-grained (or you lose time rather than gain it), and it only really works well for tasks that are inherently parallel, and tasks that don't require too much waiting on data being passed between the tasks.

Also, if we go GPU-side then something close what you are describing happens when using SLI.

[Layl]

I have no idea where the bottleneck is.  It is proportional to viewport size and not number of entities, so I assume it has to do with drawing to the canvas, but it could also be downstream of that (and out of my hands).  Just tossing this idea out there to see what my options are.

Then start profiling. Don't optimize if you don't know if it will actually help.