Ouchface
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Is any software rendering port using OpenCL?
 
Author
All times are GMT. The time now is 17:02. Post New Thread    Post A Reply
printz
CRAZY DUMB ZEALOT


Posts: 8890
Registered: 06-06


Are there any Doom ports which don't use the GPU for rendering graphics, but for other operations, such as a playsim with lots of actors (nuts-like)? Is OpenCL of any use here?

Just throwing it there, the concept seems interesting, I'll look into it when time comes to try something performance demanding :)

__________________
Automatic Wolfenstein - Version 1.0 - also on Android

Old Post 08-12-12 20:45 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12749
Registered: 07-06


The examples shown aren't really all that different from designing your own task-specific thread objects in Java, C++ or C# (been there, done that in pre-grad), and there's not even a syntactic sugar a-la Apple's "Grand Dispatch Central". The only difference will be -maybe- the portability of said code and the "free" application to any GPU, instead of doing language-specific black thread juju, assuming the framework itself is more ubiquitous than this or that multithreading library.

However, seeing how the language it's based on is C99 "with some limitations and additions", and that it's best suited for massively parallelizable mini-tasks ("functions"), I can't think of anything more unsuitable for running Doom, at least not without major changes to the engine itself.

Until someone comes and throws the traditional Doom state model away (and allows mobj interactions to become non-deterministic), no such proposals would really work. Too much stuff to keep in sync, which would degenerate everything into serial execution (even though in disguise).

E.g. while in theory one could say that actor state functions (A_ stuff) could run as many parallel "OpenCL minitasks", the problem is in what order? Random? A forced one? A mixed model?

As for graphics, it won't have any advantages performance-wise over the current multithreaded rendering ports: there's still a lot of work-splitting, task-syncing and status-duplication to take into consideration, and the final benefits can't exceed a 100% speedup (if gameplay/serial rendering CPU time are perfectly equal, and if you manage to reduce rendering time to zero).

Finally, not quite the same thing, but the Android Doom ports use a temporary OpenGL surface to actually draw the screen buffer to the screen.

Old Post 08-12-12 21:00 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
All times are GMT. The time now is 17:02. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Is any software rendering port using OpenCL?

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.