4
\$\begingroup\$

If there are 2 GPUs in a PC, one processing only graphics and the other dedicated to PhysX, what is the flow of the physics-related data?

Let's say we're simulating an explosion and the PhysX calculates exploded elements (position, size, number, whatnot) while graphics GPU renders them. Does CPU send input to PhysX GPU, gets the results and sends (some of) them to graphics GPU? Or is something like this possible: CPU sends input data to PhysX GPU and, after performing calculations, data from PhysX GPU goes straight to graphics GPU (omitting CPU altogether) since they're just used to render stuff anyway and CPU doesn't need to do anything with them?

Edit: Actually, as a bonus question, I'd like to know the same in case of just one GPU (used for both PhysX and graphics). Does the data flow to GPU, gets calculated, returns to CPU and then goes back to GPU for rendering or can it "stay" on GPU?

Improve this question
\$\endgroup\$

4 Answers 4

Reset to default
2
+100
\$\begingroup\$

It is worth noting that the render pipeline and the physics calculations are already logically separated in your application's code.

Render pipelines usually require specific data formats for the information needed to calculate a scene. The pipeline is, on top, highly customizable by using your shaders etc. .

When PhysX calculates its tasks on the gpu it DOES use the local memory but the rendering of the scene is usually logically separated clearly from physics calculations. Those are done asynchronously (with PhysX) and need to be done before starting to render a scene. So the results need to be collected at some point in time by some entity. As physx tasks are performed on both cpu and gpu and the central game logic and phsyx components run on the cpu, that "management task" can only be carried out there. The information needs to go back to the cpu, be repackaged into manageable formats and then sent to the rendering pipeline.

Maybe you can hack a graphics card to access memory that was used by a physx task before and get your data from there, but I don't know anything about that.

Improve this answer
\$\endgroup\$
3
\$\begingroup\$

Even if you have a dedicated PhysX card, some of the processing is still done on the CPU, as mentioned here.

This means that all data must be sent back to the cpu, and then forwarded on to the GPU. To clarify, the PhysX calculations are not done on the GPU, they are done on the PPU (Physics Processing Unit), which happens to be part of the physical Graphics Card you put in the machine.

You used to be able to buy dedicated PPU cards, however AMD and Intel decided it was better to do these calculations on the CPU, and Nvidia/Ageia decided it would be better on a dedicated card or on the GPU. If you want to read more about the PPU/PhysX Architecture this is a really good read.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ Thank you for the link. I was always thinking that NVidia's PPU is mostly the same GPU that is specialized (on hardware level) in utilizing some shaders that has little sense for rendering, but in general you can use any GPU on your graphics card for PhysX. \$\endgroup\$
    – Sergey.quixoticaxis.Ivanov
    Dec 15, 2016 at 11:22
0
\$\begingroup\$

Edit: Actually, as a bonus questions, I'd like to know the same in case of just one GPU (used for both PhysX and graphics). Does the data flow to CPU and back to GPU to can it "stay" on GPU?

Most certainly can the data remain on the GPU persistently. I don't use PhysX, instead calculate physics over HLSL shaders, so i cannot say exactly how PhysX does this. The principle should still be more or less the same. The GPU has "video memory" which is the 2,3,4, whatever GB printed on the card box. This is fast memory for the GPU, hence you can see all this nice grahics.

The big problem, as said in other replies, is the transportation of data from GPU to CPU memory. There are several issues related to this, and the retrieval of results from the GPU should be minimized in all ways, both size and density over time (= do not do anything unnecessary, ever).

If you however perform a calculation on the GPU, that has part persistent arguments and part such that change from frame to frame, you can well upload the persistent part once only. This must be possible with PhysX as well. You can also let one GPU calculation write it's results into video memory as argument for the next calculation. In both cases, it will survive from game frame to frame unless disturbed somehow.

Also to note, a hard reset will destroy whatever was written and stayed in video memory. This should happen if you change the graphics device resolution, for example resize a game that runs in windowed mode.

Timing is hugely important. The graphics pipeline is batched, meaning once you decide to render to screen, the GPU is fully occupied for some time. During that time, you should not attempt to read data from the GPU, instead focus on CPU work. That also means you will have some of the figures handy "late" in the game loop.

Improve this answer
\$\endgroup\$
5
  • \$\begingroup\$ I'm not sure you quite understood me - I meant the situation where some physics data are calculated by PhysX (e.g. positions of shards of an exploded object) and then used by GPU to render them on the screen. They change each frame but are calculated by GPU and then rendered by GPU. \$\endgroup\$
    – NPS
    Dec 15, 2016 at 8:18
  • \$\begingroup\$ PhysX was one of the first attempts to use shaders for not-meant-to-be-rendered-ever data :-) So I wouldn't be so certain about possibility of persistency. \$\endgroup\$
    – Sergey.quixoticaxis.Ivanov
    Dec 15, 2016 at 9:44
  • \$\begingroup\$ Nono, i believe i understand you well. Imagine you upload the object masses (max 512 objects) into a 1x512 surface (in video mem) once only, as they are persistent. Plus some other data needed for the phys calc. Then, using these, do a calc-render to a result fp32 surface (still in video mem). Finally, the screen render (vertex shader) does a lookup into the result surface, to get the new object positions. During the next loop cycle/physcalc, this result surface holds the current positions, to be looked up by a new phys calc and updated. Etc. But it's not fully that simple, so CPU needed too. \$\endgroup\$
    – Stormwind
    Dec 15, 2016 at 11:58
  • \$\begingroup\$ And to note, as one cannot write to the same surface one reads from, one uses two surfaces and bounces the data between them. I'd guess PhysX must do the same. This is a way to have the data remain/accumulate in fast video memory. ThisSurface = fn(OtherSurface). Then next cycle goes in opposite direction. The "other surface" always holds the accumulation of positions or whatever. \$\endgroup\$
    – Stormwind
    Dec 15, 2016 at 12:04
  • \$\begingroup\$ Then, at any point, you can read the surface pixel data into CPU, only if you have to. THAT is the expensive part, looping pixel by pixel. You can also update argument surfaces from CPU. Sometimes this mandatory. PhysX must be using combinations of all this, as i do too. \$\endgroup\$
    – Stormwind
    Dec 15, 2016 at 12:13
0
\$\begingroup\$

As far as I know, the data is transfered back to RAM even when you use one card for both rendering and PhysX.

I never worked with GPU in production environments but as far as I remember back from my university years PhysX utilizes it's own "pipeline" not completely compatable at high level with normal GPU usage.

I can be wrong though.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .