Cuda vs Vulkan compute

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: Cuda vs Vulkan compute

Postby Julio Jerez » Tue Sep 02, 2025 8:12 am

Imagine this.
Support you implement a cloth system.
After you do all the physics part, you are left with a collection of vertices, indices, materials.

Now you have to somehow convert that to graphic, and it is that part that makes it confusing and difficult.

If you have a graphic library, the the interface is more clear.
And a user can easy see how to reproduce the implementation on their side.
Julio Jerez
Moderator
Moderator
 
Posts: 12452
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Cuda vs Vulkan compute

Postby Julio Jerez » Tue Sep 02, 2025 9:40 am

When it comes to ray tracing, my main interest is that, in theory,
it provides a natural solution to the reflection problem, maybe even shadow.

I’ve always disliked how reflections are handled with rasterization.
You have to rely on multiple render-to-texture cube maps, and even then, the results often look fake and inaccurate.
With ray tracing, as I understand it, even just two or three bounce levels should produce reflections that look far more natural, and with a simpler implementation.

Of course, that’s more of a long-term idea. My second PC doesn’t even support hardware ray tracing, so it’s not something I can pursue right now.

To be clear, I’m not aiming to build a full rendering engine.
The goal is just to create a minimal support library for rendering scenes made up of basic primitives, something closer to what RenderWare’s core library was back in the ’90s.

It’ll be a very simple system, essentially a node-and-mesh scene setup without culling, just consolidating the rendering functionality that’s currently scattered in demo toolboxes into a dedicated library.

The alternative is to keep sprinkling #ifdef / #endif blocks everywhere, which I really dislike.
Julio Jerez
Moderator
Moderator
 
Posts: 12452
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Cuda vs Vulkan compute

Postby Julio Jerez » Tue Sep 02, 2025 12:50 pm

Joe, you said:
I would say VK isn't as worse as we think, once we get used to it and just do the work.
It could be much easier now as well, as they have added 'easy paths' not requiring renderpasses for example, afaik.


Personally, I’ve always thought render passes are a great way to organize a rendering library.
A lot of things seem to fall naturally into place with that approach. For example:

-It closely mirrors how a painter builds a scene on a canvas, starting with the background, then layering elements on top. Organizing a scene becomes as simple as sorting layers in a list.

-It adds flexibility for configuration. Some layers can be simple, while others can be advanced—for instance, handling reflections via ray tracing if the hardware supports it.

-It even allows for performance-oriented configurations.

That’s the approach I’ve been using, and I honestly don’t see any major downsides to render passes.
Is there a specific reason you’re not a fan of them?
Julio Jerez
Moderator
Moderator
 
Posts: 12452
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Cuda vs Vulkan compute

Postby JoeJ » Tue Sep 02, 2025 2:41 pm

Ah i see. So you indeed want some fun, and i won't try to stop you. :)
Yeah, raytraced reflections would be very cool.
But i don't expect it to be easy.
We get robust results, but then we have to work on denoising for image quality and practical performance.
Maybe that's an interesting problem, but i guess it's no longer 'fun' at this point.

However, i became a lot more optimistic about the future of RT.
You surely saw NVidias 'mega geometry' (or how they call it) dome in Unreal, which supports Nanite.
This is not just proprietary. They have released VK extensions, so we can do this too.
It's not the flexible access to BVH i have requested, but it is a solution to traceable LOD and looks pretty good to me.
Now i guess most Engines will adopt the Nanite idea, other PGU vendors will support the extension, and RT finally becomes 'useful'. \:D/

But if it's practical and affordable still remains a question.
Actually in Europe it clearly shows the PC platform is shrinking quickly since RTX gave us a GPU price hike for little benefit. RT really seems an enthusiast feature, and support on entry level GPUs didn't help much against that. :|

I still have no RT GPU myself. They need to try harder to gat my money. ; )
User avatar
JoeJ
 
Posts: 1494
Joined: Tue Dec 21, 2010 6:18 pm

Re: Cuda vs Vulkan compute

Postby JoeJ » Tue Sep 02, 2025 4:18 pm

-It closely mirrors how a painter builds a scene on a canvas, starting with the background, then layering elements on top. Organizing a scene becomes as simple as sorting layers in a list.


Oh, haha, that sounds you can make make sense out of Vulkan concepts.
Well, luck for you. I already and again have completely forgotten what renderpasses are. :lol:
I do not really 'learn' Vulkan i feel. But so far i could do all the things in the way i wanted to have them, and in the future i can look up my own code on demand, to figure out for the tenth time what a renderpass is. ;D

So i can't tell if i'm a fan of renderpasses right now, sorry. I only know i do use them.

But maybe more interesting, there is also a modern easy mode now to lower descriptor complexity, 'push discriptors' iirc. I saw this in the popular Mesh Optimizer library on github. And it it lowers overall complexity extremely. It's almost as simple as OpenGL.

But well, personally i'm too lazy to learn modern easy mode. It came too late for me.

But the one thing i do want to use is raw pointers instead storage buffer descriptors.
They say pointers are faster, and we can do pointer arithmetic, so one Vulkan concept less i need to understand.
I do even think this allows to do the impossible: Setting uniform buffer data from GPU, because they become just pointers too. Usually we can modify unifrom data and thus precious constant on chip ram only from CPU, limiting efficiency with GPU driven rendering.
User avatar
JoeJ
 
Posts: 1494
Joined: Tue Dec 21, 2010 6:18 pm

Re: Cuda vs Vulkan compute

Postby Julio Jerez » Fri Sep 05, 2025 11:20 am

Ok Joe,

I’ve put together the basic skeleton of the render library I’ve been envisioning.
Right now it’s just a bare-bones implementation: simple rendering plus the input/output callbacks wired up.

For testing, I’m running a minimal demo—just an environment map, a solid floor, and a box. It’s basically the “Hello World” of physics.

From here I could take a few different directions, but my next step will be to add a blank context and confirm it compiles and links on Windows. It won’t actually do anything yet, but it will help test builds across platforms—Linux, Windows (legacy), Android, macOS, and possibly iOS.

The idea is that, to get it running on each platform, either I (or anyone else) can implement the required classes. A Vulkan backend is also on the table.

People often assume Vulkan is the only real option for mobile, but I believe most devices still rely heavily on GLES.

Some time ago, I tried building the engine for Android but couldn’t compile any of the demos because they used OpenGL functions deprecated in GLES. I ended up writing a completely separate demo, which was frustrating. I don’t want to keep repeating that.

If you want to take a look, you can sync and build it now. I already have basic Blinn reflections working, and later I plan to add simple environment reflections to make the ground and objects look shiny.
I’ve learned the hard way that, for many people, presentation matters just as much as the library itself.

edit:
I just added the MacOs blank, and try to build.
hurray, it compiled and link:mrgreen: :mrgreen:
of course it does not run since there is no graphics, but that's an issue for another day.

It also builds and run the Linux virtual machine.

now I can add more th erest fo teh demos and basic functionality like picking.

Ove the weekend I will try to build in Android studio.
That should be relatively simple, since it is a subset of openGL,
just need to replace the error whet OpenGL and GLES are different. :D :D

I start to like this solution a lot better that dreadful #Ifdef/#endif :mrgreen:
Julio Jerez
Moderator
Moderator
 
Posts: 12452
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Cuda vs Vulkan compute

Postby JoeJ » Sun Sep 07, 2025 5:33 am

I was just thinking, it's actually not easy these days to get into gamedev without using an engine.
Beside things like SFML or rayLib there is not much around to give you some gfx to get started.
Consequently everybody is using engines, and gamedev is not longer development but just content generation, as i like to say.

This has to stop. All game i see are the same. They are boring. At this point i do not even try new games anymore. It's a waste of time. They all *. They say they make AAAAA games now, but i say no thanks.
It is so bad, i even have motivation issues for the first time in my life.

But maybe at least a tiny minority of people is still willing to learn gamedev from ground up, so they can come up with new things instead cloning former successes and adding one more A.
And if so, a physics engine with a simple renderer would be much more useful than Godot.
So if i were you, i would target this new generation of devs, which are the survivors of the upcoming video game crash. :twisted:

In this sense, there is one request / proposal i could make: Debug visualization. I have never seen a library for that.

This is what i see when working on the ragdoll:
Capture.JPG
Capture.JPG (105.11 KiB) Viewed 4235 times

I do visualizations all the time. It's some work but it really helps to understand and verify.
For rendering i support the following primitives:
Point(x), Line(x1,x2), Vector(x,v), Arrow(x,v,size), Circle(with given axis or aligning to camera), Cone

I can also print text at a given position, which is super helpful. (using ImGui)

And i have a plot which you see on top of the image, graphing curves where i add a data point each frame. For the ragdoll the plot is really essential, but i rarely used it elsewhere.

Then i have a window where i see my debug log, so i do not need to have a console window or look into a file.

To me those debugging tools are absolutely essential, and i use them for everything i do.
It's key that they are easily available from everywhere.
I saw you have a visualization method in your joint base class. That's good software architecture, but it's also too cumbersome for debugging. I do it differently: Just putting a Vis::RenderPoint() call into the code i'm currently working on. This generates debug clutter you need to remove later, but it's convenient. (ImGui also is an example of this kind of workflow - you can put ImGui calls everywhere and don't have to initialize something up front.)

Maybe you could provide such debugging tools as well. For me they are part of my application framework.
But that's really just an idea, not a request from my side.

Another thing i think would help is debug visualization of your collision geometry.
You provide related tools already and i use them. Your spherical triangles for round shapes look very nice.
But maybe you could make this easier so users need to call only one function for the whole scene.
Personally i can draw this either solid or wireframe, and each object gets a random color.
The colors help a lot compared to your monochrome collision display from the sandbox.

To me this collision geometry is all i want to see. I would develop most of my game with this kind of gfx. No need for distracting textures and lighting. I care about that only later when starting with content for the game. (But simple shadows can be helpful to visualize contact.)
Looking at detailed game models is not helpful for me, because there always is the paranoia of a mismatch with the collision shape.

On gamedev.net i often see progress on the Matali physics engine, which has a simple renderer. And recently even lights became part of that. 'Physically accurate lights' ofc., although i don't know what this claim is based on. But maybe this goes a bit in to the direction you have in mind, and you can take a look. Running the engine demo feels like playing a game. A real game, not those awkward inversed mouse camera controls rocket scientists like you use. :P If you care about presentation, this might matter the most.

(I'm at least a bit closer to a fast walking ragdoll...)
User avatar
JoeJ
 
Posts: 1494
Joined: Tue Dec 21, 2010 6:18 pm

Re: Cuda vs Vulkan compute

Postby Julio Jerez » Sun Sep 07, 2025 10:33 am

yeah, but that's not new.
Here is the little dirty secret. Game just as movies and product of art not a product of technology.
in general, a game is about 90 to 95% art and 0 to 10% technology.
but when it comes to cost and time it is the inverse, technology consumes lot of money and time.

Games are very expensive, and getting funding to hire people to work on it cost a lot.
with the exception of very few tech companies, the last thing investors in game what to do is spend money in research a development on game engine.
The one that do, are either self-funded, or a very trusted by published because they produced game that generated billions a priory.

I have never worked for a company that actually wanted to do tech dev.
Most studios are in general content generator.
And these days with huge engine like unreal and Unity, many studios operate as if they were movie studios.

the one big difference now is that is that some huge, and most sophisticated game engine are free.
that level the playing feels a little bit for indies developer.

anyway, since I am not making a game engine, that's not something I care too much.

I already have almost all the navigation functionality, that I has before.
I can now start adding the rest of the demos.
but before that I will add the environmental reflection, so that the scenes are shinny.
all the scenes are too doll and that make the look outdated.
Julio Jerez
Moderator
Moderator
 
Posts: 12452
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Cuda vs Vulkan compute

Postby Julio Jerez » Sun Sep 07, 2025 4:17 pm

I’ve now got basic environment-mapped reflections working, and the scene looks shiny, maybe a bit too shiny,
but that’s something I can tune through the material settings. Raster performance does dip with shadows and reflections, but so far it’s nothing concerning compared to the big aesthetic improvement.

The next fundamental step will be adding a render-to-texture pass.
That opens the door to effects like water ripples, object reflections on planes (billboards playing videos, rear-view mirrors, etc.). I’ll probably tackle that later, right now I need to re-enable some demos and add a debug pass.

Overall, not a bad result!
Julio Jerez
Moderator
Moderator
 
Posts: 12452
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Cuda vs Vulkan compute

Postby JoeJ » Sun Sep 07, 2025 8:44 pm

Here is the little dirty secret. Game just as movies and product of art not a product of technology.

You can not declare your product as art. Others have to do this, and no, games are not considered art outside of the games industry itself.
Now you may argue that games are made from hundreds of artists, so they are art.
But that's not the case. They create what they were advised to create, so they create content, but no true art.
Now you may argue that the person who advises them is the true artist then, like a good Hollywood movie director is.
But no. The movie director has to work with only a small circle of people. Some main actors and few other guys which have the most impact on the outcome. They can share a vision, and build up the needed chemistry.
But with hundreds of artists this can't work. Instead the designer talks to concept artists, which create the requested content, no art. They call it Cyberpunk, or Steampunk, or Xpunk or Ypunk. Although they never heard the Ramones or their message, and simply don't care what punk actually is.
Those non art concepts are handed to 3D artists which then create 3D models as requested, again removing a part of an initial vision which maybe came from heart like art, but now is just business and everyday work.

Growth did not only increased costs. It also prevented the option to become a form of art.
I'm sorry to tell you, but no. Your creative industry does not create art, exposing the fallacy in your argument.

If it would be art, then would would see what happened in the music industry.
There was Rock and Roll, but then there was Flower Power, Thrash Metal, Country, Punk, Techno. Tell me what you like and i tell you what you probably think about society or the world.

Can i tell anything if you tell me your favorite video game genre?
No, i can't. Because there is no association about various ideologies with games. Because games don't have any artistic message, since they are no art.

If games want to become art, they need their underground, so ideologies can form by separating from the mainstream. But so far the indie scene failed just as badly at delivering such a thing which could be eventually considered art.
So maybe it's not just the big business of huge AAA studios, but the medium, or the society itself, which fails to deliver art or inspiration in modern times?

I don't know. It's not our business anyway. We do something else. Games are made of code, not art. Code first. Always. And thus, by outsourcing code to Epic or Unity, or by focusing entirely on content, the games industry commits suicide, and indies as well. The new Video Game Crash is here, and admitting it is better than holding up golden Game Awards.

But luckily i know a way out. Character simulation of coarse. And with every step the ragdoll does, it becomes more obvious and certain. (just got a new walking speed record... 8) )
User avatar
JoeJ
 
Posts: 1494
Joined: Tue Dec 21, 2010 6:18 pm

Previous

Return to General Discussion

Who is online

Users browsing this forum: Google Adsense [Bot] and 105 guests

cron