GTX465, SLOW Buffer Reading
  1 / 2    
Admittedly, being new to this site, I have been attempting to post this question in different places (including nvnews.net for their specific linux support) and as of yet have found no folks who understand (or care about) the problem. Let me also state that I am aware that Nvidia supports its gamer folks in the Windows world first and foremost given the market share.

We have used GTX cards in a research environment going back to the 8800 series. Our pre-fermi favorites were the 9800 and 280 cards. They could both render and dump very fast on PCIe slots. This is important in scene rendering environments where the scene data requires non-parallel data processing (downstream).

Recently, I purchased a GTX 465 with the hope of even better performance (at least on the render side). Indeed, the rendering was much faster than the 280. However, the buffer dump was much slower. Very dissapointing.

Now is a good time for me to add that I understand that these cards are aimed at the gamer market and maybe it never made much sense to be able to dump frame data off at such high rates as allowed by the PCIe protocol. And since the Quadros exist for workstations, maybe the idea is to move users like me to the (sadly) more expensive quadro (or even the MORE expensive Teslas). Don't get me wrong, I'd love to have a Tesla C2050 with the DVI output! But funds are limited for now.

[b]So, my question is this: Is the slow down in frame dump speed a driver issue or a hardware issue? If it is a driver issue, will it ever get fixed? If it is a hardware issue, is it fair to advertize PCIe 16x speed capability?[/b]

Thanks!

Mike

Edit: My OS environment is Linux (CentOS 4.7, 64 bit). My computer has two AMD cpus, dual core. 16 Gb ram.
Admittedly, being new to this site, I have been attempting to post this question in different places (including nvnews.net for their specific linux support) and as of yet have found no folks who understand (or care about) the problem. Let me also state that I am aware that Nvidia supports its gamer folks in the Windows world first and foremost given the market share.



We have used GTX cards in a research environment going back to the 8800 series. Our pre-fermi favorites were the 9800 and 280 cards. They could both render and dump very fast on PCIe slots. This is important in scene rendering environments where the scene data requires non-parallel data processing (downstream).



Recently, I purchased a GTX 465 with the hope of even better performance (at least on the render side). Indeed, the rendering was much faster than the 280. However, the buffer dump was much slower. Very dissapointing.



Now is a good time for me to add that I understand that these cards are aimed at the gamer market and maybe it never made much sense to be able to dump frame data off at such high rates as allowed by the PCIe protocol. And since the Quadros exist for workstations, maybe the idea is to move users like me to the (sadly) more expensive quadro (or even the MORE expensive Teslas). Don't get me wrong, I'd love to have a Tesla C2050 with the DVI output! But funds are limited for now.



So, my question is this: Is the slow down in frame dump speed a driver issue or a hardware issue? If it is a driver issue, will it ever get fixed? If it is a hardware issue, is it fair to advertize PCIe 16x speed capability?



Thanks!



Mike



Edit: My OS environment is Linux (CentOS 4.7, 64 bit). My computer has two AMD cpus, dual core. 16 Gb ram.

#1
Posted 09/27/2010 02:07 PM   
Admittedly, being new to this site, I have been attempting to post this question in different places (including nvnews.net for their specific linux support) and as of yet have found no folks who understand (or care about) the problem. Let me also state that I am aware that Nvidia supports its gamer folks in the Windows world first and foremost given the market share.

We have used GTX cards in a research environment going back to the 8800 series. Our pre-fermi favorites were the 9800 and 280 cards. They could both render and dump very fast on PCIe slots. This is important in scene rendering environments where the scene data requires non-parallel data processing (downstream).

Recently, I purchased a GTX 465 with the hope of even better performance (at least on the render side). Indeed, the rendering was much faster than the 280. However, the buffer dump was much slower. Very dissapointing.

Now is a good time for me to add that I understand that these cards are aimed at the gamer market and maybe it never made much sense to be able to dump frame data off at such high rates as allowed by the PCIe protocol. And since the Quadros exist for workstations, maybe the idea is to move users like me to the (sadly) more expensive quadro (or even the MORE expensive Teslas). Don't get me wrong, I'd love to have a Tesla C2050 with the DVI output! But funds are limited for now.

[b]So, my question is this: Is the slow down in frame dump speed a driver issue or a hardware issue? If it is a driver issue, will it ever get fixed? If it is a hardware issue, is it fair to advertize PCIe 16x speed capability?[/b]

Thanks!

Mike

Edit: My OS environment is Linux (CentOS 4.7, 64 bit). My computer has two AMD cpus, dual core. 16 Gb ram.
Admittedly, being new to this site, I have been attempting to post this question in different places (including nvnews.net for their specific linux support) and as of yet have found no folks who understand (or care about) the problem. Let me also state that I am aware that Nvidia supports its gamer folks in the Windows world first and foremost given the market share.



We have used GTX cards in a research environment going back to the 8800 series. Our pre-fermi favorites were the 9800 and 280 cards. They could both render and dump very fast on PCIe slots. This is important in scene rendering environments where the scene data requires non-parallel data processing (downstream).



Recently, I purchased a GTX 465 with the hope of even better performance (at least on the render side). Indeed, the rendering was much faster than the 280. However, the buffer dump was much slower. Very dissapointing.



Now is a good time for me to add that I understand that these cards are aimed at the gamer market and maybe it never made much sense to be able to dump frame data off at such high rates as allowed by the PCIe protocol. And since the Quadros exist for workstations, maybe the idea is to move users like me to the (sadly) more expensive quadro (or even the MORE expensive Teslas). Don't get me wrong, I'd love to have a Tesla C2050 with the DVI output! But funds are limited for now.



So, my question is this: Is the slow down in frame dump speed a driver issue or a hardware issue? If it is a driver issue, will it ever get fixed? If it is a hardware issue, is it fair to advertize PCIe 16x speed capability?



Thanks!



Mike



Edit: My OS environment is Linux (CentOS 4.7, 64 bit). My computer has two AMD cpus, dual core. 16 Gb ram.

#2
Posted 09/27/2010 02:07 PM   
Admittedly, being new to this site, I have been attempting to post this question in different places (including nvnews.net for their specific linux support) and as of yet have found no folks who understand (or care about) the problem. Let me also state that I am aware that Nvidia supports its gamer folks in the Windows world first and foremost given the market share.

We have used GTX cards in a research environment going back to the 8800 series. Our pre-fermi favorites were the 9800 and 280 cards. They could both render and dump very fast on PCIe slots. This is important in scene rendering environments where the scene data requires non-parallel data processing (downstream).

Recently, I purchased a GTX 465 with the hope of even better performance (at least on the render side). Indeed, the rendering was much faster than the 280. However, the buffer dump was much slower. Very dissapointing.

Now is a good time for me to add that I understand that these cards are aimed at the gamer market and maybe it never made much sense to be able to dump frame data off at such high rates as allowed by the PCIe protocol. And since the Quadros exist for workstations, maybe the idea is to move users like me to the (sadly) more expensive quadro (or even the MORE expensive Teslas). Don't get me wrong, I'd love to have a Tesla C2050 with the DVI output! But funds are limited for now.

[b]So, my question is this: Is the slow down in frame dump speed a driver issue or a hardware issue? If it is a driver issue, will it ever get fixed? If it is a hardware issue, is it fair to advertize PCIe 16x speed capability?[/b]

Thanks!

Mike

Edit: My OS environment is Linux (CentOS 4.7, 64 bit). My computer has two AMD cpus, dual core. 16 Gb ram.
Admittedly, being new to this site, I have been attempting to post this question in different places (including nvnews.net for their specific linux support) and as of yet have found no folks who understand (or care about) the problem. Let me also state that I am aware that Nvidia supports its gamer folks in the Windows world first and foremost given the market share.



We have used GTX cards in a research environment going back to the 8800 series. Our pre-fermi favorites were the 9800 and 280 cards. They could both render and dump very fast on PCIe slots. This is important in scene rendering environments where the scene data requires non-parallel data processing (downstream).



Recently, I purchased a GTX 465 with the hope of even better performance (at least on the render side). Indeed, the rendering was much faster than the 280. However, the buffer dump was much slower. Very dissapointing.



Now is a good time for me to add that I understand that these cards are aimed at the gamer market and maybe it never made much sense to be able to dump frame data off at such high rates as allowed by the PCIe protocol. And since the Quadros exist for workstations, maybe the idea is to move users like me to the (sadly) more expensive quadro (or even the MORE expensive Teslas). Don't get me wrong, I'd love to have a Tesla C2050 with the DVI output! But funds are limited for now.



So, my question is this: Is the slow down in frame dump speed a driver issue or a hardware issue? If it is a driver issue, will it ever get fixed? If it is a hardware issue, is it fair to advertize PCIe 16x speed capability?



Thanks!



Mike



Edit: My OS environment is Linux (CentOS 4.7, 64 bit). My computer has two AMD cpus, dual core. 16 Gb ram.

#3
Posted 09/27/2010 02:07 PM   
Hmm, I find this interesting since perhaps slow buffer transfer speeds may explain the performance/stuttering problems some people seem to be having with Fermi cards. It may even be related to the DPC latency issue. Can you provide actual numbers to compare between the 8800, 280, and 465 cards so that we can have an idea just how much slower the 465 seems to be compared to the older cards? If possible, is there any way to get these numbers under Windows? I think very few people in this forum use Linux, so if there's a way to measure it under Windows then a lot more people on here can check on their own cards and post results here for comparison. Does the Performance tab of the CUDA-Z utility show this problem? The Performance tab in CUDA-Z has real-time benchmark on Memory Copy speed (Host to Device, Device to Host, and Device to Device). What's even nicer for you is that CUDA-Z is also available for Linux so you can test this out yourself and compare. You can download CUDA-Z from here: [url="http://cuda-z.sourceforge.net/"]http://cuda-z.sourceforge.net/[/url]

I suppose I'll start with posting my CUDA-Z performance results. I'm using an MSI Cyclone GTX 460 1GB OC. I'm attaching 2 results from CUDA-Z from 2 different versions. The first one is from stable version 0.5.95, and the second one is from beta version 0.6.133. The results are pretty much identical using both versions, btw.

The following links show performance for GTX 285 taken from the CUDA-Z website:
[url="http://cuda-z.sourceforge.net/img/scr/CUDA-Z-0.5.95-win32-p3.jpg"]http://cuda-z.sourceforge.net/img/scr/CUDA...95-win32-p3.jpg[/url]
[url="http://cuda-z.sourceforge.net/img/scr/CUDA-Z-0.5.95-linux-p3.jpg"]http://cuda-z.sourceforge.net/img/scr/CUDA...95-linux-p3.jpg[/url]

My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.
Hmm, I find this interesting since perhaps slow buffer transfer speeds may explain the performance/stuttering problems some people seem to be having with Fermi cards. It may even be related to the DPC latency issue. Can you provide actual numbers to compare between the 8800, 280, and 465 cards so that we can have an idea just how much slower the 465 seems to be compared to the older cards? If possible, is there any way to get these numbers under Windows? I think very few people in this forum use Linux, so if there's a way to measure it under Windows then a lot more people on here can check on their own cards and post results here for comparison. Does the Performance tab of the CUDA-Z utility show this problem? The Performance tab in CUDA-Z has real-time benchmark on Memory Copy speed (Host to Device, Device to Host, and Device to Device). What's even nicer for you is that CUDA-Z is also available for Linux so you can test this out yourself and compare. You can download CUDA-Z from here: http://cuda-z.sourceforge.net/



I suppose I'll start with posting my CUDA-Z performance results. I'm using an MSI Cyclone GTX 460 1GB OC. I'm attaching 2 results from CUDA-Z from 2 different versions. The first one is from stable version 0.5.95, and the second one is from beta version 0.6.133. The results are pretty much identical using both versions, btw.



The following links show performance for GTX 285 taken from the CUDA-Z website:

http://cuda-z.sourceforge.net/img/scr/CUDA...95-win32-p3.jpg

http://cuda-z.sourceforge.net/img/scr/CUDA...95-linux-p3.jpg



My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.

CPU: Intel Core i5-2550K @4.4GHz
Mainboard: MSI Z77A-GD43 (Intel Z77 chipset)
Graphics: MSI N660Ti PE 2GD5/OC (GeForce GTX 660 Ti @1019MHz)
RAM: 2 x 4GB Visipro PC3-12800 (1.5V @933MHz)
OS: Windows 7 Ultimate 64-bit Service Pack 1
PSU: Seasonic Eco 600W SS-600BT Active PFC T3
Monitor: Asus VX239H (23" Full HD AH-IPS LED Display)

#4
Posted 09/27/2010 03:49 PM   
Hmm, I find this interesting since perhaps slow buffer transfer speeds may explain the performance/stuttering problems some people seem to be having with Fermi cards. It may even be related to the DPC latency issue. Can you provide actual numbers to compare between the 8800, 280, and 465 cards so that we can have an idea just how much slower the 465 seems to be compared to the older cards? If possible, is there any way to get these numbers under Windows? I think very few people in this forum use Linux, so if there's a way to measure it under Windows then a lot more people on here can check on their own cards and post results here for comparison. Does the Performance tab of the CUDA-Z utility show this problem? The Performance tab in CUDA-Z has real-time benchmark on Memory Copy speed (Host to Device, Device to Host, and Device to Device). What's even nicer for you is that CUDA-Z is also available for Linux so you can test this out yourself and compare. You can download CUDA-Z from here: [url="http://cuda-z.sourceforge.net/"]http://cuda-z.sourceforge.net/[/url]

I suppose I'll start with posting my CUDA-Z performance results. I'm using an MSI Cyclone GTX 460 1GB OC. I'm attaching 2 results from CUDA-Z from 2 different versions. The first one is from stable version 0.5.95, and the second one is from beta version 0.6.133. The results are pretty much identical using both versions, btw.

The following links show performance for GTX 285 taken from the CUDA-Z website:
[url="http://cuda-z.sourceforge.net/img/scr/CUDA-Z-0.5.95-win32-p3.jpg"]http://cuda-z.sourceforge.net/img/scr/CUDA...95-win32-p3.jpg[/url]
[url="http://cuda-z.sourceforge.net/img/scr/CUDA-Z-0.5.95-linux-p3.jpg"]http://cuda-z.sourceforge.net/img/scr/CUDA...95-linux-p3.jpg[/url]

My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.
Hmm, I find this interesting since perhaps slow buffer transfer speeds may explain the performance/stuttering problems some people seem to be having with Fermi cards. It may even be related to the DPC latency issue. Can you provide actual numbers to compare between the 8800, 280, and 465 cards so that we can have an idea just how much slower the 465 seems to be compared to the older cards? If possible, is there any way to get these numbers under Windows? I think very few people in this forum use Linux, so if there's a way to measure it under Windows then a lot more people on here can check on their own cards and post results here for comparison. Does the Performance tab of the CUDA-Z utility show this problem? The Performance tab in CUDA-Z has real-time benchmark on Memory Copy speed (Host to Device, Device to Host, and Device to Device). What's even nicer for you is that CUDA-Z is also available for Linux so you can test this out yourself and compare. You can download CUDA-Z from here: http://cuda-z.sourceforge.net/



I suppose I'll start with posting my CUDA-Z performance results. I'm using an MSI Cyclone GTX 460 1GB OC. I'm attaching 2 results from CUDA-Z from 2 different versions. The first one is from stable version 0.5.95, and the second one is from beta version 0.6.133. The results are pretty much identical using both versions, btw.



The following links show performance for GTX 285 taken from the CUDA-Z website:

http://cuda-z.sourceforge.net/img/scr/CUDA...95-win32-p3.jpg

http://cuda-z.sourceforge.net/img/scr/CUDA...95-linux-p3.jpg



My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.

CPU: Intel Core i5-2550K @4.4GHz
Mainboard: MSI Z77A-GD43 (Intel Z77 chipset)
Graphics: MSI N660Ti PE 2GD5/OC (GeForce GTX 660 Ti @1019MHz)
RAM: 2 x 4GB Visipro PC3-12800 (1.5V @933MHz)
OS: Windows 7 Ultimate 64-bit Service Pack 1
PSU: Seasonic Eco 600W SS-600BT Active PFC T3
Monitor: Asus VX239H (23" Full HD AH-IPS LED Display)

#5
Posted 09/27/2010 03:49 PM   
Hmm, I find this interesting since perhaps slow buffer transfer speeds may explain the performance/stuttering problems some people seem to be having with Fermi cards. It may even be related to the DPC latency issue. Can you provide actual numbers to compare between the 8800, 280, and 465 cards so that we can have an idea just how much slower the 465 seems to be compared to the older cards? If possible, is there any way to get these numbers under Windows? I think very few people in this forum use Linux, so if there's a way to measure it under Windows then a lot more people on here can check on their own cards and post results here for comparison. Does the Performance tab of the CUDA-Z utility show this problem? The Performance tab in CUDA-Z has real-time benchmark on Memory Copy speed (Host to Device, Device to Host, and Device to Device). What's even nicer for you is that CUDA-Z is also available for Linux so you can test this out yourself and compare. You can download CUDA-Z from here: [url="http://cuda-z.sourceforge.net/"]http://cuda-z.sourceforge.net/[/url]

I suppose I'll start with posting my CUDA-Z performance results. I'm using an MSI Cyclone GTX 460 1GB OC. I'm attaching 2 results from CUDA-Z from 2 different versions. The first one is from stable version 0.5.95, and the second one is from beta version 0.6.133. The results are pretty much identical using both versions, btw.

The following links show performance for GTX 285 taken from the CUDA-Z website:
[url="http://cuda-z.sourceforge.net/img/scr/CUDA-Z-0.5.95-win32-p3.jpg"]http://cuda-z.sourceforge.net/img/scr/CUDA...95-win32-p3.jpg[/url]
[url="http://cuda-z.sourceforge.net/img/scr/CUDA-Z-0.5.95-linux-p3.jpg"]http://cuda-z.sourceforge.net/img/scr/CUDA...95-linux-p3.jpg[/url]

My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.
Hmm, I find this interesting since perhaps slow buffer transfer speeds may explain the performance/stuttering problems some people seem to be having with Fermi cards. It may even be related to the DPC latency issue. Can you provide actual numbers to compare between the 8800, 280, and 465 cards so that we can have an idea just how much slower the 465 seems to be compared to the older cards? If possible, is there any way to get these numbers under Windows? I think very few people in this forum use Linux, so if there's a way to measure it under Windows then a lot more people on here can check on their own cards and post results here for comparison. Does the Performance tab of the CUDA-Z utility show this problem? The Performance tab in CUDA-Z has real-time benchmark on Memory Copy speed (Host to Device, Device to Host, and Device to Device). What's even nicer for you is that CUDA-Z is also available for Linux so you can test this out yourself and compare. You can download CUDA-Z from here: http://cuda-z.sourceforge.net/



I suppose I'll start with posting my CUDA-Z performance results. I'm using an MSI Cyclone GTX 460 1GB OC. I'm attaching 2 results from CUDA-Z from 2 different versions. The first one is from stable version 0.5.95, and the second one is from beta version 0.6.133. The results are pretty much identical using both versions, btw.



The following links show performance for GTX 285 taken from the CUDA-Z website:

http://cuda-z.sourceforge.net/img/scr/CUDA...95-win32-p3.jpg

http://cuda-z.sourceforge.net/img/scr/CUDA...95-linux-p3.jpg



My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.

CPU: Intel Core i5-2550K @4.4GHz
Mainboard: MSI Z77A-GD43 (Intel Z77 chipset)
Graphics: MSI N660Ti PE 2GD5/OC (GeForce GTX 660 Ti @1019MHz)
RAM: 2 x 4GB Visipro PC3-12800 (1.5V @933MHz)
OS: Windows 7 Ultimate 64-bit Service Pack 1
PSU: Seasonic Eco 600W SS-600BT Active PFC T3
Monitor: Asus VX239H (23" Full HD AH-IPS LED Display)

#6
Posted 09/27/2010 03:49 PM   
Finally! Thank you!

OK, you threw a lot at me, and it may take me a bit to do some of it... especially the part regarding Windows. Our software will not work in Windows, not even Cygwin. However, if there is some kind of benchmark that I can run in Windows as well as Linux, I will do it (I am assuming Cuda Z might be the ticket). I might get to tackle this tonight. I bet I can tackle the Linux/CUDA Z thing after lucnch...

Mike
Finally! Thank you!



OK, you threw a lot at me, and it may take me a bit to do some of it... especially the part regarding Windows. Our software will not work in Windows, not even Cygwin. However, if there is some kind of benchmark that I can run in Windows as well as Linux, I will do it (I am assuming Cuda Z might be the ticket). I might get to tackle this tonight. I bet I can tackle the Linux/CUDA Z thing after lucnch...



Mike

#7
Posted 09/27/2010 04:23 PM   
Finally! Thank you!

OK, you threw a lot at me, and it may take me a bit to do some of it... especially the part regarding Windows. Our software will not work in Windows, not even Cygwin. However, if there is some kind of benchmark that I can run in Windows as well as Linux, I will do it (I am assuming Cuda Z might be the ticket). I might get to tackle this tonight. I bet I can tackle the Linux/CUDA Z thing after lucnch...

Mike
Finally! Thank you!



OK, you threw a lot at me, and it may take me a bit to do some of it... especially the part regarding Windows. Our software will not work in Windows, not even Cygwin. However, if there is some kind of benchmark that I can run in Windows as well as Linux, I will do it (I am assuming Cuda Z might be the ticket). I might get to tackle this tonight. I bet I can tackle the Linux/CUDA Z thing after lucnch...



Mike

#8
Posted 09/27/2010 04:23 PM   
Finally! Thank you!

OK, you threw a lot at me, and it may take me a bit to do some of it... especially the part regarding Windows. Our software will not work in Windows, not even Cygwin. However, if there is some kind of benchmark that I can run in Windows as well as Linux, I will do it (I am assuming Cuda Z might be the ticket). I might get to tackle this tonight. I bet I can tackle the Linux/CUDA Z thing after lucnch...

Mike
Finally! Thank you!



OK, you threw a lot at me, and it may take me a bit to do some of it... especially the part regarding Windows. Our software will not work in Windows, not even Cygwin. However, if there is some kind of benchmark that I can run in Windows as well as Linux, I will do it (I am assuming Cuda Z might be the ticket). I might get to tackle this tonight. I bet I can tackle the Linux/CUDA Z thing after lucnch...



Mike

#9
Posted 09/27/2010 04:23 PM   
[i]My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed. [/i]

Does Device mean "graphics card" and does host mean "computer"? And by device to device are you talking about SLI?

Just need a little help with terminology... I am by no means a GPU expert... just a user.

Mike
My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.



Does Device mean "graphics card" and does host mean "computer"? And by device to device are you talking about SLI?



Just need a little help with terminology... I am by no means a GPU expert... just a user.



Mike

#10
Posted 09/27/2010 04:26 PM   
[i]My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed. [/i]

Does Device mean "graphics card" and does host mean "computer"? And by device to device are you talking about SLI?

Just need a little help with terminology... I am by no means a GPU expert... just a user.

Mike
My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.



Does Device mean "graphics card" and does host mean "computer"? And by device to device are you talking about SLI?



Just need a little help with terminology... I am by no means a GPU expert... just a user.



Mike

#11
Posted 09/27/2010 04:26 PM   
[i]My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed. [/i]

Does Device mean "graphics card" and does host mean "computer"? And by device to device are you talking about SLI?

Just need a little help with terminology... I am by no means a GPU expert... just a user.

Mike
My GTX 460 has faster Device to Host and Host to Device transfer speeds, but the GTX 285 has faster Device to Device transfer speed.



Does Device mean "graphics card" and does host mean "computer"? And by device to device are you talking about SLI?



Just need a little help with terminology... I am by no means a GPU expert... just a user.



Mike

#12
Posted 09/27/2010 04:26 PM   
I'm pretty sure Device means the graphics card (or more specifically the video memory), and Host either means the CPU or the system memory. I'm also pretty sure that Device to Device means copying from one location in video memory to another location in video memory on the same card. I don't have SLI though, and I don't know if the Device to Device numbers indicate transfer speeds between different cards if there's an SLI setup.

Anyway, Device to Host and Host to Device transfers should go through the PCI-E bus, whereas Device to Device is done through the internal bus on the graphics card/GPU. For your case, I guess the Device to Host and Host to Device transfer speeds are the numbers we should be looking at. :)
I'm pretty sure Device means the graphics card (or more specifically the video memory), and Host either means the CPU or the system memory. I'm also pretty sure that Device to Device means copying from one location in video memory to another location in video memory on the same card. I don't have SLI though, and I don't know if the Device to Device numbers indicate transfer speeds between different cards if there's an SLI setup.



Anyway, Device to Host and Host to Device transfers should go through the PCI-E bus, whereas Device to Device is done through the internal bus on the graphics card/GPU. For your case, I guess the Device to Host and Host to Device transfer speeds are the numbers we should be looking at. :)

CPU: Intel Core i5-2550K @4.4GHz
Mainboard: MSI Z77A-GD43 (Intel Z77 chipset)
Graphics: MSI N660Ti PE 2GD5/OC (GeForce GTX 660 Ti @1019MHz)
RAM: 2 x 4GB Visipro PC3-12800 (1.5V @933MHz)
OS: Windows 7 Ultimate 64-bit Service Pack 1
PSU: Seasonic Eco 600W SS-600BT Active PFC T3
Monitor: Asus VX239H (23" Full HD AH-IPS LED Display)

#13
Posted 09/27/2010 04:50 PM   
I'm pretty sure Device means the graphics card (or more specifically the video memory), and Host either means the CPU or the system memory. I'm also pretty sure that Device to Device means copying from one location in video memory to another location in video memory on the same card. I don't have SLI though, and I don't know if the Device to Device numbers indicate transfer speeds between different cards if there's an SLI setup.

Anyway, Device to Host and Host to Device transfers should go through the PCI-E bus, whereas Device to Device is done through the internal bus on the graphics card/GPU. For your case, I guess the Device to Host and Host to Device transfer speeds are the numbers we should be looking at. :)
I'm pretty sure Device means the graphics card (or more specifically the video memory), and Host either means the CPU or the system memory. I'm also pretty sure that Device to Device means copying from one location in video memory to another location in video memory on the same card. I don't have SLI though, and I don't know if the Device to Device numbers indicate transfer speeds between different cards if there's an SLI setup.



Anyway, Device to Host and Host to Device transfers should go through the PCI-E bus, whereas Device to Device is done through the internal bus on the graphics card/GPU. For your case, I guess the Device to Host and Host to Device transfer speeds are the numbers we should be looking at. :)

CPU: Intel Core i5-2550K @4.4GHz
Mainboard: MSI Z77A-GD43 (Intel Z77 chipset)
Graphics: MSI N660Ti PE 2GD5/OC (GeForce GTX 660 Ti @1019MHz)
RAM: 2 x 4GB Visipro PC3-12800 (1.5V @933MHz)
OS: Windows 7 Ultimate 64-bit Service Pack 1
PSU: Seasonic Eco 600W SS-600BT Active PFC T3
Monitor: Asus VX239H (23" Full HD AH-IPS LED Display)

#14
Posted 09/27/2010 04:50 PM   
I'm pretty sure Device means the graphics card (or more specifically the video memory), and Host either means the CPU or the system memory. I'm also pretty sure that Device to Device means copying from one location in video memory to another location in video memory on the same card. I don't have SLI though, and I don't know if the Device to Device numbers indicate transfer speeds between different cards if there's an SLI setup.

Anyway, Device to Host and Host to Device transfers should go through the PCI-E bus, whereas Device to Device is done through the internal bus on the graphics card/GPU. For your case, I guess the Device to Host and Host to Device transfer speeds are the numbers we should be looking at. :)
I'm pretty sure Device means the graphics card (or more specifically the video memory), and Host either means the CPU or the system memory. I'm also pretty sure that Device to Device means copying from one location in video memory to another location in video memory on the same card. I don't have SLI though, and I don't know if the Device to Device numbers indicate transfer speeds between different cards if there's an SLI setup.



Anyway, Device to Host and Host to Device transfers should go through the PCI-E bus, whereas Device to Device is done through the internal bus on the graphics card/GPU. For your case, I guess the Device to Host and Host to Device transfer speeds are the numbers we should be looking at. :)

CPU: Intel Core i5-2550K @4.4GHz
Mainboard: MSI Z77A-GD43 (Intel Z77 chipset)
Graphics: MSI N660Ti PE 2GD5/OC (GeForce GTX 660 Ti @1019MHz)
RAM: 2 x 4GB Visipro PC3-12800 (1.5V @933MHz)
OS: Windows 7 Ultimate 64-bit Service Pack 1
PSU: Seasonic Eco 600W SS-600BT Active PFC T3
Monitor: Asus VX239H (23" Full HD AH-IPS LED Display)

#15
Posted 09/27/2010 04:50 PM   
  1 / 2    
Scroll To Top