Adam Gontier schrieb:
Ja Moin, einige von uns müssen tatsächlich arbeiten und bei dem Wetter nach der Arbeit auf schnellsten Wege in den Biergarten.
Ich dachte eigentlich die News erklärt sich von selbst.
Mit dem Visual Profiler ist es möglich,
die Performance bereits geschriebener CUDA-Programme zu verbessern
Darüber hinaus unterstützt CUDA 2.2 nun
Windows Server 2003 sowie Windows Server 2008, wenn die
Tesla-Karten C1060 oder S1070 verwendet werden.
Mit anderen Worten, CUDA wird eine noch höhere Watt/Perfomance erreichen als zb. CPU oder ATI Stream.
Die offiziellen Änderungen wie folgt:
http://forums.nvidia.com/index.php?showtopic=92416
A brief overview of CUDA 2.2 beta features:
1. Zero-copy support (see this thread for more information)
2. Asynchronous memcpy on Vista/Server 2008
3. exturing from pitchlinear memory
4. cuda-gdb for 64-bit Linux (it is pretty great)
5. OGL interop performance improvements
6. CUDA profiler supports a lot more counters on GT200. I think this includes memory bandwidth counters (counters for each transaction size) and instruction count. In other words, you can very easily determine if you're bandwidth limited or compute limited, which makes it far more useful than it used to be.
7. CUDA profiler works on Vista
8. >4GB of pinned memory in a single allocation (except in Vista, where the limit is still 256MB per allocation, but I think this is going to be raised between now and the final release)
9. Blocking sync for all platforms. Whether this made it into the headers for the beta, I'm not entirely sure--I've heard conflicting reports and need to check this afternoon. Basically, it's a context creation flag where instead of spinlocking or spinlocking+yielding when a thread is waiting for the GPU, the thread will sleep and the driver will wake it up when the event has completed. It's not the default mode because you're at the mercy of the OS thread scheduler which will sometimes increase latency, but if you want to minimize CPU utilization, it's very nice.
10. Officially supports Ubuntu 8.10, RHEL 5.3, Fedora 10
There's one last feature that didn't make it in the beta that I think is the best feature in 2.2 (even compared to the dramatically improved profiler, zero-copy and the 64-bit debugger), but I don't want to spoil it...
Tja dann hat er doch die Katze aus dem Sack gelassen bis zur finalen Version sollen dann außerdem:
11. Yeah. In 2.2 under Linux, you can use nvidia-smi to designate a GPU as supporting multiple contexts, a single context, or no contexts. You can query this in CUDART, plus we give you some convenience features to make this easy. So, you have multiple GPUs and multiple MPI processes that need GPUs--no problem. Set all your GPUs to single context mode (aka compute exclusive mode), don't call cudaSetDevice() (or you call the new function to set the valid list of possible devices), and run your app. One process will grab the first GPU, the other will try the first GPU and fail because the context already exists, then (assuming you use CUDART) it will silently retry and create a context on the next GPU. Once you're out of GPUs, context creation will fail.
In other words, all of the problems that Seppo mentioned just go poof and disappear.
Ein weiterer Punkt der erst in dern finalen Version interessant wird.
12. With 2.2 coming in the not-too-distant future, I think it's time to talk about the Windows-specific feature that wasn't included in the beta. As you can probably guess by the subject, we're going to ship a test version of cudart.dll compiled with /MD in a separate package from the rest of the 2.2 toolkit (but it should be out simultaneously or very soon after the main 2.2 release) for people to try out. We're not committing to supporting this going forward or anything like that at this point--we just want some feedback to see if this is useful. I'm not a C# or CLR guy or anything like that, but I'm guessing this will allow you to mix CUDART, C#, all that stuff that people have asked us to support.
If people really like /MD (and based on the number of complaints about the lack of /MD I've seen I'm pretty sure you guys will), we'd certainly like to support it going forward. However, this brings us to a problem; for a lot of reasons, we don't want to support both /MD and /MT. So, we thought we'd just put the question out there. Does anyone have a really good reason why they'd need to stick with /MT as opposed to moving to /MD? From what I know on the subject, I can't think of any reason besides the need to change your project settings, but I'm not the most knowledgeable about Windows internals. There's certainly a possibility that I've missed some giant MSDN advisory claiming that /MD should never be used for anything...
Kurz CUDA 2.2 ist für Programmierer nun noch besser einsetzbar und quasi "Geek heaven"
Für die User ist vorallem die Performancesteigerung interessant. Performance-Tests sollte es erst mit der finalen Version geben um die Beta-Bugs auszuschließen und dann kann man sagen um wieviel sich Programme wie Folding@Home oder PhysX gesteigert haben.
Es gibt Gerüchte das NV PhysX über OpenCL frei gibt, also wird es wahrscheinlich ATI mit DX 11 auch problemlos nutzen können, genauso wie NV über OpenCL Havok GPU-Physik nutzen kann. Möge die bessere Physik Beschleunigung gewinnen...
Damit würden sich die 2 exklusiven Vorteile ausgleichen NV hat durch DX 11 dann auch DX 10.1 und ATI hat durch DX 11 dann auch PhysX.
OpenCL:
http://de.wikipedia.org/wiki/OpenCL
https://www.computerbase.de/forum/t...it-der-gpu-rechnen.426771/page-2#post-5398995
Und nun viel Spaß beim diskutieren, muss dann mal weg
MFG Kasmo
