Direct3D Äquivalent zu glActiveTexture()
-
Titel sagt alles. Gibt's da überhaupt eine äquivalente Funktion?
-
du solltest immer die Direct3D version angeben, weil die oft das komplette interface neu erfinden.
in Direct3D 9 z.B. "SetTexture" funktion, aus dem direct3d9device interface. disable indem du NULL zuweist.
-
Oups sorry vergessen, ich meine D3D11.
-
-
Danke. Scheint mir das nur so, oder ist das unnötig (?) kompliziert im Gegensatz zu OpenGL? (Ich erwarte eine gute Antwort von dir Dot, als DX11 Beführworter. :p)
-
ja, es ist unnoetig kompliziert. Aber das ist noch simpel im vergleich zu den sonstigen beschraenkungen, z.B. wenn du versuchst compute zu verwenden. MS hat sich lustige kuenstliche beschraenkungen ausgedacht, z.B. koennen nur manche buffer atomics, nur manche koennen mehr als primitive daten addressieren und wenn du dann versuchst die buffer die du in compute nutzt, beim rendering zu verwenden, wirst du feststellen dass es echt nur eine einzige konstelation gibt wie die die "Views" (unordered access view etc.) erstellen kannst (was format usw angeght). und das schlimste ist, das ist nirgens dokumentiert, du kannst entweder das internet durchsuchen und hoffen jemand anderes hatte das problem schon und hat es durch ausprobieren rausgefunden, oder du hast kumpels auf treiberseite die das vermutlich wissen.
aber solange sich AMD und NVidia (und Intel) nicht auf eine gute API einigen, gibt es leider das quasi-monopol von MS.
siehe auch:
http://www.tomshardware.com/news/API-DirectX-11-Shader-Richard-Huddy-PC-gaming,12418.html
-
Was genau findest du daran "unnötig kompliziert"? In OpenGL machst du eben glBindTexture(), in Direct3D machst du PSSetShaderResources(). Das Direct3D System Daten und Views in diese Daten zu trennen, ist imo eine sehr saubere Lösung, es erlaubt z.B. eine Texture als DepthBuffer zu verwenden und den Inhalt später in einem Shader zu samplen etc. Die Tatsache, dass in OpenGL 4.3 nun genau das gleiche System nachträglich draufgeklatsch wurde, spricht imo für sich...überhaupt scheint mir OpenGL mit jeder neuen Version der Spezifikation mehr und mehr ein Direct3D Klon zu werden...
rapso schrieb:
MS hat sich lustige kuenstliche beschraenkungen ausgedacht, z.B. koennen nur manche buffer atomics, nur manche koennen mehr als primitive daten addressieren und wenn du dann versuchst die buffer die du in compute nutzt, beim rendering zu verwenden, wirst du feststellen dass es echt nur eine einzige konstelation gibt wie die die "Views" (unordered access view etc.) erstellen kannst (was format usw angeght).
Ähm, Atomic Operations machen rein semantisch auch nur auf ganz bestimmten UAVs Sinn. Ja, DirectCompute ist in vielen Punkten wesentlich restriktiver als es auf aktuellen Hardwareimplementierungen unbedingt nötig wäre. Ich sah bei den aktuellen Einschränkungen bisher allerdings kein wirklich großes Problem, das einzige, was mich je wirklich mal etwas geärgert hat, war, dass man Dinge wie Atomics und Append/Consume Buffer nur im PixelShader benutzen konnte, was mit Direct3D 11.1 aber hinfällig ist. Wobei ich dazu sagen muss, dass ich allerdings auch praktisch keine Erfahrung mit DirectCompute hab; ich hab meistens mit CUDA und manchmal mit OpenCL zu tun. Und damit sollte man DirectCompute imo nicht vergleichen, wenn dann eher mit den OpenGL ComputeShadern. Ja, sowas gibts interessanterweise mittlerweile auch auf einmal...
Die HLSL Doku und der Compiler sind teilweise leider tatsächlich grottig, da stimm ich dir zu, man kann nur hoffen, dass das in Zukunft besser wird.
rapso schrieb:
und das schlimste ist, das ist nirgens dokumentiert, du kannst entweder das internet durchsuchen und hoffen jemand anderes hatte das problem schon und hat es durch ausprobieren rausgefunden, oder du hast kumpels auf treiberseite die das vermutlich wissen.
Rein aus Interesse: Was genau für ein Problem meinst du?
rapso schrieb:
siehe auch:
http://www.tomshardware.com/news/API-DirectX-11-Shader-Richard-Huddy-PC-gaming,12418.htmlAlso ich bin selbst nicht in der Spieleindustrie tätig und ich hab auch keine Erfahrung auf Konsolen, aber der Artikel sagt so ziemlich das Gegenteil von allem, was einem z.B. gamedev.net und andere entsprechenden Medien so vermitteln. Die generelle Einstellung dort ist wohl eher, dass die Konsolen die Entwicklung zurückhalten, weil die aktuellen Konsolen hardwaremäßig am Stand von 2004 oder so sind. Kaum ein Spiel nutzt heutzutage Direct3D 11 auch nur ansatzweise aus. Spiele werden oft für den kleinsten gemeinsamen Nenner ausgelegt und die PC Version ist dann am Ende mehr oder weniger ein Port der Konsolenversion wo einfach ein paar Regler für die Grafikqualität hochgedreht wurden. Das reicht aber eben rein prinzipiell nicht für eine sinnvolle Nutzung von Direct3D 11 Hardware aus. Das Problem hat mit zu wenig direktem Zugriff auf die Hardware also rein gar nichts zu tun. Und: Ein direkterer Zugriff auf die Hardware, völlig ohne oder mit nur ganz wenig Abstraktion dazwischen, macht auf dem PC überhaupt keinen Sinn; denn im Gegensatz zu den Konsolen hat man dort ein unglaublich breites Spektrum an Hardware zu supporten. Ich kann mir nicht vorstellen, dass irgendwer ernsthaft bei jeder Software eigene Treiber für jede auch nur erdenkliche Hardware mitliefern will. Die Grafikkartenhersteller wollen nichtmal Debug Symbole für ihre Treiber rausrücken, dass die den kompletten Source oder auch nur genug Doku hergeben, damit sowas überhaupt in greifbare Nähe rücken würde, ist wohl kaum vorstellbar. "Droppen wir jegliche API und plötzlich kann jeder alles machen" ist imo jedenfalls einfach nur eine völlig bescheuerte Aussage. Genau wie auch z.B. das hier:
[...] a good chunk of the gaming industry is developing titles for the Xbox 360 and PlayStation 3 first and then porting them over to the PC thereafter. The result is that PC versions are only slightly superior to their console counterparts on a visual sense even though a high-end graphics card has at least ten times the horsepower of the Xbox 360's Xenos GPU and the PlayStation 3's GeForce 7-series architecture.
What this means is that-- although PC graphics are better than the console version-- developers can't tap into the PC's true potential because they can't program hardware directly at a low-level, forced to work through DirectX instead.
Sry, aber ich kann nicht nachvollziehen, wie genau man aus "Spiele werden vorranging zunächst für Konsolen entwickelt und dann auf den PC portiert" schließen will, dass jeglicher Versuch, auf dem PC die Hardware gescheit zu nutzen, aufgrund von API Overhead von vorn herein zum Scheitern verurteilt wäre. Ich seh da keinen sinnvollen Zusammenhang. Ich würde mal meinen, dass die Gründe dafür viel eher rein geschäftlicher Natur sind...
Ich hätte absolut nichts gegen eine noch modernere, noch leichtgewichtigere, noch bessere API als Direct3D 11; ich wär wohl der erste der umsteigen würde. Aber irgendeine Art von Hardware-Abstraktion wird es auf dem PC rein prinzipiell immer brauchen. Und irgendwelche "close to the metal" APIs, wo dann jeder Hersteller sein eigenes Süppchen kocht und jede zweite Karte ihren eigenen Renderpfad braucht, wie der nette Herr von AMD aus dem Artikel sie uns sicherlich gerne verkaufen würde, halt ich jedenfalls für keine besonders attraktive "Alternative" zu sowas die Direct3D...
-
dot schrieb:
Was genau findest du daran "unnötig kompliziert"? In OpenGL machst du eben glBindTexture(), in Direct3D machst du PSSetShaderResources(). Das Direct3D System Daten und Views in diese Daten zu trennen, ist imo eine sehr saubere Lösung, es erlaubt z.B. eine Texture als DepthBuffer zu verwenden und den Inhalt später in einem Shader zu samplen etc. Die Tatsache, dass in OpenGL 4.3 nun genau das gleiche System nachträglich draufgeklatsch wurde, spricht imo für sich...überhaupt scheint mir OpenGL mit jeder neuen Version der Spezifikation mehr und mehr ein Direct3D Klon zu werden...
unnoetig kompliziert ist dass man diese resourcen erstellen muss, statt einfach zu setzen was man gerade braucht. das macht die arbeit relativ unflexibel und falls man datadriven resourcen hat, auch aufwendiger alles zu verwalten.
rapso schrieb:
MS hat sich lustige kuenstliche beschraenkungen ausgedacht, z.B. koennen nur manche buffer atomics, nur manche koennen mehr als primitive daten addressieren und wenn du dann versuchst die buffer die du in compute nutzt, beim rendering zu verwenden, wirst du feststellen dass es echt nur eine einzige konstelation gibt wie die die "Views" (unordered access view etc.) erstellen kannst (was format usw angeght).
Atomic Operations machen rein semantisch nur auf UAVs Sinn.
ich glaube dann hast du dich noch nicht richtig damit befasst, laut docu sind atomics einzig auf RWByteAddressBuffer moeglich. wenn du z.B. einen RWStructuredBuffer hast, kannst du das nicht, was aber sehr gaengig ist um z.B. ein ABA problem zu umgehen. in Cuda und OpenCL (was teil vom neusten OGL ist), ist das problemlos moeglich.
Ueberhaupt macht es keinen sinn zig verschiedene buffertypen anzulegen, jeder treiber mapt das wieder auf denselben typen. das ganze hat garkeinen HW grund und ist kein wunsch von developern gewesen, reine MS idee die einen echt restriktiert. Ich musste am ende einen OpenCL software rasterizer schreiben um vernuenftig arbeiten zu koennen, weil ich mit D3D soviel buffer kopieren und soviel drawcalls mit verschiedenen views auf dieselben resourcen machen musste, dass es am ende tatsaechlich schneller war.Ja, DirectCompute ist in vielen Punkten wesentlich restriktiver als es auf aktuellen Hardwareimplementierungen unbedingt nötig wäre. Ich sah bei den aktuellen Einschränkungen bisher allerdings kein wirklich großes Problem, das einzige, was mich je wirklich mal etwas geärgert hat, war, dass man Dinge wie Atomics und Append/Consume Buffer nur im PixelShader benutzen konnte, was mit Direct3D 11.1 aber hinfällig ist. Wobei ich dazu sagen muss, dass ich allerdings auch praktisch keine Erfahrung mit DirectCompute hab, ich hab da meistens mit CUDA und manchmal mit OpenCL zu tun. Und damit sollte man DirectCompute imo nicht vergleichen, wenn dann eher mit den OpenGL ComputeShadern. Ja, sowas gibts interessanterweise mittlerweile auch auf einmal...
ja, opengl hat opencl integriert, das war der einzige vorteil den D3D hatte, solange man nicht gegen mauern lief. viel angenehmer waere es aber gewesen, wenn Cuda/OpenCL einfach ein rasterizer interface bekommen haette. mittels triangles zu spawnen ist nichts anderes als zZ quadratische wavefronts bzw warps zu spawnen. vermutlich haellt man sich hier nur den weg offen mal HW ohne rasterizer fuer HPC zu basteln.
rapso schrieb:
und das schlimste ist, das ist nirgens dokumentiert, du kannst entweder das internet durchsuchen und hoffen jemand anderes hatte das problem schon und hat es durch ausprobieren rausgefunden, oder du hast kumpels auf treiberseite die das vermutlich wissen.
Rein aus Interesse: Was genau für ein Problem meinst du?
ich habe es nicht mehr exakt im kopf, ich glaube ich hatte ein depth buffer versucht als resource fuer einen simplen compute shader zu setzen. wenn ich mich richtig entsinne war es nicht einfach eine konstelation von depthbuffer format <-> accessview format und im shader von buffer deklaration zu finden.
lustigerweise lief mal eine kombination durch ausprobieren, aber mit D3D im debug gab es dann einen error. schon 1/2 jahre her.rapso schrieb:
siehe auch:
http://www.tomshardware.com/news/API-DirectX-11-Shader-Richard-Huddy-PC-gaming,12418.htmlAlso ich bin selbst kein Spieleentwickler und ich hab auch keine Erfahrung auf Konsolen, aber der Artikel sagt so ziemlich das Gegenteil von dem, was einem z.B. gamedev.net und andere entsprechenden Medien so vermitteln. Die generelle Einstellung dort ist wohl eher, dass die Konsolen die Entwicklung zurückhalten, weil die aktuellen Konsolen hardwaremäßig am Stand von 2005 oder so sind. Kaum ein Spiel nutzt heutzutage Direct3D 11 auch nur ansatzweise aus. Spiele werden oft für den kleinsten gemeinsamen Nenner ausgelegt und die PC Version ist dann am Ende mehr oder weniger ein Port der Konsolenversion wo einfach ein paar Regler für die Grafikqualität hochgedreht wurden.
Ich glaube das ist nicht so recht der punkt des artikels. punkt ist eher, obwohl die konsolen ueber ein halbes jahrzehnt auf dem buckel haben, bekommt man auf ihnen dinge hin die weitaus staerkere PCs in die kniee zweingen. natuerlich hat ein PC 2x die textur aufloesung und 1080p mit 4xAA statt 720p mit 2xAA. aber eine xbox/ps3 hat auch nur ihre 20GB/s speicherbandbreite. ein PC hat bis 300GB/s nur auf der GPU. dazu kommen die 200GFlops gegen die 5000GFlops+ auf PCs.
Ein direkterer Zugriff auf die Hardware, völlig ohne oder mit nur wenig Abstraktion dazwischen, macht auf dem PC sowieso keinen Sinn; denn im Gegensatz zu den Konsolen hat man dort ein unglaublich breites Spektrum an Hardware zu supporten. Ich kann mir nicht vorstellen, dass irgendwer ernsthaft bei jeder Software eigene Treiber für jede auch nur erdenkliche Hardware mitliefern will.
doch, das ist sehr sinnvoll, es muss nur richtig gemacht werden. HW ist heutzutage nicht so grundverschieden, auch mit neuen generationen nicht. was die HW kann oder nicht ist dann nicht mehr als ein featurelevel bei D3D11, eine neuere HW kann alte features native unterstuetzen, eine alte HW kann neuere absolut nicht, das ist aber beim release vom spiel bekannt (aenlich den feature leveln eben).
Entwickler koennen dann entweder ein unterstes verwenden, oder ein paar extra features mit besseren HW level erlauben. dafuer ist kein extra treiber noetig. auf konsolen haben wir auch keinen treiber, aber es kommen immer neue HW revisionen. z.B. ist die neuste Xbox nur ein SoC bei dem die CPU und GPU nicht mehr ueber FSB sondern direkt kommunizieren. Sony koennte auch locker eine PS3 rausbringen mit 4x der power und tesselation ohne dass irgend ein altes spiel nicht mehr laufen wuerde.
Nintendo macht sowas seit jahren. vermutlich wird auf der WiiU noch GameCube software funzen. dabei sind laufwerke, cpu, ram ein weitaus groesseres problem als die GPU (die auf konsolen fast komplett ohne layer laeuft), einen layer auszutauschen der ein commandbuffer interpretiert, das ist wirklich einfach.Und die Grafikkartenhersteller wollen nichtmal Debug Symbols für ihre Treiber rausrücken, dass die den kompletten Source oder auch nur genug Doku hergeben, dass sowas überhaupt in greifbare Nähe rücken würde, ist wohl kaum vorstellbar.
komplette intel GPU doku http://intellinuxgraphics.org/documentation.html (oft schon geupdated bevor die GPU zu kaufen ist)
ati dokumentation: http://www.x.org/docs/AMD/das ist weitaus mehr 'low level' info als ein einheitliches low level interace benoetigen wuerde.
"Droppen wir einfach mal so jegliche API und plötzlich kann jeder alles machen" ist imo jedenfalls nicht nur völlig impraktikabel, sondern einfach nur eine völlig bescheuerte Aussage.
wie gut dass das niemand sagt L), vermutlich sehr inteligend von AMD zu sagen, dass sie eine einheitliche low level schnittstelle von Hardware vendorn definiert haben wollen, statt high level D3d. Ohne lustige kuenstliche restriktionen von MS, ohne ewig langen verhandlungen die erst nach jahren features freigeben die die HW schon ewig hat, oft sogar inkompatibel zur hardware (z.b. hat fast jede ATI GPU seit ca dx8 eine tesselation einheit, nur konnte niemand MS zu einer freigabe ueberreden). Ob deine HW erfolg hat, haengt oft von MS ab. du musst gut freund sein etc. sonst wird ein detail so definiert, dass die 5jahre entwicklung die du in dieses feature deiner HW gesteckt hast komplett umsonst sind (bzw sogar hinderlich sind, weil in deiner HW nun etwas steckt was brach liegt und platz fuer nuetzliche dinge versperrt).
Genau wie auch z.B. das hier:
[...] a good chunk of the gaming industry is developing titles for the Xbox 360 and PlayStation 3 first and then porting them over to the PC thereafter. The result is that PC versions are only slightly superior to their console counterparts on a visual sense even though a high-end graphics card has at least ten times the horsepower of the Xbox 360's Xenos GPU and the PlayStation 3's GeForce 7-series architecture.
What this means is that-- although PC graphics are better than the console version-- developers can't tap into the PC's true potential because they can't program hardware directly at a low-level, forced to work through DirectX instead.
Sry, aber ich kann nicht nachvollziehen, wie genau man aus "Spiele werden vorranging zunächst für Konsolen entwickelt und dann auf den PC portiert" schließen will, dass Spieleprogrammierer die PC Hardware nicht gut genug nutzen können, das macht imo überhaupt keinen Sinn. Ich würde mal meinen, dass die Gründe dafür viel eher rein geschäftlicher Natur sind...
wenn man nicht drinnen steckt, versteht man es natuerlich nicht, aber dann sollte man es nicht bewerten ;).
Auf konsolen hast du halt sehr low level zugriff und viele moeglichkeiten die der PC nicht bietet.
z.B.: als D3D rauskam, waren ploetzlich drawcalls 2 bis 5mal langsammer als bei OpenGL (gibt eine NV presentation dazu) (oh, und ich meine nicht das erste D3D bei dem man noch von hand commandbuffer gestrickt hat, 3 oder 5 glaube ich). auf konsolen, mit CPUs die in vanilla benchmarks mit ca Celeron 900 kaempfen, hat man weit mehr drawcalls. sowas wie KillZone schickt bis 20k drawcalls pro frame, high end PCs koennen dir vielleicht bis 10k bieten, egal wieviel cores du hast, egal wieviel GHz, egal wieviel die GPU verarbeiten koennte.
deswegen hast du Highend PCs die damals probleme hatten GTA3 fluessig darzustellen, das auf PS2 gut lief. GTA4 und RedDR laeuft ebenfalls bescheiden.auf konsolen kannst du jedes dreieck einzeln generieren bevor du es zeichnest, auf PC war das noch zu 3dfx zeiten so, unter windows und vor allem seit TnL, kannst du das vergessen wenn du performance willst. dabei ist das kein hardware problem, du koenntest locker 8GB/s an triangles per PCIe schicken (falls du backface culling etc nutzt waere das RAW sogar weitaus mehr). in meinen Test auf PS3, hab ich auf einer SPU fast 200Mio Vertice/s transformiert. 6SPUs -> 1.2Mrd vertices. (echte level daten, kein teapot das nur 1000mal instanziert wird).
zZ bist du auf PC meist pixel limitiert und deine CPU ist oft idle (gerade ein 6core wird sicher selten >50% genutzt). du koenntest also wie auf konsole, simple dinge auf CPU transformieren und die GPU so fuer nur fragment shading entlasten.auf konsolen kannst du buffer nutzen wie du willst, ohne irgendwelche views zu erstellen, DX9 HW oder letzte generation mit PS2, es ist kein problem z.b. ein "stream out" zu machen in einen buffer den du dann als vertexbuffer nutzt, das ging bei DX9 nur auf ATI mit einem R2VB hack.
auf der anderen seite gibt es funktionen die keine HW hat, die aber emuliert wird, durch z.B. shader patchen, weil MS das unbedingt in d3d haben moechte.man darf ueber die meisten dinge einfach nicht sprechen, NDA etc. deswegen sind meine beispiel etwas duerftig. zeigen jedoch die limits die fakt sind.
nach dem Huddy interview von AMD, kam ein paar tage spaeter eine "richtigstellung" in der man natuerlich sagte, D3D ist das einzig richtige und man findet es toll, von AMDs pressesprecher.
-
rapso schrieb:
unnoetig kompliziert ist dass man diese resourcen erstellen muss, statt einfach zu setzen was man gerade braucht. das macht die arbeit relativ unflexibel und falls man datadriven resourcen hat, auch aufwendiger alles zu verwalten.
Mag sein, dass es ein klein wenig komplizierter zu verwenden ist, dafür kann der API Overhead aber potentiell drastisch reduziert werden, da alle möglichen Validierungen, die in Direct3D 9 eben jedes Mal beim Setzen gewisser Ressourcen gemacht werden mussten, nun nurmehr einmal beim Erzeugen gemacht werden müssen. Genau darum sind Draw Calls und State Changes in Direct3D 11 potentiell sehr viel effizienter als in Direct3D 9...
rapso schrieb:
ich glaube dann hast du dich noch nicht richtig damit befasst, laut docu sind atomics einzig auf RWByteAddressBuffer moeglich. wenn du z.B. einen RWStructuredBuffer hast, kannst du das nicht, was aber sehr gaengig ist um z.B. ein ABA problem zu umgehen.
Da wär ich mal nicht so vorschnell, laut Doku sind Atomics sehr wohl auf einem RWStructuredBuffer möglich
Wenn dies tatsächlich nicht stimmen würde (der fxc kompiliert es jedenfalls), dann würde ich dir natürlich zustimmen, dass das wirklich eine sehr lästige Einschränkung wäre...rapso schrieb:
in Cuda und OpenCL (was teil vom neusten OGL ist), ist das problemlos moeglich.
Tut mir leid dich enttäuschen zu müssen, aber OpenGL ComputeShader haben mit OpenCL rein gar nichts zu tun...
rapso schrieb:
viel angenehmer waere es aber gewesen, wenn Cuda/OpenCL einfach ein rasterizer interface bekommen haette. mittels triangles zu spawnen ist nichts anderes als zZ quadratische wavefronts bzw warps zu spawnen.
Wenn du wüsstest, wie oft wir uns das schon gewünscht hätten...aber wenn man NVIDIA danach fragt, dann bekommt man als Antwort, dass das problemlos möglich wäre, aber solange nicht gerade Autodesk oder so das gerne hätte, wirds einfach nicht passieren...
rapso schrieb:
doch, das ist sehr sinnvoll, es muss nur richtig gemacht werden. HW ist heutzutage nicht so grundverschieden, auch mit neuen generationen nicht. was die HW kann oder nicht ist dann nicht mehr als ein featurelevel bei D3D11, eine neuere HW kann alte features native unterstuetzen, eine alte HW kann neuere absolut nicht, das ist aber beim release vom spiel bekannt (aenlich den feature leveln eben).
Entwickler koennen dann entweder ein unterstes verwenden, oder ein paar extra features mit besseren HW level erlauben. dafuer ist kein extra treiber noetig.Das ist mir natürlich sehr wohl bewusst, dafür bräuchte es eben noch bessere APIs. Gegen sowas hätte ich natürlich absolut nix...
rapso schrieb:
auf konsolen haben wir auch keinen treiber, aber es kommen immer neue HW revisionen. z.B. ist die neuste Xbox nur ein SoC bei dem die CPU und GPU nicht mehr ueber FSB sondern direkt kommunizieren. Sony koennte auch locker eine PS3 rausbringen mit 4x der power und tesselation ohne dass irgend ein altes spiel nicht mehr laufen wuerde.
Nintendo macht sowas seit jahren. vermutlich wird auf der WiiU noch GameCube software funzen. dabei sind laufwerke, cpu, ram ein weitaus groesseres problem als die GPU (die auf konsolen fast komplett ohne layer laeuft), einen layer auszutauschen der ein commandbuffer interpretiert, das ist wirklich einfach.Das wusste ich natürlich nicht, aber sehr interessant, danke für die Info
rapso schrieb:
Und die Grafikkartenhersteller wollen nichtmal Debug Symbols für ihre Treiber rausrücken, dass die den kompletten Source oder auch nur genug Doku hergeben, dass sowas überhaupt in greifbare Nähe rücken würde, ist wohl kaum vorstellbar.
komplette intel GPU doku http://intellinuxgraphics.org/documentation.html (oft schon geupdated bevor die GPU zu kaufen ist)
ati dokumentation: http://www.x.org/docs/AMD/das ist weitaus mehr 'low level' info als ein einheitliches low level interace benoetigen wuerde.
Dachte mir schon, dass du das gleich verlinken wirst...hast auch schon mal auf das Datum der AMD OpenGPU Doku geschaut?
rapso schrieb:
Auf konsolen hast du halt sehr low level zugriff und viele moeglichkeiten die der PC nicht bietet.
Wie gesagt, ich hätte natürlich absolut nichts gegen eine bessere, von Hardwareherstellern definierte, API. Aber OpenGL ist in der Hinsicht eben genau so wenig eine Lösung wie Direct3D. Der Grund, wieso ich Direct3D mag, ist nicht, dass es von Microsoft ist, sondern dass es die imo beste entsprechende API ist, die uns auf dem PC momentan zur Verfügung steht. Sobald es was besseres gibt, bin ich der erste der umsteigt...
-
dot schrieb:
rapso schrieb:
unnoetig kompliziert ist dass man diese resourcen erstellen muss, statt einfach zu setzen was man gerade braucht. das macht die arbeit relativ unflexibel und falls man datadriven resourcen hat, auch aufwendiger alles zu verwalten.
Mag sein, dass es ein klein wenig komplizierter zu verwenden ist, dafür kann der API Overhead aber potentiell drastisch reduziert werden, da alle möglichen Validierungen, die in Direct3D 9 eben jedes Mal beim Setzen gewisser Ressourcen gemacht werden mussten, nun nurmehr einmal beim Erzeugen gemacht werden müssen. Genau darum sind Draw Calls und State Changes in Direct3D 11 potentiell sehr viel effizienter als in Direct3D 9...
das ist eben die self fullfilling prophecy. der API overhead entsteht erst durch D3D.
Intern arbeiten die GPUs nicht mit acces views etc. auf treiber seite muss also weiterhin hin und her uebersetzt werden, ob D3D9 oder D3D11. es gab auch schon frueher dinge die zu mehr drawcalls etc. resultieren konnten, die es in HW nicht gibt. lediglich die d3d schnittstelle wurde weniger oft aufgerufen und das komplizierte komposing auf client seite wie auch das decomposing auf driver seite hatte weniger overhead -> war schneller.rapso schrieb:
ich glaube dann hast du dich noch nicht richtig damit befasst, laut docu sind atomics einzig auf RWByteAddressBuffer moeglich. wenn du z.B. einen RWStructuredBuffer hast, kannst du das nicht, was aber sehr gaengig ist um z.B. ein ABA problem zu umgehen.
Laut Doku sind Atomics sehr wohl auf einem RWStructuredBuffer möglich. Wenn dies tatsächlich nicht stimmen würde (der fxc kompiliert es jedenfalls), dann würde ich dir natürlich zustimmen, dass das wirklich eine sehr lästige Einschränkung wäre...
http://msdn.microsoft.com/en-us/library/windows/desktop/ff471359(v=vs.85).aspx
soweit ich sehe, sind die RWByteAddressBuffer die einzigen die interlock funktionen bieten:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff471475(v=vs.85).aspx
(btw ist 'byte addressed' auch ein witz.)rapso schrieb:
in Cuda und OpenCL (was teil vom neusten OGL ist), ist das problemlos moeglich.
Tut mir leid dich enttäuschen zu müssen, aber OpenGL ComputeShader haben mit OpenCL rein gar nichts zu tun...
hmm, hatte glaube ich nur mal bei heise gelesen, nie selbst die doku angeschaut, kannst da gut recht haben.
rapso schrieb:
viel angenehmer waere es aber gewesen, wenn Cuda/OpenCL einfach ein rasterizer interface bekommen haette. mittels triangles zu spawnen ist nichts anderes als zZ quadratische wavefronts bzw warps zu spawnen.
Wenn du wüsstest, wie oft wir uns das schon gewünscht hätten...aber wenn man NVIDIA danach fragt, dann bekommt man als Antwort, dass das problemlos möglich wäre, aber solange nicht gerade Autodesk oder so das gerne hätte, wirds einfach nicht passieren...
viele wie autodesk haben schon gefragt (und ich auch in jedem einzelnen meeting mit amd, nvidia, intel), die windgen sich wie heringe. genau wie bei programmierbarem command prozessor und texture sampler.
rapso schrieb:
Und die Grafikkartenhersteller wollen nichtmal Debug Symbols für ihre Treiber rausrücken, dass die den kompletten Source oder auch nur genug Doku hergeben, dass sowas überhaupt in greifbare Nähe rücken würde, ist wohl kaum vorstellbar.
komplette intel GPU doku http://intellinuxgraphics.org/documentation.html (oft schon geupdated bevor die GPU zu kaufen ist)
ati dokumentation: http://www.x.org/docs/AMD/das ist weitaus mehr 'low level' info als ein einheitliches low level interace benoetigen wuerde.
Dachte mir schon, dass du das gleich verlinken wirst...hast auch schon mal auf das Datum der AMD OpenGPU Doku geschaut?
sorry, war nur quick googlen, das ist latest low level ISA manual: http://developer.amd.com/tools/hc/AMDAPPSDK/assets/AMD_Southern_Islands_Instruction_Set_Architecture.pdf
amd hat afaik alles public gemacht was noetig ist um open source treiber zu entwickeln, genau wie intel, ich glaube Via auch. Arm, ImgTec, nvidia und Qualcomm verschliessen sich. jedoch, wie gesagt, waere eine intermediate low level api nichts derart geheimes. sicher kann man sogar ogl und d3d on-top implementieren, wenn man wollte. punkt ist wohl, dass das ganze auf application ebene verbaut ist.rapso schrieb:
Auf konsolen hast du halt sehr low level zugriff und viele moeglichkeiten die der PC nicht bietet.
Wie gesagt, ich hätte natürlich absolut nichts gegen eine bessere, von Hardwareherstellern definierte, API. Aber OpenGL ist in der Hinsicht eben genau so wenig eine Lösung wie Direct3D. Der Grund, wieso ich Direct3D mag, ist nicht, dass es von Microsoft ist, sondern dass es die imo beste entsprechende API ist, die uns auf dem PC momentan zur Verfügung steht. Sobald es was besseres gibt, bin ich der erste der umsteigt...
das 'imo' trifft es gut. beides ist schei***, choose your poison. deswegen finde ich OpenglES 2.0 am besten, kommt konsolen am nahesten.
-
dot schrieb:
rapso schrieb:
unnoetig kompliziert ist dass man diese resourcen erstellen muss, statt einfach zu setzen was man gerade braucht. das macht die arbeit relativ unflexibel und falls man datadriven resourcen hat, auch aufwendiger alles zu verwalten.
Mag sein, dass es ein klein wenig komplizierter zu verwenden ist, dafür kann der API Overhead aber potentiell drastisch reduziert werden, da alle möglichen Validierungen, die in Direct3D 9 eben jedes Mal beim Setzen gewisser Ressourcen gemacht werden mussten, nun nurmehr einmal beim Erzeugen gemacht werden müssen. Genau darum sind Draw Calls und State Changes in Direct3D 11 potentiell sehr viel effizienter als in Direct3D 9...
das ist eben die self fullfilling prophecy. der API overhead entsteht erst durch D3D.
Intern arbeiten die GPUs nicht mit acces views etc. auf treiber seite muss also weiterhin hin und her uebersetzt werden, ob D3D9 oder D3D11. es gab auch schon frueher dinge die zu mehr drawcalls etc. resultieren konnten, die es in HW nicht gibt. lediglich die d3d schnittstelle wurde weniger oft aufgerufen und das komplizierte komposing auf client seite wie auch das decomposing auf driver seite hatte weniger overhead -> war schneller.rapso schrieb:
ich glaube dann hast du dich noch nicht richtig damit befasst, laut docu sind atomics einzig auf RWByteAddressBuffer moeglich. wenn du z.B. einen RWStructuredBuffer hast, kannst du das nicht, was aber sehr gaengig ist um z.B. ein ABA problem zu umgehen.
Laut Doku sind Atomics sehr wohl auf einem RWStructuredBuffer möglich. Wenn dies tatsächlich nicht stimmen würde (der fxc kompiliert es jedenfalls), dann würde ich dir natürlich zustimmen, dass das wirklich eine sehr lästige Einschränkung wäre...
http://msdn.microsoft.com/en-us/library/windows/desktop/ff471359(v=vs.85).aspx
soweit ich sehe, sind die RWByteAddressBuffer die einzigen die interlock funktionen bieten:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff471475(v=vs.85).aspx
(btw ist 'byte addressed' auch ein witz.)rapso schrieb:
in Cuda und OpenCL (was teil vom neusten OGL ist), ist das problemlos moeglich.
Tut mir leid dich enttäuschen zu müssen, aber OpenGL ComputeShader haben mit OpenCL rein gar nichts zu tun...
hmm, hatte glaube ich nur mal bei heise gelesen, nie selbst die doku angeschaut, kannst da gut recht haben.
rapso schrieb:
viel angenehmer waere es aber gewesen, wenn Cuda/OpenCL einfach ein rasterizer interface bekommen haette. mittels triangles zu spawnen ist nichts anderes als zZ quadratische wavefronts bzw warps zu spawnen.
Wenn du wüsstest, wie oft wir uns das schon gewünscht hätten...aber wenn man NVIDIA danach fragt, dann bekommt man als Antwort, dass das problemlos möglich wäre, aber solange nicht gerade Autodesk oder so das gerne hätte, wirds einfach nicht passieren...
viele wie autodesk haben schon gefragt (und ich auch in jedem einzelnen meeting mit amd, nvidia, intel), die windgen sich wie heringe. genau wie bei programmierbarem command prozessor und texture sampler.
rapso schrieb:
Und die Grafikkartenhersteller wollen nichtmal Debug Symbols für ihre Treiber rausrücken, dass die den kompletten Source oder auch nur genug Doku hergeben, dass sowas überhaupt in greifbare Nähe rücken würde, ist wohl kaum vorstellbar.
komplette intel GPU doku http://intellinuxgraphics.org/documentation.html (oft schon geupdated bevor die GPU zu kaufen ist)
ati dokumentation: http://www.x.org/docs/AMD/das ist weitaus mehr 'low level' info als ein einheitliches low level interace benoetigen wuerde.
Dachte mir schon, dass du das gleich verlinken wirst...hast auch schon mal auf das Datum der AMD OpenGPU Doku geschaut?
sorry, war nur quick googlen, das ist latest low level ISA manual: http://developer.amd.com/tools/hc/AMDAPPSDK/assets/AMD_Southern_Islands_Instruction_Set_Architecture.pdf
amd hat afaik alles public gemacht was noetig ist um open source treiber zu entwickeln, genau wie intel, ich glaube Via auch. Arm, ImgTec, nvidia und Qualcomm verschliessen sich. jedoch, wie gesagt, waere eine intermediate low level api nichts derart geheimes. sicher kann man sogar ogl und d3d on-top implementieren, wenn man wollte. punkt ist wohl, dass das ganze auf application ebene verbaut ist.rapso schrieb:
Auf konsolen hast du halt sehr low level zugriff und viele moeglichkeiten die der PC nicht bietet.
Wie gesagt, ich hätte natürlich absolut nichts gegen eine bessere, von Hardwareherstellern definierte, API. Aber OpenGL ist in der Hinsicht eben genau so wenig eine Lösung wie Direct3D. Der Grund, wieso ich Direct3D mag, ist nicht, dass es von Microsoft ist, sondern dass es die imo beste entsprechende API ist, die uns auf dem PC momentan zur Verfügung steht. Sobald es was besseres gibt, bin ich der erste der umsteigt...
das 'imo' trifft es gut. beides ist schei***, choose your poison. deswegen finde ich OpenglES 2.0 am besten, kommt konsolen am nahesten.
-
rapso schrieb:
dot schrieb:
rapso schrieb:
ich glaube dann hast du dich noch nicht richtig damit befasst, laut docu sind atomics einzig auf RWByteAddressBuffer moeglich. wenn du z.B. einen RWStructuredBuffer hast, kannst du das nicht, was aber sehr gaengig ist um z.B. ein ABA problem zu umgehen.
Laut Doku sind Atomics sehr wohl auf einem RWStructuredBuffer möglich. Wenn dies tatsächlich nicht stimmen würde (der fxc kompiliert es jedenfalls), dann würde ich dir natürlich zustimmen, dass das wirklich eine sehr lästige Einschränkung wäre...
http://msdn.microsoft.com/en-us/library/windows/desktop/ff471359(v=vs.85).aspx
soweit ich sehe, sind die RWByteAddressBuffer die einzigen die interlock funktionen bieten:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff471475(v=vs.85).aspx
(btw ist 'byte addressed' auch ein witz.)Als Methode haben es wohl nur RWByteAddressBuffer. Aber es gibt auch noch die da:
MSDN schrieb:
Atomic functions which implement interlocked operations are allowed on int and uint elements in an RWStructuredBuffer.
rapso schrieb:
dot schrieb:
rapso schrieb:
viel angenehmer waere es aber gewesen, wenn Cuda/OpenCL einfach ein rasterizer interface bekommen haette. mittels triangles zu spawnen ist nichts anderes als zZ quadratische wavefronts bzw warps zu spawnen.
Wenn du wüsstest, wie oft wir uns das schon gewünscht hätten...aber wenn man NVIDIA danach fragt, dann bekommt man als Antwort, dass das problemlos möglich wäre, aber solange nicht gerade Autodesk oder so das gerne hätte, wirds einfach nicht passieren...
viele wie autodesk haben schon gefragt (und ich auch in jedem einzelnen meeting mit amd, nvidia, intel), die windgen sich wie heringe. genau wie bei programmierbarem command prozessor und texture sampler.
Gut zu wissen, dass eifrig danach gefragt wird, vielleicht bekommen wir es dann irgendwann sogar mal..
rapso schrieb:
jedoch, wie gesagt, waere eine intermediate low level api nichts derart geheimes.
Ja, sowas wäre natürlich ziemlich nice...
-
dot schrieb:
MSDN schrieb:
Atomic functions which implement interlocked operations are allowed on int and uint elements in an RWStructuredBuffer.
ok, ich schiebe das auf die docu
rapso schrieb:
dot schrieb:
rapso schrieb:
viel angenehmer waere es aber gewesen, wenn Cuda/OpenCL einfach ein rasterizer interface bekommen haette. mittels triangles zu spawnen ist nichts anderes als zZ quadratische wavefronts bzw warps zu spawnen.
Wenn du wüsstest, wie oft wir uns das schon gewünscht hätten...aber wenn man NVIDIA danach fragt, dann bekommt man als Antwort, dass das problemlos möglich wäre, aber solange nicht gerade Autodesk oder so das gerne hätte, wirds einfach nicht passieren...
viele wie autodesk haben schon gefragt (und ich auch in jedem einzelnen meeting mit amd, nvidia, intel), die windgen sich wie heringe. genau wie bei programmierbarem command prozessor und texture sampler.
Gut zu wissen, dass eifrig danach gefragt wird, vielleicht bekommen wir es dann irgendwann sogar mal..
http://www.geeks3d.com/20120920/programmable-blending-on-mobile-and-desktop-gpus-opengl/
das wird wohl als naechstes kommen, frage ist nur wann MS sich danach fuehlt.
-
rapso schrieb:
dot schrieb:
MSDN schrieb:
Atomic functions which implement interlocked operations are allowed on int and uint elements in an RWStructuredBuffer.
ok, ich schiebe das auf die docu
Ja, die HLSL Doku entspricht leider bei weitem nicht dem für die MSDN sonst üblichen Standard...
rapso schrieb:
das wird wohl als naechstes kommen, frage ist nur wann MS sich danach fuehlt.
Naja, im dem Artikel steht aber auch schon, dass das eben auf Mobile GPUs funktioniert weil die tile based arbeiten. Auf Desktops ist das nicht so einfach, genauere Diskussion des Problem z.b. hier ganz unten. Cool wär das natürlich schon, ich denk das hat sich jeder schonmal gewünscht. Wobei ich natürlich noch lieber gleich Zugriff auf die komplette Fragment List hätte...
-
dot schrieb:
rapso schrieb:
dot schrieb:
MSDN schrieb:
Atomic functions which implement interlocked operations are allowed on int and uint elements in an RWStructuredBuffer.
ok, ich schiebe das auf die docu
Ja, die HLSL Doku entspricht leider bei weitem nicht dem für die MSDN sonst üblichen Standard...
frueher war die DirectX docu eigentlich weit ueber dem msdn standard, also bis ca DirectX9
rapso schrieb:
das wird wohl als naechstes kommen, frage ist nur wann MS sich danach fuehlt.
Naja, im dem Artikel steht aber auch schon, dass das eben auf Mobile GPUs funktioniert weil die tile based arbeiten. Auf Desktops ist das nicht so einfach, genauere Diskussion des Problem z.b. hier ganz unten. Cool wär das natürlich schon, ich denk das hat sich jeder schonmal gewünscht. Wobei ich natürlich noch lieber gleich Zugriff auf die komplette Fragment List hätte...
Update: NVIDIA already exposes the same extension for its Tegra plateform: GL_NV_shader_framebuffer_fetch. According to the spec, GL_NV_shader_framebuffer_fetch exists since 2006.
Tegra ist, nicht viel anderes als eine Geforce7800, natuerlich fuer mobile gepimpt, aber die GPU architecture sollte == sein.
in die ROPs sowas wie Pixelshader 1.3 einzubauen sollte eigentlich ok sein, sind ja nur 32pipelines und PS 1.3 (natuerlich mit float) sollte 'ok' sein.es in shader einzubauen klingt aber natuerlich noch cooler + aufwendiger, da man dann die shader am frontend und nicht erst am backend serialisieren mueste (sprich, fuer keinen pixel gibt es mehr als ein shader der gerade laeuft).
-
rapso schrieb:
dot schrieb:
rapso schrieb:
dot schrieb:
MSDN schrieb:
Atomic functions which implement interlocked operations are allowed on int and uint elements in an RWStructuredBuffer.
ok, ich schiebe das auf die docu
Ja, die HLSL Doku entspricht leider bei weitem nicht dem für die MSDN sonst üblichen Standard...
frueher war die DirectX docu eigentlich weit ueber dem msdn standard, also bis ca DirectX9
Ja, ich hoffe dass die Direct3D 11 Doku mit der Zeit besser wird, die Direct3D 9 Doku war in der Tat extrem gut...
rapso schrieb:
es in shader einzubauen klingt aber natuerlich noch cooler + aufwendiger, da man dann die shader am frontend und nicht erst am backend serialisieren mueste (sprich, fuer keinen pixel gibt es mehr als ein shader der gerade laeuft).
Aber verliert man dadurch nicht zu einem Großen Grad an Parallelität?
-
dot schrieb:
rapso schrieb:
es in shader einzubauen klingt aber natuerlich noch cooler + aufwendiger, da man dann die shader am frontend und nicht erst am backend serialisieren mueste (sprich, fuer keinen pixel gibt es mehr als ein shader der gerade laeuft).
Aber verliert man dadurch nicht zu einem Großen Grad an Parallelität?
falls es ueberlappungen gibt, dann ja, aus diesem grund wuerde ich programmable ROPs auch bevorzugen, die arbeiten immer garantiert in der richtigen reihenfolge und ohne race (weil es pro Pixel garantiert nur eine ROP pipeline gibt).
aber die alternative ist halt dass es garnicht geht.programmable blending sollte ohne speed drop gehen, fuer die meisten faelle wo man es braucht, z.b. deferred decals in den gbuffer blenden, der ein format hat das nicht kompatibel ist zu den paar blendmodes die es gibt (z.b. weil ein channel normalized sein sollte, oder weil du 4bit specular power und 4bit specular intensity im alpha ablegst).
du kannst das decal als ein quad zeichnen, garantierst also dass nichts ueberlappt.
