PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : [Shader]: Intel Grafik Media 950


pajofego
2006-10-21, 00:05:33
Hallo miteinander,

ich bin dabei mir ein Notebook zu kaufen (ja mir ist klar das in Hardwarefragen eigentlich das Hardwareforum zu konsultieren ist, aber ist dennoch eine Programmieraufgabe), mit Intels interner Grafikengine 950 http://www.intel.com/cd/personal/computing/emea/deu/216821.htm

Da steht doch tatsächlich das Ding soll Pixelshader 2.0 können:


Hardwarebeschleunigungsfunktionen von Microsoft* DirectX* 9:
Pixel Shader 2.0


Ist das ein schlechter Witz oder können heute die internen Grafik Chips auch schon PS 2.0? Ich ging immer davon aus, dass die nichts können. :confused:

Hat einer von euch schon mal ein ps 2.0 Shader auf so einer Hardware compiliert? Würde das Teil beim compilieren mit cgc.exe die compiler profile options -fp20 -vs20 respektive p_s_2_0 und vs_2_0 schlucken und entsprechendes DirectX bzw. OpenGL Programm laufen?

Danke,

Gruß

pajofego

Android
2006-10-21, 01:36:27
Hallo miteinander,

ich bin dabei mir ein Notebook zu kaufen (ja mir ist klar das in Hardwarefragen eigentlich das Hardwareforum zu konsultieren ist, aber ist dennoch eine Programmieraufgabe), mit Intels interner Grafikengine 950 http://www.intel.com/cd/personal/computing/emea/deu/216821.htm

Da steht doch tatsächlich das Ding soll Pixelshader 2.0 können:



Ist das ein schlechter Witz oder können heute die internen Grafik Chips auch schon PS 2.0? Ich ging immer davon aus, dass die nichts können. :confused:

Hat einer von euch schon mal ein ps 2.0 Shader auf so einer Hardware compiliert? Würde das Teil beim compilieren mit cgc.exe die compiler profile options -fp20 -vs20 respektive p_s_2_0 und vs_2_0 schlucken und entsprechendes DirectX bzw. OpenGL Programm laufen?

Danke,

Gruß

pajofego

Also PS2.0 ist kein Witz. VS3.0 halt nur über Software.
Der Kompilierung sollte eigentlich nichts im Weg stehen.
Noch interessanter ist übrigens der G965 Chipsatz.

Mfg
Android

Ganon
2006-10-21, 07:20:29
Jup. Können sie. Ansonsten wären sie nicht CoreImage Kompatibel in OS X.

VooDoo7mx
2006-10-21, 09:41:36
Der GMA 950 kann nicht Vertexshader 2.0.
Er kann auch nicht Vertexshader 1.1. Er hat nicht einmal eine Hardware TnL Einheit.

Und das besste ist, der Treiber lässt diese Aufgaben nicht einmal von CPU übernehmen.

Gast
2006-10-21, 11:00:01
Wenn die App nicht alzu dämlich ist, dann fordert sie dann einfach Software-Vertexprocessing an und gut is.

Ich versteh schon gar nicht warum Direct3D da son Aufstand drum macht. Es wäre völlig einfach gewesen einen automatischen Fallback dafür einzubauen, anstatt das den Entwickler abfragen zu lassen und dann das entsprechende Cap zu setzen.

pajofego
2006-10-21, 12:51:47
Also PS2.0 ist kein Witz. VS3.0 halt nur über Software.
Der Kompilierung sollte eigentlich nichts im Weg stehen.
Noch interessanter ist übrigens der G965 Chipsatz.

Mfg
Android

Interessant...ps2.0 sollte mir erst einmal reichen. Ist nur eine Lösung wenn ich Unterwegs mal was machen will, ansonsten steht ja die Höllenmaschine zu Hause. Die lässt sich halt schlech im Zug aufstellen. Danke

Gruß

pajofego

Gast
2006-10-21, 13:16:54
Must aber mal schauen wie es mit den OpenGL-Extensions aussieht. Intel hat immer sehr schlechte Treiber was das angeht...

TheGamer
2006-10-21, 14:33:39
Der GMA 950 kann nicht Vertexshader 2.0.
Er kann auch nicht Vertexshader 1.1. Er hat nicht einmal eine Hardware TnL Einheit.

Und das besste ist, der Treiber lässt diese Aufgaben nicht einmal von CPU übernehmen.


Doch ird von der CPU übernommen. Habs probiert vor ein paar Monaten auf einem Mac Mini auf dem Windows lief. Eine kleine D3D9 app erstellt welche es vorarusgesetzt hat das VS verwendet werden ansonsten hätte ich nciht das sehen können was die App dan gezeigt hat. Es lief ohn Probleme bis auf die Performance eben

Gast
2006-10-21, 14:41:39
Der Treiber hat keine Hardware-T&L-Emulation wie der von ATi oder nVIDIA. Wenn die App also Hardware anfordert dann wird sie nicht laufen.

TheGamer
2006-10-21, 14:49:48
Der Treiber hat keine Hardware-T&L-Emulation wie der von ATi oder nVIDIA. Wenn die App also Hardware anfordert dann wird sie nicht laufen.

Es läuft aber wie oben geschrieben bzw. kann man dies alles noch an anderen Orten nachlesen

Gast
2006-10-21, 15:12:17
Es läuft aber wie oben geschrieben bzw. kann man dies alles noch an anderen Orten nachlesen

Nein es läuft nicht. "Die Sims" hatte das Problem z.B. das es HW vertex processing anfordert und deshalb auf GMA900 nicht lief.

TheGamer
2006-10-21, 15:21:03
Nein es läuft nicht. "Die Sims" hatte das Problem z.B. das es HW vertex processing anfordert und deshalb auf GMA900 nicht lief.

Dann liegts an Sims aber nicht an Treibern oder hardware. Ich habs selbst getestet wie man oben unschwer überlesen kann

Coda
2006-10-21, 15:36:02
Das ist insofern ein "Treiberproblem", das der Treiber eben kein HW T&L emuliert und dir D3D nen Error um die Ohren knallt wenn du Direct3DCreate9 mit D3DCREATE_HARDWARE_VERTEXPROCESSING aufrufst.

Kannst du auch gerne hier in der Liste schauen: http://zp.amsnet.pl/cdragan/d3dcaps.html

Ja, Vertexshader laufen, aber nur wenn die App den Fallback auf Software selbstständig durchführt. Der Treiber oder Direct3D machen das nicht.

TheGamer
2006-10-21, 15:44:38
Das ist insofern ein "Treiberproblem", das der Treiber eben kein HW T&L emuliert und dir D3D nen Error um die Ohren knallt wenn du Direct3DCreate9 mit D3DCREATE_HARDWARE_VERTEXPROCESSING aufrufst.

Kannst du auch gerne hier in der Liste schauen: http://zp.amsnet.pl/cdragan/d3dcaps.html

Ja, Vertexshader laufen, aber nur wenn die App den Fallback auf Software selbstständig durchführt. Der Treiber oder Direct3D machen das nicht.

Richtig ich habe AUTO Fallback in der App. Je nachdem was mir die hardware bietet entscheide ich

Jetzt merk ich erst das der Gast was anderes meint bzw. doch das gleiche. Dann hat Sims eben kin AUTO Fallback und Sims ist schuld das es nicht läuft

Coda
2006-10-21, 15:47:59
Sagte der Gast doch X-D
Der Treiber hat keine Hardware-T&L-Emulation wie der von ATi oder nVIDIA. Wenn die App also Hardware anfordert dann wird sie nicht laufen.

Lesen -> Posten...

pajofego
2006-10-23, 00:08:34
Must aber mal schauen wie es mit den OpenGL-Extensions aussieht. Intel hat immer sehr schlechte Treiber was das angeht...

Das wäre wiederum schade. Versuche mich gerade von DirectX auf OpenGL selbst umzuschulen. Wo ich die OpenGL extensions von nVidia finde ist kein Problem, aber wo finde ich die von Intel?

Danke

Gruß

pajofego

pajofego
2006-11-17, 19:34:57
Hallo Leute,

wo finde ich denn die OpenGL Extensions für diese mobile Grafikkarte? Habt ihr da ein Tipp für mich?

Danke,

Gruß

pajofego

Neomi
2006-11-17, 20:56:27
Der Treiber hat keine Hardware-T&L-Emulation wie der von ATi oder nVIDIA. Wenn die App also Hardware anfordert dann wird sie nicht laufen.

Wenn die Applikation Hardware-Vertexprocessing anfordert, warum sollte die Hardware dann emuliert werden dürfen? Dafür gibt es Software- bzw. Mixed-Vertexprocessing. Im Mischbetrieb sollte die Hardware das erledigen, was sie kann und der Rest per Software emuliert werden. Wird Hardware explizit angefordert, dann hält der Treiber sich dran, darin sehe ich kein "kann er nicht".

Coda
2006-11-17, 21:31:12
Wenn die Applikation Hardware-Vertexprocessing anfordert, warum sollte die Hardware dann emuliert werden dürfen?

Weil er es kann und manche Programmierer einfach zu doof sind und nur Hardware-Vertexprocessing anfordern.

Neomi
2006-11-17, 21:58:01
Weil er es kann und manche Programmierer einfach zu doof sind und nur Hardware-Vertexprocessing anfordern.

Wer ein D3D-Device erstellen kann, kann schonmal gar nicht zu doof dazu sein. Software-Vertexprocessing ist selbst auf den derzeit schnellsten Systemen ohne Vertexshader so lahm, daß es sich einfach nicht lohnt, auch nur eine Codezeile dafür zu verschwenden. Für Entwicklung unterwegs ist das ja noch akzeptabel, aber für Spiele einfach nicht relevant.

Alles unter VS 2.0 und PS 2.0 ist die Mühe nicht mehr wert, auch wenn es theoretisch ginge.

MikeB
2006-11-17, 22:52:24
Weil er es kann und manche Programmierer einfach zu doof sind und nur Hardware-Vertexprocessing anfordern.

Hallo ?

Schonmal was von "Transform on demand" gehört ? Kann nur Hardware...
Wenn die Daten nicht Speicherverschwenderisch angelegt sind, taugt das Softwareprocessing nicht viel, resultiert schnell in FPS < 5. Kommt nicht so doll wenn bei jeden DrawIndexedPrimitive() der komplette Vertexbuffer transformiert wird.
Es ist einfach unpraktisch alle Daten schön Häppchenweise vorzuportionieren damit auch ja nicht-HW-T&L fähige Hardware klar kommt, die sowieso schon viel zu langsam ist um mit 80MPS zu jonglieren...
Hätte im Fall meiner letzten Titel zu doppelt so grossen Vertexbuffern geführt, und das nur damit Krüppel-Hardware auch funktioniert/ruckelt ? Dann doch gleich lieber ganz den Dienst verweigern und sicher gehen, dass M$ nicht doch auf die Idee kommt etwas per CPU zu transformieren.

Die Praxis ist leider doch ein bisschen komplexer wie die Theorie...

Michael

Coda
2006-11-17, 23:00:33
Hm okay, ich hab mich damit ehrlich gesagt auch noch nicht rumschlagen müssen :D

Ich dachte nur es sei so einfach weil es unter OpenGL ja auch keine Unterscheidung gibt.

MikeB
2006-11-18, 00:14:00
Möglich wär die Anpassung schon, aber wozu ? Nur damit die Krüppel auch was darstellen können ?
Beim DrawIndexedPrimitive() gibt man einen minindex und maxindex an, dieser Bereich wird bei software processing transformiert.
Wenn man die Vertices passend clont, kann man dafür sorgen, dass kein einziger Vertex umsonst transformiert wird, aber das Clonen kostest Videoram.

Hardware hingegen transformiert immer nur dann einen Vertex, wenn er noch nicht im Vertexcache steht und das Trianglesetup ihn aber benötigt. Das ist das "Transform on demand". So dürfen die Indices ein bischen im Vertexbuffer rumspringen.

Michael

Coda
2006-11-18, 00:26:17
Huh? Bist du sicher, dass das Software-Vertexprocessing nicht auch einen Post-Transform-Cache hat für indizierte Vertexdaten? :|

Ich mein ist durchaus möglich, ich hab mich wie gesagt nicht damit beschäftigt.

Neomi
2006-11-18, 02:51:37
Huh? Bist du sicher, dass das Software-Vertexprocessing nicht auch einen Post-Transform-Cache hat für indizierte Vertexdaten? :|

Hängt natürlich von der Implementierung ab, aber beim letzten Test mit Intel-Grafik war es noch die lahme Lösung. Einmal die komplette Range transformieren und dann erst die Indizes durchnudeln...

MikeB
2006-11-18, 11:12:11
Ich bin mit dem Software-Vertexprocessing nicht im Detail vertraut. Ich hab die Erfahrung gemacht, das Software-Vertexprocessing nur halbwegs performant laeuft, wenn die Daten ordentlich aufbereitet sind und min-index und max-index passend dem DrawCall übergeben werden. Ich könnte mir vorstellen, dass es hier kein Cache gibt, da man ja sowieso alle Vertices pro DrawCall gruppieren muss.

Mit dem Hardware-Vertexprocessing bin ich zwangsläufig im Detail vertraut, das war nötig um die Daten Cache-performant aufzubereiten. Im xbox-sdk war das sehr detailliert beschrieben und Nvidia sehr kooperativ.
Die Vorgehensweise der Hardware ist in Software unmöglich nachzubilden. (Zumindest nicht in Realtime)

Michael