source-sdk-2013
source-sdk-2013 copied to clipboard
ValveSoftware
[Request] OpenCL and/or CUDA support for VVIS and VRAD.
As the title would indicate, I wish to request that OpenCL or CUDA Support be added to the VVIS and VRAD Compiling tools. This would allow mappers to much more quickly and efficiently test their maps with full lighting and visibility data.
VRAD would probably benefit the most, as a GPU can handle simulating radiosity a hell of a lot faster than a CPU can. VVIS might as well, since a GPU can handle small amounts of information in parallel much more efficiently than a CPU.
To be able to cut compile times from 45 minutes to about 5 minutes or less would be a wonderful thing.
Also, the most important thing about this, is that it would be a good way to compensate for not having the now non-functional VMPI tool.
I can tell you right now that there's no way that Valve will be tackling this. But you are free to, as the code is available for you to modify.
Isn't the source code for that outdated? Also, Valve neglects their SDK in the first place, leaving as probably one of the most broken and messed-up pieces of software I've ever used. I think we deserve at least something from them to make up for it.
The VBSP, VVIS, VRAD source code in the SDK should correspond to the actual binaries. At least, my Linux port of these tools seem to work entirely as expected. If your map compile times are too long, you are likely doing something quite wrong and need to optimize your maps or get a faster computer. If you really want VVIS and VRAD to use OpenCL - Go ahead and add it yourself and send a pull request when it's ready.
As sortie said if your compile time is 45 minutes long for lighting and it's not for a final compile you need to optimize better. You could always just not do vrad as well if you want a super fast compile to just check entities.
That logic does not apply for a large and complex map. You can optimize map like that all you want, and it will still take ages to compile. Also, even 5 minutes at a time for a compile on a smaller, but still optimized map is still extremely inconvenient and slows progress. For those maps, supporting CUDA or OpenCL would make a compile almost instant, even for a full compile. (Considering most GPUs can handle ray-tracing in real-time now, or at least pretty damn close. Especially NVidia cards on the Kepler architecture.)
If you want to attempt to add it yourself you are more then welcome to, Valves been pretty clear that they are focusing more on fixing up rather then adding new features.
If I knew how to program in C++, I would. I spent years trying to learn it, but I lack that ability despite knowing several other languages. It's not laziness either, and you just can't expect everyone to magically know how to do it.
Anyhow, to be honest, in regards to the second statement, it's pretty damn clear that Valve isn't even focusing on fixing things either, let alone adding new features if the states of Faceposer(Broken in Vista/7, and crashes on moving phonemes no matter the OS.), Hammer(Unstable, crashes frequently, Compiling hangs hammer and the compile status window until finished when it shouldn't, etc.), Half-Life 2: Deathmatch(Do I even know where to begin on this?), or VMPI are any indication. Don't even get me started on the mass of issues in the SDK that have been known for almost 6 years now, piling up in the Valve Developer Wiki.
Not to mention that there's only 3 people monitoring this Github... I've seen small, obscure open source projects that are better managed, and have more people looking at bug reports and responding to them, fixing the issues themselves, etc.
Great Idea, use OpenCL for all GUPs compatibility, AMD, NVIDIA, INTEL. :+1:
http://docs.nvidia.com/cuda/cuda-c-programming-guide/ http://portablecl.org/docs/html/ Break a leg
