Nu komme ich doch noch mal zum schreiben, wir wollen doch schön Off-Topic bleiben
Danke für Deine Antwort, arcDaniel!
Wer nun nie mit Vsync spielt, oder vielleicht einen Monitor mit mehr als 60hz hat... wird diesem Verhalten vielleicht nie begegnen.
Ich spiele seit geraumer Zeit mit 59fps-Limit und Vsync, und es ist mir so noch nie aufgefallen. Dann kann ich mich glücklich schätzen, entweder die passenden Spiele zu spielen, zufällig irgendwelche entsprechenden Einstellungen gemacht zu haben, oder einfach unempfindlich gegen solche Ruckler zu sein (kann gut sein, ich habe jede Sekunde eine doppelte Frametime, und die stört mich selbst in CSGO nicht). Dafür treibt mich Tearing in den Niesreiz
Du hast mich dran erinnert, bei Gelegenheit Radeon Chill auszuprobieren - davon hat man auch lange nichts mehr gehört
Jeder hat da andere Erfahrungen und eine andere Vorstellung, was "gut" heißt. Deshalb der Smiley, mir war schon klar, dass viele, u.a. Du, das anders sehen, und auch nicht ohne vertretbaren Grund.
Aber es gibt eben auch die, die aus irgendwelchen Gründen nichts gegen AMD-Treiber haben, und vielleicht ein, zwei Zickereien mehr bei Nvidia erlebt haben. AMD hat sich da dem Hörensagen nach in den letzten Jahren stark verbessert. Kann ich ja nicht beurteilen, hatte seit 2006 nie Probleme

Darum ging es mir.
Soviel zur subjektiven Qualität, die sicher nicht für sich eine Kaufentscheidung ausmachen sollte...
So Erfahrungen wie die von arcDaniel sind da schon eher interessant, das könnte vielleicht mal ein Hardware-Magazin beleuchten...
Dass die Leistung von Radeons in F@h nicht auf die Straße kommt, ist hinlänglich bekannt. In OpenCL scheinen sie ja nicht grundsätzlich nutzlos zu sein, wenn man sich z.B.
Luxmark anguckt.
Der grundsätzliche Unterschied ist, dass NV zum I/O von Daten den Kanal zwischen CPU und GPU quasi offen hält und deswegen einen Thread blockiert (scheinbar hohe CPU-Last). Dafür können Daten sofort ohne Zeitverlust ausgetauscht werden.
AMD hingegen wartet bis eine Anfrage zum Austausch von Daten kommt, öffnet den Kanal und schließt ihn wieder (und wieder von vorne). Dafür ist der Thread nicht blockiert (niedrige CPU-Last). Kostet aber durch die Warterei Zeit und dementsprechend Performance.
Interessant, danke! Leuchtet ein. Ist das bekanntermaßen die AMD'sche Herangehensweise an OpenCL?