Warum sind Grafik APIs noch nicht compute-only?
-
Jetzt wo langsam die neuen Grafik APIs raus kommen (dx12 und vulkan), frage ich mich warum die noch nicht auf compute-only umgestiegen sind. Ist die Grafikkarten Hardware doch noch so speziell? Ich hätte erwartet, dass da mittlerweile alles programmierbar ist. Aber trotzdem gibt es noch vertex shader, pixel shader, geometry shader, was-weiß-ich shader, blending states, etc. etc.
Warum stellt man nicht einfach eine pure compute API zur Verfügung?
-
Wenn man lokal beleuchtete Dreiecke zeichnen will, dann ist die Unterteilung in Vertex-Shader und Pixel-Shader doch sinnvoll.
Würde man es auf der CPU selber schreiben, dann nimmt man ja auch den gleichen Algorithmus, wo man diese Shader hat.
Von daher halte ich es für gut, das es für die Grafikausgabe weiterhin Shader gibt.
Für GPU-Rechenaufgaben haste dann ja deine freie programmierbares CUDA.
Nehmen wir mal an, du hättest eine Grafikkarte, die Compute Only ohne Shader ist. Wie würdest du dann Dreicke ausgeben? Nach den gleichen Schema: Dreiecksarray an GPU übergeben, dieses dann mit Hilfe von Tiefen- und Farbpuffer dann zeichen oder ein komplett anderer Ansatz?
-
Die Grafik APIs beschreiben immer noch den idealen Workflow für Grafikkarten der jetzigen Generation. Compute Shader werden zwar immer flexibler, in Tat und Warheit ist es jedoch der Krieg, solche zu entwickeln, da man überall mit Limitierungen zu kämpfen hat. Es gibt so viele Dinge zu beachten und Fehler die man machen kann, es ist ein Murks. Das hat insgesamt sehr viel mit der eigentlichen Hardware zu tun. Klar, theoretisch hat man tausende "Stream Processors", aber die können nicht viel im Vergleich zu einem Core i7 Kern. Wenn du mit diesen Limitierungen eine Grafikschnittstelle selbst nachbaust, landest du genau bei dem Modell, was Direct3D oder OpenGL bieten.
-
graphicsnoob schrieb:
Warum stellt man nicht einfach eine pure compute API zur Verfügung?
Weil der Compute Kram, so wie er im Moment funktioniert, sich nicht gut für Renderingworkloads eignet. Im Compute Mode wird die GPU als statisches, reguläres Gitter aus Threads die alle die selbe Funktion ausführen angesprochen. Rendering ist inhärent dynamisch und irregulär und viele wesentliche Komponenten, wie z.B. ein Dreiecksrasterizer, lassen sich extrem effizient in Hardware lösen. Du wärs erstaunt, wie viel der Grafikpipeline auch auf den allerneuesten GPUs in Hardware gegossen ist (man macht wohl keinen großen Fehler, wenn man davon ausgeht, dass alles, was in D3D12 nicht programmierbar ist, auch auf der GPU tatsächlich nicht in Software gelöst ist)...
-
Hier hat ein Entwickler was dazu gesagt:
I think you're also being a bit short-sighted on the possible use of compute for general graphics. It is not limited to post process. Right now, I estimate about 20% of our graphics pipeline occurs in compute shaders, and we are projecting this to be more then 50% on the next iteration of our engine. In fact, it is even conceivable to build a rendering pipeline entirely in compute shaders. For example, there are alternative rendering primitives to triangles which are actually quite feasible in compute. There was a great talk at SIGGRAPH this year on this subject. If someone gave us a card with only compute pipeline, I'd bet we could build an engine around it which would be plenty fast. In fact, this was the main motivating factors behind the Larabee project. The main problem with Larabee wasn't that it wasn't fast, it was that they failed to be able to map dx9 games to it well enough to be a viable product. I'm not saying that the graphics pipeline will disappear anytime soon (or ever), but it's by no means certain that it's necessary. It's quite possible that in 5 years time Nitrous's rendering pipeline is 100% implemented via compute shaders.
Weiß jemand, welcher Talk genau gemeint ist und er ob online verfügbar ist?
-
ich hab vor paar jahren in der arbeit eine compute-only prototype engine geschrieben. alles an GFX daten war auf GPU, sodass die CPU nur die buffer mit objekt positionen geupdated hat und ab culling bis pixel schreiben lief alles in compute.
ein paar dinge liefen suboptimal (wie dot erwaehnte z.b. rasterization). ich hab mit NV und ATI geredet, ob die fehlenden stuecke freigegeben werden koennten fuer compute. aber sie sind dagegen, weil sie nicht wissen wie sie das am besten offenlegen. es koennte eine intrinsic instruction sein, oder ein job spawner (so wie jetzt wo du ein grid festlegen kannst und cuda sub-jobs startet). aber was auch immer sie entscheiden, muesten sie ewig unterstuetzen.
rasterization ist natuerlich nur eine sache, gibt viele internet optimierungen die schlecht an compute uebergeben werden koennen.
