Jump to content
  • Advertisement
Sign in to follow this  
WireZappIndieStudios

SLI GPGPU Question

This topic is 2518 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So, I recently found out that it is possible to render shadow maps using WARP devices, on an independent CPU thread. This brought up some questions

Is it possible, if the user has 2 Graphic Cards, to use one for GPGPU (ie: calculating shadow maps, and rotating spherical harmonics), while the other one does the primary rendering? If so, can someone provide me with a code example, or at least pseudo code?

Share this post


Link to post
Share on other sites
Advertisement
Using a 2nd card explicitly (as opposed to the SLI/Crossfire way) is done by creating a 2nd device in the exact same way as using WARP, but declaring the adapter directly. Once done, you can use the device however you would normally. Note that Shaders, Vertex Buffers etc are all created on the Device level, and so would need to be created for both devices.

Resources can be shared between 2 devices, but at this time its restricted to (IIRC) 2D RGBA8 render targets without mipmaps. Syncing between the 2 devices, is not a trivial issue though, as you really don't want to block either GPU or the CPU, and its hard to enforce timing across the board without doing so.

Share this post


Link to post
Share on other sites
Thanks for the reply, just a few more questions.

1) What if the cards have different GPUs? (ie: A GTX 590, and a GTX 460) Can I use the smaller spec card for computation?

2) Do both devices have to be controlled by the main thread? Or can I use them on the thread which they were created on?

3) How do I check for multiple GPUs? Is this built into DirectX, or do I have to check the registry, and if so, what key?

4) Can I use one for CUDA, while the other one uses DirectX, and interpolate between the two cards?

Finally, 5) If the primary card doesn't meet the graphical requirements of my game engine, can I do the rendering on the other one, and display it through the primary card?

Sorry for the barrage of questions, it's just that I never really looked at integrating SLI/Crossfire into my engine, until this point

Share this post


Link to post
Share on other sites
1 & 2) When using the 2 cards as distinctly different video cards, then you aren't restricted in their use.
So, yeah you can use different cards and different threads.
However, 5) is the case where you would really want to use SLI/Crossfire and that does require very-similar if not the exact same video card.

3) You want to enumerate the device adapters, http://msdn.microsoft.com/en-us/library/windows/desktop/ff476877%28v=vs.85%29.aspx

4) If by interpolate you mean share data between, then yes but you may need to route data via the CPU which can be painfully slow. I've not looked into CUDA myself very much though.

SLI/Crossfire is largely automatic as long as your game does things in the right way, along with themselves having a few different configurations to support different means of rendering. Plenty of whitepapers from both nVidia and ATi/AMD on the matter.

Share this post


Link to post
Share on other sites
So, I read some of their white papers, but what I don't understand is that why one card renders one frame, and then the other card renders the next. Doesn't that mean that there is always one card idle, alternating between frames? And can I use that to speed along computation?

Share this post


Link to post
Share on other sites

So, I read some of their white papers, but what I don't understand is that why one card renders one frame, and then the other card renders the next. Doesn't that mean that there is always one card idle, alternating between frames? And can I use that to speed along computation?


What would be the purpose of having multiple GPU's if any of them was idle and waiting for next frame to be rendered.

Consider when the CPU has submitted all the work of a frame for the first GPU, the GPU hasn't probably finished drawing the frame yet. It is still processing a list of commands.
When there is a second GPU available, the CPU can continue the next frame immediately without waiting for GPU to finish the frame. After the second frame, the first GPU has (probably) become availableagain and the drawing can continue without interruption.

Cheers!

Share this post


Link to post
Share on other sites
Kauna is right on that mode. Note that this means that if you use a rendertarget from the previous frame on this frame, then you will always be stalling your GPUs and they will run one after the other.

I remember also reading of an alternate mode where each video card renders half the screen. Downside to this is if you try to fetch rendertarget memory thats being written by the opposing GPU, you will introduce stalls.

One fun thing to try with SLI, is doing your frame rendering on 1 video card, and then doing *all* of your post processing and HUD on the 2nd video card. So, while your 2nd card is processing the previous frame, your 1st video card is rendering out the current frame.

Share this post


Link to post
Share on other sites

Kauna is right on that mode. Note that this means that if you use a rendertarget from the previous frame on this frame, then you will always be stalling your GPUs and they will run one after the other.

I remember also reading of an alternate mode where each video card renders half the screen. Downside to this is if you try to fetch rendertarget memory thats being written by the opposing GPU, you will introduce stalls.

One fun thing to try with SLI, is doing your frame rendering on 1 video card, and then doing *all* of your post processing and HUD on the 2nd video card. So, while your 2nd card is processing the previous frame, your 1st video card is rendering out the current frame.


Doesn't this mean that there is a dependency between the GPUs and they need to synchronize the frame buffers which of course has a negative impact on the performance.

As far as I know, with the SLI/CrossFire, there shouldn't be any dependency between the current and the previous frame, otherwise the GPUs need to synchronize.

Cheers!

Share this post


Link to post
Share on other sites

Kauna is right on that mode. Note that this means that if you use a rendertarget from the previous frame on this frame, then you will always be stalling your GPUs and they will run one after the other.

I remember also reading of an alternate mode where each video card renders half the screen. Downside to this is if you try to fetch rendertarget memory thats being written by the opposing GPU, you will introduce stalls.

One fun thing to try with SLI, is doing your frame rendering on 1 video card, and then doing *all* of your post processing and HUD on the 2nd video card. So, while your 2nd card is processing the previous frame, your 1st video card is rendering out the current frame.


I am with Kauna on that, it seems as if there would be a very large amount if syncing.
What I am thinking about doing is having one card calculate all the direct lighting, and then using Wavelet Radiance Transport
(http://www-ljk.imag.fr/Publications/Basilic/com.lmc.publi.PUBLI_Inproceedings@1172c0fd434_ed088a/index.html)

The only issue is the fact that I need to have he previous frame so that it can be converted from Direct Illumination to Indirect Illumination, and then re-apply the indirect illumination. Any ideas how I can approach this?

Share this post


Link to post
Share on other sites

Doesn't this mean that there is a dependency between the GPUs and they need to synchronize the frame buffers which of course has a negative impact on the performance.

As far as I know, with the SLI/CrossFire, there shouldn't be any dependency between the current and the previous frame, otherwise the GPUs need to synchronize.

Cheers!

Yes, thats true. Though theres always a small dependancy between the two, and heavy restrictions on what can be transferred from one to the other without killing performance. Don't forget that SLI/Crossfire cards have a bridge connecting them - to my knowledge this is for direct memory transfer between the cards without passing through the motherboard. Theres also the ability to account for some latency between the two.

Its likely that cross card performance will get faster over the next few generations of cards due to their more-frequent use as general purpose units.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!