Intel bringt PowerVR-Chip in Atom-Chipsatz - Poulsbo - GMA500

[Corny]

Der Chipsatz für die neue Centrilo Atom Plattform enthält nicht den üblichen Intel GMA Grafikchip sondern einen von PowerVR:

http://www.heise.de/newsticker/IDF-Atom-Mobilplattform-mit-PowerVR-statt-Intel-Grafik--/meldung/105940

[MadManniMan]

Oh endlich wieder ein PC-Einsatz von PowerVR IP =) Wenn es auch im Endeffekt Intel ist, haben wir wieder einen kaufbaren Ansatz eines ernstzunehmenden Entwicklers. Freut mich!

[Exxtreme]

Da "freue" ich mich schon auf die Treiber von Intel ...

[Corny]

Da "freue" ich mich schon auf die Treiber von Intel ...

Wielange man wohl auf alle Features warten muss?
Vielleicht fängt Intel da aber auch gleich vernünftig an.

Die Linux Treiber waren bisher ja immer schon vergleichsweise geht. Die müssen ja auch neu geschrieben werden. Hoffe das die nicht schlechter werden, da Linux ja auf vielen Centrino Atom Rechnern laufen wird.

[AnarchX]

Liefert die Treiber nicht IMGTec?
Und imo liegt das Problem bei den GMAs doch auch meist im HW-Design, was den Treiberentwickler vor zusätzliche Probleme stellt.:D

Leistungswerte gibt es übrigens auch schon:
Poulsbo Graphics (SGX535):
3DMark03: 500
3DMark05: 150
http://forum.beyond3d.com/showthread.php?t=46999

;)

[Gast]

Da "freue" ich mich schon auf die Treiber von Intel ...

Die Treiber kommen garantiert nicht von Intel.

reunion

[Coda]

Da "freue" ich mich schon auf die Treiber von Intel ...
Die Treiber kommen sehr wahrscheinlich von PowerVR.

[Gast]

wenns ne IGP integrierte lösung ist, wird die treibersuite von intel sein, die core bestandteile jedoch von IMGtec

[Coda]

Nein wird sie nicht. ImgTec liefert mit der IP immer einen kompletten Treiber mit. Es ergibt absolut keinen Sinn, dass Intel da selber was schreibt, weil sie die Hardware auch nicht kennen.

[Spasstiger]

Kann der PowerVR SGX nicht auch D3D10.1? Bei Heise steht nur was von Shader Model 3.

[MadManniMan]

AFAIK ist der SGX gar über SM4.1 - nur was eben genutzt wird, ist besonders bei Intel ne andere Frage ;)

[Gast]

Bei Imgtec steht aber auch nur was von Shader 3.0.

[Spasstiger]

Bei Imgtec steht aber auch nur was von Shader 3.0.
Da sind die Specs, die vor mehr als einem halben Jahr zum SGX veröffentlicht wurden:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=5800125#post5800125

http://img297.imageshack.us/img297/2791/sgxdx10ue1.jpg

Aber es scheint wohl so, dass Intel sich mit SM3 zufrieden gibt. Haben wohl keine Lust darauf, auch für DX10 Support leisten zu müssen.

[Die gelbe Eule]

Kommt das Teil den wirklich in einen Desktop? Atom Varianten sollten auch im mobilen Sektor Einzug halten, Subnotebooks und Smartphones eingeschlossen.

[Xmas]

Es gibt verschiedene SGX-Varianten.

[Spasstiger]

Kommt das Teil den wirklich in einen Desktop? Atom Varianten sollten auch im mobilen Sektor Einzug halten, Subnotebooks und Smartphones eingeschlossen.
Asus will den EEE PC auch auf Atom-Basis rausbringen und bringt in Kürze auch einen Desktop-EEE-PC auf den Markt: http://www.gameswelt.de/news/30184-Asus_Eee-PC_Desktop.html.
Vielleicht steckt da ja schon ein Atom drin.

[Die gelbe Eule]

Wenn man weiterdenkt, dann ist wohl der Onboard Sektor mit PowerVR in Zukunft ausgestattet und das normale Intelteam kann sich dann auf den Desktop Part konzentrieren. Wenn man nur Kyro2 Leistung mit DX10 Features bringen würde, dann ist man ja schneller als die GMA Derivate.

[Corny]

Wenn man weiterdenkt, dann ist wohl der Onboard Sektor mit PowerVR in Zukunft ausgestattet und das normale Intelteam kann sich dann auf den Desktop Part konzentrieren. Wenn man nur Kyro2 Leistung mit DX10 Features bringen würde, dann ist man ja schneller als die GMA Derivate.

Die oben abgegeben 3DMark Werte sehen aber nicht rosig aus. Keine Ahnung was ne Kyro2 dort an Leistung bringt, bzw in etwa bringen würde sofern DX9 unterstützen würde. Aber die aktuellen GMA Chips sind da wesentlich schneller.
Aber stellt sich auch die Frage mit wie die Atom CPU in 3D Angelegenheiten läuft. Vielleicht bremst die recht stark aus.

[Ailuros]

Bei Imgtec steht aber auch nur was von Shader 3.0.

Musst Dich zwar einloggen, aber bei IMGTEC steht genau drin was je nach Modell unterstuetzt wird:

http://www.imgtec.com/powervr/insider/powervr-login.asp?Factsheet=SGX

Hat ueberhaupt D3D10.x procedural geometry?

Wenn man weiterdenkt, dann ist wohl der Onboard Sektor mit PowerVR in Zukunft ausgestattet und das normale Intelteam kann sich dann auf den Desktop Part konzentrieren. Wenn man nur Kyro2 Leistung mit DX10 Features bringen würde, dann ist man ja schneller als die GMA Derivate.

Selbst high end MBX (233MHz) ist heutzutage schneller als KYRO2. SGX ist nicht nur ein USC mit MIMD Einheiten, sondern hat auch doppelt so hohe (fast) trilineare als MBX oder KYRO2.

Ich bezweifle dass es fuer SGX555 schon einen Lizenznehmer gab, aber das Ding schafft bei nur schaebigen 20,3mm^2@65nm an die 4.0 GPixels/s Fuellrate und 100M Polys/s bei weniger als 50% shader load. Die 4.0 GPixel sind zwar mit 2.5x overdraw ausgerechnet, aber 1.6GPixels sind immerhin 4.6x mal mehr Fuellrate als KYRO2, das Ding hat IMHLO durch die fast-tri TMUs fast kostenloses AF und unterstuetzt natuerlich auch programmierbares Multisampling.

Das Zeug in Intel's ATOM wird wohl um einiges bescheidener sein, aber auf KYRO2 Niveau ist es wohl schon wenn man die Flexibilitaet eines USC und die fehlende Geometrie-Einheit einer K2 mitberechnet. Schon MBX ist eigentlich eine KYRO3 in Kleinformat. Der optionale VGP/Geometrie-Prozessor ist ja >VS1.1.

Die oben abgegeben 3DMark Werte sehen aber nicht rosig aus. Keine Ahnung was ne Kyro2 dort an Leistung bringt, bzw in etwa bringen würde sofern DX9 unterstützen würde. Aber die aktuellen GMA Chips sind da wesentlich schneller.
Aber stellt sich auch die Frage mit wie die Atom CPU in 3D Angelegenheiten läuft. Vielleicht bremst die recht stark aus.

Wen schert denn ueberhaupt 3DSch*nzMark auf so kleinen Geraeten? 3dmark05 & 06 laufen garantiert nicht vollstaendig auf KYRO2 wenn ueberhaupt. INTEL interessiert es hauptsaechlich fuer die groesseren UMPCs den Vista Siegel draufkleben zu koennen und warum auch nicht SM4.1. Ich hab zwar keine Ahnung welches Modell hier gemessen wurde, aber SGX555 ist es garantiert nicht und ich bezweifle auch dass es SGX545. Die Groessen von SGX525 bis zu 555 liegen zwischen 2 und 20.3mm^2. Wie sieht es aus wenn nach Schaetzung die die-Groesse bei =/<10mm^2 liegen koennte fuer die 500 3dmark03 Punkte?

[robbitop]

Äh? Alt und so? Wundert mich, dass das als News tituliert worden ist. Ich meine das schon seit Monaten oder länger immer mal wieder auf B3D oder hier gelesen zu haben.

[stickedy]

Aber haben wir nicht alle drauf gewartet, dass es endlich bestätigt wird? Nachdem sogar mal davon ausgegangen wurde, dass das was im G965 steckt hätte PowerVR sein können... ;)

[Ailuros]

Äh? Alt und so? Wundert mich, dass das als News tituliert worden ist. Ich meine das schon seit Monaten oder länger immer mal wieder auf B3D oder hier gelesen zu haben.

Frueher oder spaeter haette es Intel schon angekuendigt. Da die IMG Aktie in letzter Zeit eine konstante fallende Tendenz hat, hat die offizielle Ankuendigung geholfen dass es etwas wieder bergauf geht.

Solches Zeug:

http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/03-10-2008/0004770435&EDATE=
http://www.oki.com/en/press/2008/03/z07159e.html

....half da nicht besonders, obwohl ziemlich grosses Potential in so einem Markt liegt.

MBX macht ja jetzt erst anscheinend das wirklich fette Geld wo es u.a. auch so langsam losgeht mit digital TV, mobile TV, GPS und weiss der Geier was noch fuer andere Anwendungsgebiete.

Das hier war wohl doch Apple: http://www.imgtec.com/News/Release/index.asp?NewsID=676

Obwohl ich immmer noch irgendwo hoffe dass es Sony ist.

[=Floi=]

aber besser wäre es einfach, wenn intel ihre eigene igp verbauen würde. Einheitliche hardware und einheitliche treiber.

[AnarchX]

Ich sehe kein Problem darin, dass Intel den Imgtec-Code in ihr Treiberpaket integriert.
Und SGX der wohl deutlich energieeffizienter als ein GMA9xx ist, sollte man doch klar bevorzugen.

[robbitop@work]

Ich hoffe auch auf einen SGX545 (mehr frisst vermutlich zu viel Energie) in der PSP2. Aber angeblich hat NVIDIA ja den Deal. Ich gehe davon aus, dass SGX derzeit die beste Performance pro mm^2 bietet. Aber wann gewinnt schonmal das bessere Produkt den Zuschlag? ;)

[AnarchX]

@robbitop
Ohne genaue Daten über die GPU in APX2500, die du wohl meinst, kann man doch eher schlecht erahnen, wer nun das bessere Produkt hat.

[robbitop@work]

@robbitop
Ohne genaue Daten über die GPU in APX2500, die du wohl meinst, kann man doch eher schlecht erahnen, wer nun das bessere Produkt hat.
Der APX2500 ist ein spezifischer ASIC, der neben der mGPU noch andere SoC Elemente enthällt.
Ein TBDR erlaubt gerade in einer Umgebung mit beschränkten Ressourcen (Transistorbudget, Bandbreite, Leistungsufnahme) einige Vorteile.
Ein TBDR spart nicht nur einen großteil der Berechnungen durch komplette Eliminierung des Overdraws, er spart auch noch enorm an Bandbreite, da sämtliche Zugriffe auf ein Framebuffer-Tile im Tilecache stattfinden. Selbst das Downsampling dürfte Onchip laufen. Statt zig Framebufferzugriffen sind es dadurch nur noch sehr wenige.
Hinzukommt, dass PowerVR in diesem Markt die meisten Erfahrungen haben dürfte.

[Corny]

Der APX2500 ist ein spezifischer ASIC, der neben der mGPU noch andere SoC Elemente enthällt.
Ein TBDR erlaubt gerade in einer Umgebung mit beschränkten Ressourcen (Transistorbudget, Bandbreite, Leistungsufnahme) einige Vorteile.
Ein TBDR spart nicht nur einen großteil der Berechnungen durch komplette Eliminierung des Overdraws, er spart auch noch enorm an Bandbreite, da sämtliche Zugriffe auf ein Framebuffer-Tile im Tilecache stattfinden. Selbst das Downsampling dürfte Onchip laufen. Statt zig Framebufferzugriffen sind es dadurch nur noch sehr wenige.
Hinzukommt, dass PowerVR in diesem Markt die meisten Erfahrungen haben dürfte.

Aber haben nicht andere Hersteller (ATI, nVidia usw...) auch Techniken mit denen sie das rendern von nicht sichtbaren Teilen unterbinden?
Hab mich damit noch nicht so beschäftigt :redface:

[robbitop@work]

Aber haben nicht andere Hersteller (ATI, nVidia usw...) auch Techniken mit denen sie das rendern von nicht sichtbaren Teilen unterbinden?
Hab mich damit noch nicht so beschäftigt :redface:
Da der Rendervorgang nicht sortiert geschieht sondern quasi zufällig, kann ein IMR unmöglich jeden Overdraw beseitigen (Ausnahme: First-Z Pass, aber der kostet auch wieder Rechenzeit). Somit passiert, dass bsw erst Objekte mit hohem Z-Wert gerendert werden und kurz darauf kommt dann eines mit niedrigerem. Dann wird ersteres überschrieben. Läuft es andersherum, braucht das zweite nicht gerendert werden. Und die Reihenfolge ist eben zufällig. Also hat man vieleicht nur in 50% der Overdrawfälle die möglichkeit, diesen zu beseitigen.

Ein TBDR macht erstmal ein Triangle-Binning. Vor dem eigentlichen Rendern werden also sämtliche Dreiecke des Bildes sortiert und indiziert. Da das ein hoher Rechen und Cachingaufwand ist, wird das Tile für Tile erledigt. Ist das Binning für ein Tile fertig, erfolgt die Rasterizierung mittels Trisetup und dann erfolgt IIRC ein Z-Pass des Tiles (das liegt ja im Tile-Cache) bei dem sämtlicher Overdraw eliminiert wird. Das geht unheimlich fix, weil der Tile-Cache ja ein Cache und kein externer Speicher ist und man am Tilecache verdammt viele Z/Stencilunits hat (schon Kyro2 hatte 32 Stück). Und erst am Ende der Kette erfolgt der eigentliche Renderpass. Wenn das Tile fertig gerendert (inkl eventuellem Downsampling) wurde, wird es erst in den Framebuffer geschrieben.

IMRs schreiben und lesen ständig vom Framebuffer, weil damit gearbeitet werden muss. Das kostet natürlich hammer viel mehr Bandbreite und auch Latenzen, sofern sie nicht eh versteckt werden können.

[Gast]

Und die Reihenfolge ist eben zufällig. Also hat man vieleicht nur in 50% der Overdrawfälle die möglichkeit, diesen zu beseitigen.


naja, eine halbwegs ordentliche engine sollte nicht unbedingt zufällig rendern. damit erreicht man zwar immer noch nicht die effizient eines DR aber deutlich mehr als 50% der fälle sollte man schon aussortieren können.






IMRs schreiben und lesen ständig vom Framebuffer, weil damit gearbeitet werden muss. Das kostet natürlich hammer viel mehr Bandbreite und auch Latenzen, sofern sie nicht eh versteckt werden können.

heutzutage kann man das meiste in einem pass rendern, deshalb müssen auch IMRs nicht ständig aus dem framebuffer lesen. natürlich ich auch hier ein DR effizienter, aber bei weitem nicht so extrem.

[Corny]

Da der Rendervorgang nicht sortiert geschieht sondern quasi zufällig, kann ein IMR unmöglich jeden Overdraw beseitigen (Ausnahme: First-Z Pass, aber der kostet auch wieder Rechenzeit). Somit passiert, dass bsw erst Objekte mit hohem Z-Wert gerendert werden und kurz darauf kommt dann eines mit niedrigerem. Dann wird ersteres überschrieben. Läuft es andersherum, braucht das zweite nicht gerendert werden. Und die Reihenfolge ist eben zufällig. Also hat man vieleicht nur in 50% der Overdrawfälle die möglichkeit, diesen zu beseitigen.

Ein TBDR macht erstmal ein Triangle-Binning. Vor dem eigentlichen Rendern werden also sämtliche Dreiecke des Bildes sortiert und indiziert. Da das ein hoher Rechen und Cachingaufwand ist, wird das Tile für Tile erledigt. Ist das Binning für ein Tile fertig, erfolgt die Rasterizierung mittels Trisetup und dann erfolgt IIRC ein Z-Pass des Tiles (das liegt ja im Tile-Cache) bei dem sämtlicher Overdraw eliminiert wird. Das geht unheimlich fix, weil der Tile-Cache ja ein Cache und kein externer Speicher ist und man am Tilecache verdammt viele Z/Stencilunits hat (schon Kyro2 hatte 32 Stück). Und erst am Ende der Kette erfolgt der eigentliche Renderpass. Wenn das Tile fertig gerendert (inkl eventuellem Downsampling) wurde, wird es erst in den Framebuffer geschrieben.

IMRs schreiben und lesen ständig vom Framebuffer, weil damit gearbeitet werden muss. Das kostet natürlich hammer viel mehr Bandbreite und auch Latenzen, sofern sie nicht eh versteckt werden können.

Wow, danke für die verständliche Erklärung!
Ein TBDR ist also quasi DER grafikchip für kleine und sparsame Rechner? Aber wo hat der TLB seine Grenzen? Es muss ja einen Grund geben warum dieser kaum eingesetzt wird.
Das das Konzept nicht weiter angewendet wird hat mich ja nach dem Erfolg der Kyro schon gewundert.

[Gast]

Das das Konzept nicht weiter angewendet wird hat mich ja nach dem Erfolg der Kyro schon gewundert.

kyro war in erster linie deshalb so erfolgreich, weil die damaligen konkurrenzprodukte extrem ineffizient waren. die heutigen GPUs rechnen aber auch schon so ziemlich effizient, da ist es dann die frage ob sich ein TBDR noch auszahlt, die ganzen caches usw. gibt es ja auch nicht umsonst.

[robbitop]

naja, eine halbwegs ordentliche engine sollte nicht unbedingt zufällig rendern. damit erreicht man zwar immer noch nicht die effizient eines DR aber deutlich mehr als 50% der fälle sollte man schon aussortieren können.
Eine Engine kann kein HSR machen. Man kann Portale und Antiportale setzen.


heutzutage kann man das meiste in einem pass rendern, deshalb müssen auch IMRs nicht ständig aus dem framebuffer lesen. natürlich ich auch hier ein DR effizienter, aber bei weitem nicht so extrem.
Das ist zwar richtig, aber da es Overdraw gibt, muss desöfteren darauf zugegriffen werden. Zum Downsampling dann nochmal. Wenn dem nicht so wäre, würde der Z-Output so extrem lächerlich überdimensioniert, dass er nie und nimmer einen Flaschenhals darstellen würde.
Ich denke, was du ausdrücken willst, ist dass es nicht mehr so extrem wie früher ist. Aber es ist dennoch nicht zu vernachlässigen oder herunter zu spielen.

[robbitop]

Wow, danke für die verständliche Erklärung!
Ein TLB ist also quasi DER grafikchip für kleine und sparsame Rechner? Aber wo hat der TLB seine Grenzen? Es muss ja einen Grund geben warum dieser kaum eingesetzt wird.
Das das Konzept nicht weiter angewendet wird hat mich ja nach dem Erfolg der Kyro schon gewundert.
Ein TBDR hat auch Nachteile, wie zum Beispiel ständige Texturwechsel. Da trasht man dann mal eben den Texturecache und die Pipes drehen Däumchen, bis die geforderten Texturdaten da sind. Viele Texturwechsel sind dann nicht mehr so gut voraussagbar, wie es beim IMR der Fall ist.
Weiterhin kostet die Logik für's Binning und den Tilecache natürlich auch nochmal Transistoren. Auch ist die Bandbreite in diskreten GPUs heute auch nicht mehr so kritisch, wie es früher war. Auch, wie mein Vorredner schon betonte, können die IMRs heute mehr als früher und auch die Balance hat sich ein wenig verschoben.

Ein weiterer Grund ist, dass ein TBDR schon im Grundansatz dermaßen anders funktioniert, dass man viel Know How wegschmeißen kann, sofern man umsteigen wollte und bei vielen Teilen der Entwicklung nicht mehr auf Vorgänger zurückgreifen kann. Das erzeugt Entwicklungskosten, Risiken und möglicherweise eine temporär höhere Time-to-Market.
Gerade der recht margenschwache Markt der GPUs ist recht gefährlich. Nur wenige Fehler führen zu Verlusten von Marktanteilen. Die Folgen sieht man an Beispielen wie AMD/ATI, 3dfx, NVIDIA (NV30 Zeit) und mindestens 10 IHVs aus den 90er Jahren.

Ein TBDR ist, wie du siehst, nicht unbedingt der Königsweg und auch nicht der heilige Graal. Es ist ein interessantes Konzept und es hat in gewissen Bereichen unabstreitbare Stärken.
Ich denke in günstigen Konsolen und Handheldspielgeräten wäre ein TBDR die bessere Wahl. Bei diskreten Grafikkarten wäre das Konzept gewiß konkurrenzfähig aber IMRs sind das dort auch.

[Gast]

Wow, danke für die verständliche Erklärung!
Ein TLB ist also quasi DER grafikchip für kleine und sparsame Rechner? Aber wo hat der TLB seine Grenzen? Es muss ja einen Grund geben warum dieser kaum eingesetzt wird.
Das das Konzept nicht weiter angewendet wird hat mich ja nach dem Erfolg der Kyro schon gewundert.TLB kommt aus dem CPU-Bereich. Wir reden hier aber über TBDRs (Tile Based Deferred Renderer).
Die seltene Nutzung kann ich mir nur als Konsequenz des Patentsystems erklären. PowerVR dürfte so ziemlich jede Zugangsmöglichkeit zu TBDR-Techniken mit einem breiten Gürtel aus Patentminen abgesichert haben, d.h. du kannst entweder überhaupt keinen TBDR bauen oder zumindest keinen guten, ohne deren Patente zu verletzen. Innerhalb des bestehenden Patentsystems nur logisch und jeder wäre bekloppt, der diese Möglichkeiten nicht ausnutzt. Im Endeffekt bedeutet es aber, dass man TBDRs effektiv nur von IMGTec bekommen kann, während es unter den IMRs noch so was ähnliches wie einen Markt gibt.
Es gibt auch noch andere bereits angesprochene Aspekte zu berücksichtigen, aber das Patentsystem halte ich für eine weit entscheidendere Hürde als die anderen.

[=Floi=]

es ist ein unterschied ob intel hier eigene technik verbaut, oder nur fremde integriert. Ich bin eben ein freund EINER architektur und vielen produkten die auf dieser aufbauen
(siehe ati oder nv aktuell)
damit bekomme ich auf auf einen schlag sehr guten treibersupport und das ist auch sehr sehr viel wert!

optimiert hier intel eigentlich auch mal die igpu, oder setzen die einfach nur auf einen neuen fertigungsprozess in kleineren strukturen? Intel gibt hier IMMER an 45nm oder 32nm und da wird dann alles besser... :rolleyes:

[Gast]

Eine Engine kann kein HSR machen. Man kann Portale und Antiportale setzen.

prinzipiell könnte die engine natürlich HSR machen, ob es sinnvoll ist steht natürlich auf einem anderen blatt. was die engine aber durchaus wissen kann ist die reihenfolge in der die polygone gerendert werden und diese zumindest halbwegs F2B rendern und damit den overdraw auf der grafikkarte deutlich reduzieren. sicherlich niemals zu 100% aber durchaus deutlich über jenen 50% die man bei rein zufälligem rendern hätte.

portale/antiportale haben wieder eine gänzlich andere aufgabe, diese verhindern dass unsichtbare polygone erst garnicht zur grafikkarte geschickt werden.

[davidzo]

naja, lizenzen von imgtec sind nicht gerade teuer. manche große firmen kaufen welche im vorraus ohne sie dann wirklich zu nutzen. auch intel hat die lizenz zu mehreren sgx derivaten schon seit dieser herauskam gekauft und hätte sie besser nutzen können.
ich denke es wird auch möglich sein recht günstig eine Lizenz zu kaufen um selber TBDRs konstruieren zu dürfen.

[robbitop]

TLB kommt aus dem CPU-Bereich. Wir reden hier aber über TBDRs (Tile Based Deferred Renderer).
Die seltene Nutzung kann ich mir nur als Konsequenz des Patentsystems erklären. PowerVR dürfte so ziemlich jede Zugangsmöglichkeit zu TBDR-Techniken mit einem breiten Gürtel aus Patentminen abgesichert haben, d.h. du kannst entweder überhaupt keinen TBDR bauen oder zumindest keinen guten, ohne deren Patente zu verletzen. Innerhalb des bestehenden Patentsystems nur logisch und jeder wäre bekloppt, der diese Möglichkeiten nicht ausnutzt. Im Endeffekt bedeutet es aber, dass man TBDRs effektiv nur von IMGTec bekommen kann, während es unter den IMRs noch so was ähnliches wie einen Markt gibt.
Es gibt auch noch andere bereits angesprochene Aspekte zu berücksichtigen, aber das Patentsystem halte ich für eine weit entscheidendere Hürde als die anderen.
Ich möchte meine Hand zwar dafür nicht in's Feuer legen aber das glaube ich kaum. Sonst könnte man ja auch keinen IMR mehr bauen. Selbst XGI, S3 und Trident konnten das noch. Umschiffbar wäre das bestimmt.
Gigapixel und Real3D haben auf TBDRs gebaut. NVIDIA hällt ja noch Patente von ersterem.

[robbitop]

prinzipiell könnte die engine natürlich HSR machen, ob es sinnvoll ist steht natürlich auf einem anderen blatt. was die engine aber durchaus wissen kann ist die reihenfolge in der die polygone gerendert werden und diese zumindest halbwegs F2B rendern und damit den overdraw auf der grafikkarte deutlich reduzieren. sicherlich niemals zu 100% aber durchaus deutlich über jenen 50% die man bei rein zufälligem rendern hätte.
Nach meinem Verständnis geht das kaum bis gar nicht.

portale/antiportale haben wieder eine gänzlich andere aufgabe, diese verhindern dass unsichtbare polygone erst garnicht zur grafikkarte geschickt werden.
Richtig. Das ist manuelles HSR.

[Gast]

Ich möchte meine Hand zwar dafür nicht in's Feuer legen aber das glaube ich kaum. Sonst könnte man ja auch keinen IMR mehr bauen. Selbst XGI, S3 und Trident konnten das noch. Umschiffbar wäre das bestimmt.Das TBDR-Konzept hat IMHO mehr kritische Stellen, die kaum anders effizient umgesetzt werden können. Der Bau eines TBDRs dürfte noch möglich sein, nicht jedoch in einer ähnlichen Leistungs- bzw. Flächeneffizienz.
Gigapixel und Real3D haben auf TBDRs gebaut. NVIDIA hällt ja noch Patente von ersterem.Dass man Patente hält, welche die Umsetzung eines Konzepts ermöglichen, bedeutet noch lange nicht, dass man dieses Konzept auch effizient umsetzen kann, ohne Patente anderer zu verletzen. IMGTec hat einen gewaltigen Vorsprung, schon mal rein von der technischen Erfahrung her. Vor allem aber handeln sie mit IP, haben also eigentlich Patent- und Lizenzrecht als Hauptgeschäftsfeld. Also wenn die es nicht draufhaben, rechtliche Fallgruben anzulegen, wer dann bitteschön sonst?

[Coda]

Nach meinem Verständnis geht das kaum bis gar nicht.
Dann solltest du dich da nochmal schlau machen :)

Jede moderne Engine sortiert die Szene grob von vorne nach hinten, das heißt nicht nach einzelne Polygone sondern nach Szenegraph-Nodes. Man kann einen Szenegraph sehr effizient in eine bestimmte Richtung traversen.

Wenn der Player z.B. in einer Szenegraph-Node steht die einen Raum enhält der keine Fenster hat, dann wird nachdem diese Node als erstes gerendert wurde zumindest auf ATI-Karten (Hier-Z) sofort jedes Polygon dahinter verworfen. Und zwar so effizient dass dann der Vertex Shader oder das Triangle Setup limitiert.

Die neuen NVIDIA-Karten haben jetzt auch ein Verfahren dass ähnlich funktioniert (lustigerweise erst ab G84). Irgendwie haben sie wohl die Hier-Z-Patente umschifft. Davor haben die Karten aber ineffizienter auch schon Polygone verwerfen können.

[robbitop]

@Coda

Danke für das gut erklärte Update! :) Ist immer gut, dass wir hier sogar Entwickler da haben.

S3 hatte seit Columbia auch Hier-Z. Offensichtlich haben sie es auch anders umgesetzt.

[Ailuros]

Ich möchte meine Hand zwar dafür nicht in's Feuer legen aber das glaube ich kaum. Sonst könnte man ja auch keinen IMR mehr bauen. Selbst XGI, S3 und Trident konnten das noch. Umschiffbar wäre das bestimmt.
Gigapixel und Real3D haben auf TBDRs gebaut. NVIDIA hällt ja noch Patente von ersterem.

Um es mal anders anzupacken (aber verdammt vereinfacht): ein heutiger IMR verzoegert auch und ein heutiger TBDR wuerde IMHO auch nie alles verzoegern. Gigapixel sowohl wie heute Mali/Falanx sind IMO eher quasi early-Z DRs (und ja tiling wird auch benutzt) aber nicht ein "traditioneller" TBDR so wie der PowerVR.

So wie es auch gute IMRs (GeForce, Radeon z.B.) gibt, gab es auch beschissene IMRs wie Volari. Ich sehe nicht ein wieso hier was anderes gelten sollte. Wenn PowerVR schon 5 Technologie-Generationen hinter sich hat, haben sie durch die Jahre so viel von dem Zeug patentiert und haben so viel Erfahrung damit gesammelt dass ein zweiter TBDR zwar moeglich waere, aber jeglicher Versuch darf jegliche Patente nicht verletzen und sollte auch zumindest genauso effizient sein, damit es Sinn macht.

Gigapixel hatte den GP-LP in IP Form fertig als 3dfx Gigapixel aufkaufte und natuerlich haette NVIDIA diesen auch so verkaufen koennen, denn ihr erster PDA/mobile chip war trotz allem zum erbrechen schwach und eher fuer multimedia Schnickschnack optimiert:

http://users.otenet.gr/~ailuros/GPLP.pdf

I asked if the Giga3D core could do ray-casting like Imagination Technologies’ PowerVR. “No,” Henry Choy, GigaPixel’s Director of Marketing, answered, “we don’t do ray casting like the PowerVR. We can support things like bump mapping and shadows like other traditional 3D architectures. Our architecture has a traditional rendering pipeline after the visibility sub-system.
The biggest difference is all the manipulation of pixels occurs on chip (lower bandwidth). There is no need for going off chip to write out intermediate results.”

http://users.otenet.gr/~ailuros/gp-1.pdf

Ihr letztes Tier war GP3:

http://users.otenet.gr/~ailuros/gp-3.pdf

....und die wertvollsten Ideen des Mo-Bus hat wohl NV doch im Laufe der Zeit effektiv ausgeschlachtet. Der crossbar memory controller erschien wann genau auf GeForce?

[Captain Future]

Wie groß müssen denn die Tile-Caches bei einem TBDR sein, wenn man die DX10.1-Spec erfüllen will und trotzdem alles on-chip behalten? Ich meine, das sind tausende von Instruktionen, die alle auch Texturen mit Alpha-Blending sein können, dazu kommt 4x MSAA (vervierfacht den TC, IIRC) und natürlich noch MRT mit 8 Targets.

IMO müsste das Ding schon allein einen riesigen Cache haben, um das alles abfangen zu können. Ist das noch wirtschaftlich?

[robbitop]

Texturen halten die Tilecaches ja nicht sondern lediglich die Buffer. Und dabei nichtmal Color und Z gleichzeitg. Und auch nur für ein einziges 32x32 Pixeltile.
32 x 32 x 4 byte x 4 Buffer x 8 Targets = 128 kiB. Das dürften rund 6 Mio Transistoren bedeuten bei 6 Zellen pro Transistor.
Beim SGX dürfte der Tilecache kleiner sein.

@Ail

Die GP Chips sind schon echte TBDRs. Sogar der GMA ist das. Bei all diesen gibt's Tilecaches, Triangle Binning und am Tilecache angebundene Z/Stencilunits.
Richtig effizient hat das bisher nur PVR präsentiert, das stimmt wohl.

[Captain Future]

Und diese Binning-Engine? Die muss ja auch etliche tausend Einträge verarbeiten können.

[robbitop]

Und diese Binning-Engine? Die muss ja auch etliche tausend Einträge verarbeiten können.
Das passiert aber nacheinander. ;)
Du hast aber schon Recht: das kostet. Aber ich gehe davon aus, dass es das wert ist.

[Ailuros]

@Ail

Die GP Chips sind schon echte TBDRs. Sogar der GMA ist das. Bei all diesen gibt's Tilecaches, Triangle Binning und am Tilecache angebundene Z/Stencilunits.
Richtig effizient hat das bisher nur PVR präsentiert, das stimmt wohl.

Ist hab kein Problem die Dinger TBDRs zu nennen. Es geht stets darum dass es schwer klingt die Effizienz des PowerVR zu erreichen ohne IMG's Patente zu verletzen um darum geht's.

Ausserdem klingen auch heute noch ihre Angaben genauso laecherlich wie damals. 25.8 GTexels/s bei 200MHz fuer GP3?

Texturen halten die Tilecaches ja nicht sondern lediglich die Buffer. Und dabei nichtmal Color und Z gleichzeitg. Und auch nur für ein einziges 32x32 Pixeltile.
32 x 32 x 4 byte x 4 Buffer x 8 Targets = 128 kiB. Das dürften rund 6 Mio Transistoren bedeuten bei 6 Zellen pro Transistor.
Beim SGX dürfte der Tilecache kleiner sein.

Wieso 32*32?

[robbitop]

32x32 war IIRC die Tilesize vom Series5, der nicht erschienend ist.

[Ailuros]

Nicht direkt relevant:

http://forum.beyond3d.com/showpost.php?p=1106829&postcount=14

[Ailuros]

32x32 war IIRC die Tilesize vom Series5, der nicht erschienend ist.

Sagt wer?

[davidzo]

Richtig. Das ist manuelles HSR.

Naja, Portale sollten eigentlich vom Kompilerer automatisch in die Szene gesetzt werden. ich denke das ist eher halbautomatisch, wirkliche handarbeit ist da in der Regel nicht nötig, aber ein wenig vorzeitiger rechenaufwand.

[Coda]

Kann mir eigentlich mal einer erklären wie es die PowerVR-Chips schaffen an alle Polygone zu kommen die in ein Tile gehören? Dazu müssten sie ja zuerst alle Polygone einer Szene transformieren und das können ja beliebig viele sein.

Das hab ich nie verstanden.

Naja, Portale sollten eigentlich vom Kompilerer automatisch in die Szene gesetzt werden. ich denke das ist eher halbautomatisch, wirkliche handarbeit ist da in der Regel nicht nötig, aber ein wenig vorzeitiger rechenaufwand.
Das macht man eigentlich nicht mehr weil man precomputed PVS abgeschafft hat (das letzte Mal wurde das bei Q3 verwendet) und für online culling sind die automatisch gesetzten Portale zu viel und zu schlecht. Da wäre so viel manuelle Nacharbeit nötig dass man sie gleich von Hand setzen kann.

Die UE3 verwendet Hardware-Occlusion-Queries und verzögert diese um ein Frame, wodurch es auch manchmal Artefakte gibt weil in der Szene etwas eigentlich sichtbar ist im vorherigen Frame aber noch nicht war.

[robbitop]

Kann mir eigentlich mal einer erklären wie es die PowerVR-Chips schaffen an alle Polygone zu kommen die in ein Tile gehören? Dazu müssten sie ja zuerst alle Polygone einer Szene transformieren und das können ja beliebig viele sein.

Das hab ich nie verstanden.
Wenn es zuviele Dreiecke werden, bremst eben auch das Triangle Binning den ganzen nachgelagerten Prozess. Das ist allerdings entsprechend großzügig ausgelegt. Keine Ahnung, ob man mit dem Kyro 2 mal Spiele zu Gesicht bekam, deren Geometrie so aufwändig zu indizieren war, dass das Binning das Rendering ausbremst. Erwähnt wurde diese Möglichkeit u.A. damals auf 3DConcept.
Ich bin mir aber nicht sicher, ob er das Binning immer nur pro Tile macht. dadurch muss man natürlich Dreiecke mehrfach indizieren, die auf mehreren Tiles sind. Dafür bräuchte man aber auch einen kleineren Cache. Keine Ahnung, wie speicherintensiv die ganzen Indizes sind. Was sagst du als Entwickler?

[Coda]

Wenn es zuviele Dreiecke werden, bremst eben auch das Triangle Binning den ganzen nachgelagerten Prozess.
Ja, das is ja klar. Aber ich meine jetzt ob die PowerVRs wirklich erstmal alles Transformieren. Weil dann bräuchten sie viel mehr Speicher und Bandbreite für die Vertexdaten.

Aber anders kann ich's mir nicht vorstellen. Man kann ja nich mehrere Megabyte an Vertexdaten auf dem Chip cachen.

[Gmax]

Geile News, hoffentlich wirds ein Erfolg. Ich verstehe nur nicht, warum Intel diesen Larabee Kram macht, anstatt gleich auf PowerVR für den Desktop zu setzen :naughty:

[Ailuros]

Ja, das is ja klar. Aber ich meine jetzt ob die PowerVRs wirklich erstmal alles Transformieren. Weil dann bräuchten sie viel mehr Speicher und Bandbreite für die Vertexdaten.

Aber anders kann ich's mir nicht vorstellen. Man kann ja nich mehrere Megabyte an Vertexdaten auf dem Chip cachen.

Direkte Antworten bekam ich auf derartige Fragen nie, nur ein paar verstreute hints ueber Parameter-Management, Komprimierungs-Techniken, bounding volumes, Macro-/Micro-tiling oder weiss der Geier was noch aber nie etwas konkretes.

Aus einem der aelteren Interviews:

What do you believe are the key benefits of a unified shading architecture, and further are there any specific advantages of it for a tile based deferred rendering architecture?

The benefits of a universal shader which combines vertex and pixel shading is primarily one of load balancing - irrespective of the scene or whether there is more vertex shading or more pixel shading to be done, the universal shader can ensure the best throughput is obtained in all cases. This combines best in the tile based renderer because the vertex shading and pixel shading steps are entirely decoupled leading to an improvement in the traditional benefits of low bandwidth and low power of the tile based renderer.

Ich wundere mich auch heute noch wo genau hier der Vorteil sein soll und natuerlich nur unter der Perspektive ob sich die jeweiligen Vor-und Nachteile beim Bandbreiten-Verbrauch fuer Geometrie irgendwie ausbalancieren.

Von dem abgesehen SGX hat neben den quasi MIMD Einheiten noch einen weiteren wichtigen Vorteil:

Compiler quality is essential in PC space so much that companies go as far as replacing shaders with hand optimised versions. How is this going to impact the mobile market, where driver size must be small and CPU power is limited?

The quality of the code compilers generate is indeed very important, in the same way as they are in the PC space and as you rightly say, footprint, compile time and available CPU are also key. We have many years of compiler experience and as a result PowerVR SGX has been designed to be very compiler friendly, ensuring that the compiler can generate optimal code with the minimum effort.

[Ailuros]

Geile News, hoffentlich wirds ein Erfolg. Ich verstehe nur nicht, warum Intel diesen Larabee Kram macht, anstatt gleich auf PowerVR für den Desktop zu setzen :naughty:

N.I.H. (not invented here) :P

Spass beiseite, es dauert wohl eine Weile bis Intel Larabee fuer Kleinkram einsetzen kann in der Zukunft. Es wird sich dann zeigen ob Intel tatsaechlich immer noch 3rd party IP braucht, oder ihr eigener Mist gut genug sein kann.

[AnarchX]

Nun hat man ein Poulsbo basierendes Netbook mal einem Review unterzogen, speziell auch dem SGX:
http://img50.imageshack.us/img50/1421/kohjinshasc33dmarkdetaiua9.jpg
http://img246.imageshack.us/img246/1879/kohjnshasc3d3dvillagematr5.jpg
http://www.pocketables.net/2008/07/review-kohjinsh.html

Doch etwas seltsam dass die MT-Fill unter der ST-Fill liegt? :|

[Ronny145]

Der Eee 901 macht 641 Punkte im 3dmark03, hat aber auch mehr CPU Takt. Die hätten auch mal den Verbrauch messen können.

[AnarchX]

Der Eee 901 macht 641 Punkte im 3dmark03, hat aber auch mehr CPU Takt. Die hätten auch mal den Verbrauch messen können.

Im EEE901 ist doch kein Poulsbo, sondern ein GMA950-Ableger?

[stickedy]

Vor allem, dass Villagemark so wenig fps hat. Also auf dem Niveau einer Kyro hätte ich die Lösung nun schon erwartet. Aber das ist ja mehr als deutlich unter einer Kyro oder gar Kyro II!

[Ronny145]

Im EEE901 ist doch kein Poulsbo, sondern ein GMA950-Ableger?


Ich weiß, es war nur als Vergleich gedacht zur besseren Einordnung. Intel GMA 500 ist nun der PowerVR Chip oder was ist jetzt so besonders dran?

[AnarchX]

Ich weiß, es war nur als Vergleich gedacht zur besseren Einordnung.
Zum Verbrauch gibt es ja auch paar Daten:
Kohjinsha has given the SC3's standard li-ion battery (7.4V, 2600mAh) a runtime estimate of 3.2 hours, but my usage (Wi-Fi and Bluetooth on, GPS off, screen at mid-brightness, web browsing with Firefox 3) returns about 2.5 hours. Unimpressive.

Also ca. 20Wh Akku-Kapazität, macht bei 2.5h 8W Verbrauch.

Soviel höher liegt der Eee doch auch nicht wieder oder liege ich da falsch?

[Ronny145]

Soviel höher liegt der Eee doch auch nicht wieder oder liege ich da falsch?


Nicht viel wenn ich mir die c't Ergebnisse so anschaue. Im Akkubetrieb je nach Last 7,5 bis 11,5 Watt. Aber das Gerät auf der letzten Seite hat 2 GB RAM und eine herkömmliche 60 GB HDD. Auch wenn das nur wenig ausmacht, bei den Dimensionen von um die 10 Watt fällt das schon ins Gewicht. Ob man die so direkt vergleichen kann weiß ich nicht.

[robbitop]

Ich komme auf rund 7,6 W Leistungsaufnahme. Vermutlich ein wenig weniger, weil ein Akku ja nicht mit 100 % Wirkungsgrad entläd.
Wenn man bedenkt, dass dort 2 GiB RAM und eine 2,5" HDD drinsteckt, ist das schon sehr gut!
Immerhin hat er mit WLAN und Firefox 3 gesurft, was heutzutage ja schon ziemlich rechenintensiv ist. Mit meinem Thinkpad X60 (mit undervolteter CPU) komme ich nie unter 12-13 W bei diesen Settings.
Mit SSD wäre noch weniger Leistungsaufnahme drin.

Was ich nur nicht verstehe ist die erstaunlich geringe Leistung des GMA500. Das Teil ist eine SGX535 mit 2x universal scalable shader engines. Dazu gehörten AFAIK 2x TMUs. Das sollte doch in wenigstens 400 MTex Füllrate oder mehr münden.

[loewe]

Was ich nur nicht verstehe ist die erstaunlich geringe Leistung des GMA500. Das Teil ist eine SGX535 mit 2x universal scalable shader engines. Dazu gehörten AFAIK 2x TMUs. Das sollte doch in wenigstens 400 MTex Füllrate oder mehr münden.

Der GMA500 läuft hier noch mit sehr schwachen Treibern. AFAIK wird OGL im Moment gar nicht oder so gut wie gar nicht in Hardware unterstützt und D3D läuft mit angezogener Handbremse.

Bzgl. D3D wandelt Vista alle fixed Function Aufrufe in flaot Shader um, dabei werden wohl die 8bit Festkomme-Zahlen in 32bit Fließkomme konvertiert und das ist für den kleinen SGX zu heftig. Sicher kann SGX mit flaot Formaten umgehen, aber für gute Geschwindigkeit ist ein dem Problem angepasstes Format besser.

So ähnlich soll das sein, hier sind sicher ein paar Leute die das noch genauer erklären können. :)
Der Treiber muss diesen Quatsch unterdrücken, was er bisher noch nicht kann.

Ich erwarte von diesem kleinen SGX auch Werte leicht über denen der KYRO II in den alten Benchmarks, wenn es dann mal ordentliche Treiber geben wird. ;)

[robbitop@work]

sowas habe ich schon fast vermutet, danke Loewe! ;)

[mekakic]

Hat das Gerät eigentlich irgendeine Videobeschleunigung?
Ich möcht emit den Dell Inspiron Mini 12 (http://www1.euro.dell.com/content/products/productdetails.aspx/laptop-inspiron-12?c=de&l=de&s=dhs&cs=dedhs1&~oid=de~de~80854~feb_laptop_inspiron_12_n02m1202~~) holen. Mit der Atom CPU wird wahrscheinlich bei Video nicht allzuviel gehen. Kann der GMA500 da irgendwie helfen? Kann jemand beurteilen "wieviel" Video da gehen wird?

[loewe]

Hat das Gerät eigentlich irgendeine Videobeschleunigung?
Ich möcht emit den Dell Inspiron Mini 12 (http://www1.euro.dell.com/content/products/productdetails.aspx/laptop-inspiron-12?c=de&l=de&s=dhs&cs=dedhs1&~oid=de~de~80854~feb_laptop_inspiron_12_n02m1202~~) holen. Mit der Atom CPU wird wahrscheinlich bei Video nicht allzuviel gehen. Kann der GMA500 da irgendwie helfen? Kann jemand beurteilen "wieviel" Video da gehen wird?

Da sollte eine ganz Menge gehen!
http://www.mitrax.de/?cont=artikel&aid=35&page=10

[mekakic]

Das wäre ja absolut genial und wie ich das sehe auch dann so ziemlich das einzige Netbook mit soetwas wie HD Videobeschleunigung, oder?

[AnarchX]

Das wäre ja absolut genial und wie ich das sehe auch dann so ziemlich das einzige Netbook mit soetwas wie HD Videobeschleunigung, oder?
Es gibt noch das ASUS N10J mit dedizierter, abschaltbarer GeForce9:
http://geizhals.at/deutschland/a381917.html

Bei dem von loewe verlinkten Artikel wird aber AFAIK der Treiber von IMGTec verwendet, der öffentliche Intel-Treiber könnte da wohl etwas eingeschränkter sein.

[mekakic]

Ist der IMGTec Treiber auch "öffentlich"?

[stickedy]

Ist der IMGTec Treiber auch "öffentlich"?
Leider anscheinend nicht. Unverständlicherweise kocht Intel da sein eigenes, sehr schlechtes Süppchen...

Ansonsten bietet das Samsung NC20 mit VIA Nano und VIA VX800 IGP ebenfalls eine vernünftige HD-Video-Beschleunigung: "1080p (oben) und 720p (unten) laufen problemlos, super fluessig und mit recht wenig CPU Load." (http://www.netbooknews.de/1224/samsung-nc20-im-test-gute-performance-akku-ok/2/)

[Shink]

Keine Ahnung, es wurde hier im Thread allerdings schon mal erwähnt dass er jedenfalls nicht mit dem GMA500 funktioniert.

Also ich hätte da meine Skrupel tolle Hardware zu kaufen bei der ja anscheinend nur der Treiber schlecht ist. Dafür war ich wahrscheinlich zu lange an S3, SiS und XGI-Produkten interessiert.

Wenn du HD-Beschleunigung willst würde ich mit dem Kauf eines GMA500-Notebooks warten bis sie tatsächlich nutzbar ist.

Ist zwar OT aber mit dem zum Dell Inspiron Mini 12 ähnlichen Samsung NC20 sollten 1080p-Videos jetzt schon flüssig abspielbar sein laut den Russen: http://translate.google.com/translate?prev=hp&hl=en&u=http%3A%2F%2Fgagadget.com%2Fmobile_pc%2F2009-01-26-promezhutochnyi_variant_obzor_12-dyuimovogo_netbuka_samsung_nc20&sl=auto&tl=en

[stickedy]

Wahrscheinlich hat Intel einfach Bedenken, dass der GMA500/PowerVR-Grafikkern ihre gesamte IGP-Serie nass macht und bis auf die Knochen blamiert wenn sie ihm nen vernünftigen Treiber verpassen würden :D

[mekakic]

Bestellt ist er schon. Ich habe mich nach loewe's posting sehr gefreut, daß das Gerät für HD Videowiedergabe tauglich ist. Wenn das jetzt an Treibern scheitert, wäre das in der Tat sehr ärgerlich... das müßte man eigentlich alle etwas nerven (Intel, Dell, ImgTec); auch wenn es wohl nichts bringt.

[Shink]

@stickedy:

Das werden wir vielleicht nie erfahren (auch wenn ichs nicht glaube; soviel Rohleistung hat das Teil dann auch wieder nicht).

[Ailuros]

@stickedy:

Das werden wir vielleicht nie erfahren (auch wenn ichs nicht glaube; soviel Rohleistung hat das Teil dann auch wieder nicht).

Ich will hoffen dass sich bei Intel endlich etwas bewegt; bei denen geht ja sowieso alles im Schneckentemp egal ob sie die Treiber selber schreiben oder ob Tungsten diese ausliefert.

Von dem abgesehen einen reinen IGP mit einem SoC mit Grafikkern zu vergleichen waere sowieso etwas unfair, da beim zweiten zwei Idioten (CPU und GPU) um die gleiche Bandbreite kaempfen muessen.

[Gast]

http://www.notebookcheck.net/Intel-Graphics-Media-Accelerator-500-GMA-500.12614.0.html
DirectX 10.1 und Shader 4.1?

Leider wurde vga gekillt... dafür hdmi!
http://www.qvc.com/qic/qvcapp.aspx/app.detail/params.item.E06938

[Xmas]

DirectX 10.1 und Shader 4.1?
Die Angabe stimmt nicht.

[mekakic]

@stickedy:

Das werden wir vielleicht nie erfahren (auch wenn ichs nicht glaube; soviel Rohleistung hat das Teil dann auch wieder nicht).
Für den GMA500 soll es einen neuen Treiber geben:
http://www.netbooknews.de/6709/gma-500-zeigt-durch-neuen-treiber-ihre-wahre-leistung/

Auf das der wirklich deutlich besser wird *hoff*

[AnarchX]

Für den GMA500 soll es einen neuen Treiber geben:
http://www.netbooknews.de/6709/gma-500-zeigt-durch-neuen-treiber-ihre-wahre-leistung/

Auf das der wirklich deutlich besser wird *hoff*
Das scheint wohl seit den letzen Releases besser geworden zu sein:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7377962#post7377962
... funktionierende HD-Beschleunigung über DXVA.

Fragt sich nur warum Intel das "verheimlicht". ;)

[mekakic]

Interessant.

[FelixPaul]

Kurze Frage, läuft DXVA2 (worüber ich alle Formate abspielen kann) eigentlich mit Windows XP?

[stickedy]

Meines Wissens nein

[FelixPaul]

Grad eben ist was spannendes passiert ;) Ihr kennt doch sicher die Seite www.netbooknews.de ? Dies ist der populärste Blog wenn es um entsprechende Geräte geht und ist eigentlich auch immer sehr aktuell. Leider werden Netbooks mit Z-Atom (bzw. GMA500) immer wieder hart kritisiert, durch die Autoren aber auch in den Kommentaren. Ich war einfach mal so frei einen Erfahrungsbericht über meinen Acer 751 in dessen Forum zu posten: http://forum.eeepcnews.de/viewtopic.php?f=1&t=7661

Habe ich damit etwas falsch gemacht? Anscheinend schon ;) Soeben bekam ich Post, vom Netbooknews.de Chefredakteur/Inhaber 'Sascha Pallenberg'.

http://img191.imageshack.us/img191/6122/netbooknews1.jpg

Immerhin hat er sich die Mühe gemacht und raus gefunden das ich Student an der Uni Paderborn bin. (Felix Wiegers) Wer möchte darf mich gerne gruscheln ;) Über die Art und Weise, wie mit Lesern umgegangen wird darf sich jeder anhand des Screenshot selber ein Urteil bilden.

FRAGE: Die Blogs attestieren dem Geräten mit Z-Atom (GMA500) schlechte Performance und mangelnde Fähigkeiten bzgl. HD-Wiedergabe. Ich mache genau gegenteilige Erfahrungen indem ich schlicht einen (kostenlosen) Player verwende der die Hardware Decodierung des GMA500 unterstützt. Was habe ich als einfacher Kunde mit meinem Erfahrungsbericht falsch gemacht? Rede ich BullShit oder bin ich ein Troll?

Gruß,
Felix

[mekakic]

Finde ich eigenartig - hast Du außer dem einen Posting noch was anderes geschrieben? Immerhin hat die Seite doch selber über die verbesserten Intel Treiber berichtet. Beim Dell Inspiron Mini 12 mit dem meine Freundin rumturnt (und was von der deutschen Dell Seite irgendwie verschwunden ist) sitzt ja auch ein GMA500, hatte aber noch keine Zeit den Treiber da mal upzudaten. Der dort installierte hat definitiv einige Bugs - man kann z.B. keine Videoanwendung im Fenster laufen lassen - das ruckelt sich zu Tode, Vollbild ist dagegen kein Problem; egal welche Software und wie wenig anspruchsvoll das Video ist.

[FelixPaul]

Den Streit mit netbooknews.de möchte ich begraben, es gibt ja auch andere Plattformen wo man vernünftiger diskutieren kann. Ich bleib erstmal hier ;)

@mekakic: Deine Freundin nutzt doch bestimmt Vista auf ihrem Dell Mini 12? Dies ist der aktuellste Treiber der ja auch durch diverse News gegangen ist: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProductID=3001&DwnldID=16943&strOSs=All&OSFullName=All

Der macht vieles besser. So kann ich auf meinem Gerät jetzt sämtliche HD-Formate abspielen und sogar ein paar ältere 3D-Spiele (Quake 3, Warcraft 3 usw.) spielen. Ich denke viel mehr kann man von so einem Netbook nicht erwarten?

Evtl. interessant, da die Netbooks mit GMA500 ja genau das gleiche können, nur ist es wohl noch nirgends angekommen. http://blog.laptopmag.com/video-ion-powered-lenovo-s12-looks-great-but-not-coming-until-fall


Gruß,
Felix

[Ronny145]

Habe ich damit etwas falsch gemacht? Anscheinend schon ;) Soeben bekam ich Post, vom Netbooknews.de Chefredakteur/Inhaber 'Sascha Pallenberg'.

http://img191.imageshack.us/img191/6122/netbooknews1.jpg

Immerhin hat er sich die Mühe gemacht und raus gefunden das ich Student an der Uni Paderborn bin. (Felix Wiegers) Wer möchte darf mich gerne gruscheln ;) Über die Art und Weise, wie mit Lesern umgegangen wird darf sich jeder anhand des Screenshot selber ein Urteil bilden.

FRAGE: Die Blogs attestieren dem Geräten mit Z-Atom (GMA500) schlechte Performance und mangelnde Fähigkeiten bzgl. HD-Wiedergabe. Ich mache genau gegenteilige Erfahrungen indem ich schlicht einen (kostenlosen) Player verwende der die Hardware Decodierung des GMA500 unterstützt. Was habe ich als einfacher Kunde mit meinem Erfahrungsbericht falsch gemacht? Rede ich BullShit oder bin ich ein Troll?

Gruß,
Felix


Ja dieser Sascha Pallenberg tickt so. Kritik ist da ein Fremdwort, kann er gar nicht leiden. So wird man schnell zum Troll, sein Lieblingswort. Hab ich selber schon bemerkt und sieht man auch an vielen unverschämten Kommentaren dort. Der letzte Kommentar (http://www.netbooknews.de/6874/bilderserie-hands-on-mit-dem-msi-wind-u200/) dort ist pfui.

[FelixPaul]

Danke Ronny, das du das ausgegraben hast ;) Ja, der Kommentar ging an mich, später folgte halt die E-Mail.

Die Sache ist ja so, ich hab mir diesen Acer 751 gekauft und er verhält sich bei mir völlig anders als in der Presse/Szene beschrieben und kritisiert wird. Wenn ich über meine persönlichen Erfahrungen schreibe ist doch nichts falsches?

Jetzt aber wieder On-Topic:

Habe mir zum Spass heute mal zwei Demos runtergeladen, Quake 3 läuft 1A (35 fps) und Warcraft 3 ist spielbar aber könnte besser sein. Was nutzen die Games eigentlich, OpenGL, D3D?

YouTube-Videos laufen auf Vista/Win7 im HQ-Modul sehr gut, lediglich HD ist nicht zu gebrauchen. Auf XP soll dies zwar schon gut laufen, kann ich allerdings grad nicht testen :(

Apple scheint hier weiter zu sein. Ihr kennt doch sicher die Apple Trailer Seite? Während ich hier schreibe, ziehe ich mir grad ein paar neue HD-Trailer rein, was ja auf Grund der schwachen Hardware nicht gehen dürfte. Schon garnicht bei 9 offenen Browser-Tabs bei nur 1GB Ram. Bei mir sieht das allerdings so aus: http://img44.imageshack.us/img44/4488/appletrailer1.jpg

Das die Wiedergabe absolut Top ist (dank PowerVR Unterstüzung) dürfte man anhand der CPU Belastung erahnen können. Ich habe leider keine geeignete Kamera um das hier fest zu halten.

Mein Fazit für heute: Multitasking inkl. Stream-Videos ist selbst auf den schwächsten Rechnern machbar, sofern man seine vorhandenen Ressourcen intelligent nutzt. Mein Akku hält dabei noch 7 Stunden in der Uni durch, was will man mehr von einem 400€ Netbook?

Gruß,
Felix

[FelixPaul]

und so geht die Kritik halt weiter ;) diesmal ist der neue Asus dran: http://www.netbooknews.de/6984/asus-eee-pc-1101ha-nur-mit-133-ghz-atom-z520/

Für die Kunden bedeutet diese Entscheidung, dass die Wiedergabe von höher aufgelösten Videos auf dem Gerät wahrscheinlich kaum ordentlich möglich ist. Ähnline Probleme gibt es bereits beim Acer Aspire One 751, der ebenfalls mit einem 11,6-Zoll-Display und Intel Atom Z520 Prozessor daher kommt. Abgesehen von der wohl enttäuschenden Videoleistung dürfte der neue ASUS Eee PC 1101HA dennoch seine Freunde finden, schließlich bietet er ein durchaus attraktives Paket aus langer Laufzeit und reichlich Platz auf dem Bildschirm.

[Captain Future]

Ich denke, teilweise könnte ich es auch belegen, intel hat kein Interesse an besseren Treibern.
Sie haben einen Treiber entwickelt der stabil ist, so gut wie keine Grafikfehler hat und elementare 3D Funktionen unterstützt. Für Spiele sind die Geräte nicht gedacht und Video geht.
Bei ordentlicher Ausnutzung der Hardware wäre zwar ein mehrfaches an 3D Leistung drin, aber wofür der Aufwand, sagt sich intel!
Naja, zum Beispiel um Leute wie mich nicht dauerhaft abzuschrecken. Nach einer GMA900, die schreckliche Hardware mit unterirdischen Treibern gepaart hat, habe ich trotz bedenken doch noch aufgrund der guten Hardware zum GMA500 gegriffen - nicht wissend, dass Intel die Treiber so kaputtmacht, dass nichtmal elementare Dinge außerhalb des Aero-Desktops funktionieren.

Beispiele?
Divine Divinity ist in keiner Betriebsart (Software, D2D, D3D) spielbar - entweder furchtbar langsam oder katastrophale Bildfehler.

OpenGL ist ein komplettes No-Go. Doof für ältere Spiele, für die die 3D-Performance des GMA500 noch ausreichen würde.

Das anspruchslose Portal und das noch anspruchslosere Half-Life 1(!!) laufen im einstelligen Fps-Bereich in niedrigsten Einstellungen/Auflösung

Legale HD-Wiedergabe scheitert an fehlender HDCP-Kompa des Treibers (bei mir zumindest, den neuesten Treiber habe ich noch nicht probiert).


Schade, aber bisher: Epic Fail, Intel.

[FelixPaul]

3D mit dem GMA500 ist noch eine große Baustelle. Was loewe da allerdings sagt, beunruhigt mich ja doch etwas. Wollen die denn gar nichts in der Richtung tun?

@Cap.Future: schau doch mal hier vorbei: http://www.mydellmini.com/forum/gaming/9131-games-work-dell-mini-10-12-a.html

evtl. hilft dir das bei denen Spielen weiter und sag doch nochmal welche Netbook du hast und mit welchem OS/Treiber. Evtl. kann ich dir auch was helfen, und wenn es nur ein paar infos sind.

Gruß,
Felix

[Captain Future]

Servus Felix!

Danke - ich schau mir das mal an.
Ich hab ein Vaio P und das kam ab Werk mit Vista x86.

[=Floi=]

dafür ist es auch nicht geadcht. diese igp ist nur für office und dvd qualität. keine spiele kein ogl und kein dx. Selsbt wenn die leistung stimmen würde, wäre noch immer ein schlechter treiber (kompatibilität und features)
hier muß man ganz kleir zu nv oder ati greifen und wer spielen möchte, der sollte auch zu eine core 2 (oder turion x2) greifen!

[loewe]

dafür ist es auch nicht geadcht. diese igp ist nur für office und dvd qualität. keine spiele kein ogl und kein dx. Selsbt wenn die leistung stimmen würde, wäre noch immer ein schlechter treiber (kompatibilität und features)


Auch wenn Dein Beitrag schon ein paar Tage her ist, darauf muss ich noch antworten!

Nein, ich kann Dir da überhaupt nicht zustimmen!
Intel hat einen Chipsatz und eine CPU für kleine leichte Computer entwickelt. Diese Computer werden als Netbooks verkauft und sind als solche erst einmal kleine, leistungsschwache PCs, aber PCs und als solche universell. Es obliegt dem Nutzer was er damit tut, natürlich im Rahmen der Fähigkeiten des Gerätes.

Intel hat nun bewußt auf einen Grafikkern eines Fremdanbieters zurück gegriffen und sich dabei eben für SGX entschieden. Sie beschreiben den Grafikkern auch selbst als DVD fähig und DX9 kompilant.
Als Nutzer kann ich dann auch erwarten, dass sie diese Dinge im Rahmen der Fähigkeiten des Cores bieten.
Wir schreiben nicht mehr das Jahr 2000 wo man mit einem miniGL Treiber leben mußte und DX gerade erfunden wurde.

In der readme des 9.1.1 Treibers schreiben sie selbst "OpenGL 2.0 on all capable chipsets" und sie wissen das der SGX OGL 2.0 unterstützt. Sie liefern aber nach wie vor Microsfts OGL 1.1 Implementation.
Wenn ich einen Rechner kaufe, kann ich auch entsprechende Treiber erwarten und nicht Treiber, die die eine API überhaupt nicht unterstützen und ansonsten nur mit einem Bruchteil der möglichen Leistung laufen.
Das ist alles in allem eine Frechheit und Betrug am Kunden.

Ich verstehe aber imgtec genauso wenig.
Sicher haben sie Verträge, die intel die Entwicklung des Treibers auferlegen und sie bekommen kein Geld dafür, dort selbst etwas zu tun. Aber so tatenlos zu zusehen, wie ihr Ruf den Bach runter geht. :confused:

Wenn du dir einen Kleinwagen kaufst, kannst du doch auch erwarten das er im Rahmen seiner Möglichkeiten benutzbar ist. Oder würdest du es als normal ansehen, wenn der Wagen zwar einen Rückwärtsgang und fünf Vorwärtsgänge hätte, der Rückwärtsgang aber nicht ginge und ein schalten in einen Gang oberhalb des Zweiten nicht möglich wäre.
Das ist so etwa das was uns intel hier liefert und ich halte das nicht für in Ordnung.

[FelixPaul]

hallo loewe! den von dir angesprochenen IEGD Treiber habe ich gerade unter Windows XP im Einsatz. Allerdings nicht in version 9.1.1 sondern 10.1. wenn ich mir die openGL Fähigkeiten auflisten lasse, kommt dieses dabei herraus:


OpenGL Eigenschaften
Anbieter Tungsten Graphics, Inc.
Renderer Gallium 0.1, pipe/psb/Poulsbo on IEGD
Version 2.0 Mesa 7.1
Abtönungs Sprachversion 01. Okt
OpenGL DLL 5.1.2600.5512(xpsp.080413-0845)
ICD Treiber iegdglga.dll
Multitexture Texture Units 8
Occlusion Query Counter Bits 64
Sub-Pixel Precision 4 Bit
Max Viewport Size 4096 x 4096
Max Cube Map Texture Size 2048 x 2048
Max Rectangle Texture Size 2048 x 2048
Max 3D Texture Size 128 x 128 x 128
Max Anisotropy 16
Max Clipping Planes 6
Max Display-List Nesting Level 64
Max Draw Buffers 1
Max Evaluator Order 30
Max Light Sources 8
Max Pixel Map Table Size 256
Max Texture LOD Bias 4

OpenGL Befolgung
OpenGL 1.1 Ja (100%)
OpenGL 1.2 Ja (100%)
OpenGL 1.3 Ja (100%)
OpenGL 1.4 Ja (100%)
OpenGL 1.5 Ja (100%)
OpenGL 2.0 Ja (100%)
OpenGL 2.1 Nein (33%)
OpenGL 3.0 Nein (9%)
OpenGL 3.1 Nein (16%)


Konnte jetzt schon ein paar ältere OpenGL Spiele testen, die laufen wirklich wunderbar 70+FPS ;)

Gruß,
Felix

[Ailuros]

Bitte nicht schlagen aber die 2.1/3.0/3.1 Prozentuale sind sehr interessant ;)

[FelixPaul]

In der Tat ;) aber Everest spuckt mir das halt so aus. Seltsam ist, Spiele wie Quake3 laufen klasse, aber der OpenGL Benchmark z.B. von CrystalMark will nicht starten :frown: Was gibt es denn sonst an Benchmarks die ich mal testen könnte?

Gruß,
Felix

[loewe]

Lass mal den Archmark drüber laufen, bitte beide Einstellungen flush und swap! :)

http://www.zeckensack.de/archmark/index.html

Achso, fast vergessen und natürlich de VillageMark als D3D und OGL Version. Wäre auch im Vergleich mal ganz interessant. Eigentlich sollten beide gleich schnell sein und alles unter 100 FPS ist zu wenig. ;)

[Gast]

Bitte nicht schlagen aber die 2.1/3.0/3.1 Prozentuale sind sehr interessant ;)

Was, wenn man fragen darf?

[Ailuros]

Was, wenn man fragen darf?

Lediglich dass SGX545 diese Prozentuale zu 100% bringen koennte und wieviel genau einem SM3.0+ 535 bis zur vollen Komplianz fehlt ;)

[FelixPaul]

@Loewe: gern doch, habs gleich mal getestet. Hier die Ergebnisse des Archmark:

SWAP:
ArchMark 0.50
Driver: Gallium 0.1, pipe/psb/Poulsbo on IEGD v2.0 Mesa 7.1
1024x768 @ unknown refresh rate (assuming 85Hz)
Swapping buffers
Fillrate
32 bits
Mode: R8G8B8A8 Z24 S8
313.603 MPix/s color only
306.082 MPix/s z only
314.269 MPix/s color and z
264.011 MPix/s z tested (pass), color and z
279.146 MPix/s discardable by LEQUAL depth test
280.178 MPix/s discardable by GEQUAL depth test
280.243 MPix/s discardable by EQUAL depth test
307.042 MPix/s stencil writes
306.981 MPix/s discardable by EQUAL stencil test
stencil test passed
307.229 MPix/s pure stencil updates
304.668 MPix/s z fail (LEQUAL), stencil update
z test passed (LEQUAL)
307.464 MPix/s stencil update
306.342 MPix/s stencil update, z update
314.559 MPix/s color replace
314.221 MPix/s z update, color replace
313.643 MPix/s stencil update, color replace
314.045 MPix/s stencil update, z update, color replace
16 bits
Mode: R8G8B8A0 Z16 S0
329.363 MPix/s color only
325.071 MPix/s z only
331.326 MPix/s color and z
266.842 MPix/s z tested (pass), color and z
276.228 MPix/s discardable by LEQUAL depth test
280.601 MPix/s discardable by GEQUAL depth test
281.689 MPix/s discardable by EQUAL depth test
Bandwidth
Mode: R8G8B8A8 Z24 S8
available to buffer clears
630.058 MB/s all buffers
240.312 MB/s color only
273.058 MB/s depth and stencil
175.564 MB/s depth only
58.863 MB/s stencil only
2.247 GB/s worst case draw bandwidth
267.387 MB/s burned by the RAMDAC
2.514 GB/s estimated physical bandwidth
Geometry
Mode: R8G8B8A0 Z16 S0
Plain vertices
773.407 kTris/s as triangle fan
392.672 kTris/s as triangle list
326.527 kTris/s clipped
Vertex shading speed
388.790 kTris/s lit (one directional light)
387.348 kTris/s lit (one point light)
240.002 kTris/s lit (eight point lights)
Texturing
Mode: R8G8B8A0 Z16 S0
Textured fillrate
Bilinear filter
55.221 MPix/s w 1 layers
53.345 MPix/s w 2 layers
51.126 MPix/s w 3 layers
39.501 MPix/s w 4 layers
34.480 MPix/s w 5 layers
29.880 MPix/s w 6 layers
26.330 MPix/s w 7 layers
31.029 MPix/s w 8 layers
Trilinear filter
49.251 MPix/s w 1 layers
44.684 MPix/s w 2 layers
40.983 MPix/s w 3 layers
29.887 MPix/s w 4 layers
26.048 MPix/s w 5 layers
21.954 MPix/s w 6 layers
19.060 MPix/s w 7 layers
20.675 MPix/s w 8 layers
Readback
Mode: R8G8B8A8 Z24 S8
Whole buffer
8.612 MPix/s of R8G8B8A8 colors
3.042 MPix/s of B8G8R8A8 colors
9.278 MPix/s of R8G8B8 colors
3.407 MPix/s of B8G8R8 colors
6.572 MPix/s of depth data (unsigned integer)
7.927 MPix/s of depth data (float)
9.949 MPix/s of stencil
32x32 region
9.171 MPix/s as R8G8B8A8
2.264 MPix/s as B8G8R8A8
9.190 MPix/s as R8G8B8
2.438 MPix/s as B8G8R8
5.632 MPix/s of depth data (unsigned integer)
6.562 MPix/s of depth data (float)
8.832 MPix/s of stencil
Texture cache
Mode: R8G8B8A8 Z24 S8
8 kiB using RGBA textures(CSV)
Tiling
Mode: R8G8B8A8 Z24 S8
preferred block alignment
updating all buffers (CSV)
16 pixels wide
16 pixels high
in color buffer (CSV)
16 pixels wide
16 pixels high
in depth buffer (CSV)
8 pixels wide
none detected in y-direction
in stencil buffer (CSV)
none detected in x-direction
none detected in y-direction

FLUSH:
ArchMark 0.50
Driver: Gallium 0.1, pipe/psb/Poulsbo on IEGD v2.0 Mesa 7.1
Resolution: 1024x768 @ 201.15Hz
Flushing commands, no buffer swaps
Fillrate
32 bits
Mode: R8G8B8A8 Z24 S8
441.765 MPix/s color only
424.499 MPix/s z only
441.475 MPix/s color and z
373.532 MPix/s z tested (pass), color and z
401.683 MPix/s discardable by LEQUAL depth test
403.951 MPix/s discardable by GEQUAL depth test
402.631 MPix/s discardable by EQUAL depth test
424.809 MPix/s stencil writes
424.760 MPix/s discardable by EQUAL stencil test
stencil test passed
422.888 MPix/s pure stencil updates
423.063 MPix/s z fail (LEQUAL), stencil update
z test passed (LEQUAL)
423.652 MPix/s stencil update
424.886 MPix/s stencil update, z update
441.650 MPix/s color replace
442.631 MPix/s z update, color replace
441.756 MPix/s stencil update, color replace
441.798 MPix/s stencil update, z update, color replace
16 bits
Mode: R8G8B8A0 Z16 S0
413.118 MPix/s color only
416.025 MPix/s z only
413.373 MPix/s color and z
342.995 MPix/s z tested (pass), color and z
351.779 MPix/s discardable by LEQUAL depth test
355.549 MPix/s discardable by GEQUAL depth test
354.281 MPix/s discardable by EQUAL depth test
Bandwidth
Mode: R8G8B8A8 Z24 S8
available to buffer clears
1.108 GB/s all buffers
393.716 MB/s color only
437.222 MB/s depth and stencil
253.748 MB/s depth only
85.940 MB/s stencil only
2.805 GB/s worst case draw bandwidth
632.778 MB/s burned by the RAMDAC
3.438 GB/s estimated physical bandwidth
Geometry
Mode: R8G8B8A0 Z16 S0
Plain vertices
1.015 MTris/s as triangle fan
495.669 kTris/s as triangle list
394.862 kTris/s clipped
Vertex shading speed
441.512 kTris/s lit (one directional light)
407.347 kTris/s lit (one point light)
238.982 kTris/s lit (eight point lights)
Texturing
Mode: R8G8B8A0 Z16 S0
Textured fillrate
Bilinear filter
76.223 MPix/s w 1 layers
72.672 MPix/s w 2 layers
67.291 MPix/s w 3 layers
47.893 MPix/s w 4 layers
40.762 MPix/s w 5 layers
34.326 MPix/s w 6 layers
29.697 MPix/s w 7 layers
35.916 MPix/s w 8 layers
Trilinear filter
65.021 MPix/s w 1 layers
57.857 MPix/s w 2 layers
51.005 MPix/s w 3 layers
34.737 MPix/s w 4 layers
29.569 MPix/s w 5 layers
24.482 MPix/s w 6 layers
20.759 MPix/s w 7 layers
22.628 MPix/s w 8 layers
Readback
Mode: R8G8B8A8 Z24 S8
Whole buffer
8.530 MPix/s of R8G8B8A8 colors
3.063 MPix/s of B8G8R8A8 colors
9.588 MPix/s of R8G8B8 colors
3.418 MPix/s of B8G8R8 colors
6.675 MPix/s of depth data (unsigned integer)
7.839 MPix/s of depth data (float)
9.978 MPix/s of stencil
32x32 region
9.182 MPix/s as R8G8B8A8
2.283 MPix/s as B8G8R8A8
9.177 MPix/s as R8G8B8
2.452 MPix/s as B8G8R8
5.637 MPix/s of depth data (unsigned integer)
6.571 MPix/s of depth data (float)
8.783 MPix/s of stencil
Texture cache
Mode: R8G8B8A8 Z24 S8
2 kiB using RGBA textures(CSV)
Tiling
Mode: R8G8B8A8 Z24 S8
preferred block alignment
updating all buffers (CSV)
16 pixels wide
16 pixels high
in color buffer (CSV)
16 pixels wide
16 pixels high
in depth buffer (CSV)
none detected in x-direction
none detected in y-direction
in stencil buffer (CSV)
8 pixels wide
none detected in y-direction

Was das jetzt heisst, müsst ihr mir allerdings sagen :biggrin:

[Gast]

Wo gibt's den 10.1er-Treiber mit Open GL für Windows XP? *habenwill* :)

[Xmas]

Abtönungs Sprachversion 01. Okt
;D;D

Lediglich dass SGX545 diese Prozentuale zu 100% bringen koennte und wieviel genau einem SM3.0+ 535 bis zur vollen Komplianz fehlt ;)
Das Wort "Komplianz" oder eine direkte Entsprechung dazu gibt es im Deutschen nicht. Software und Hardware sind außerdem zwei Paar Schuhe.

[Captain Future]

Wo gibt's den 10.1er-Treiber mit Open GL für Windows XP? *habenwill* :)
Mist, ich war nicht eingeloggt. :(

[loewe]

Wo gibt's den 10.1er-Treiber mit Open GL für Windows XP? *habenwill* :)

Schon mal von Suchmaschinen gehört?

Probier doch mal in google "iegd 10.1 download"

[Captain Future]

Schon mal von Suchmaschinen gehört?

Probier doch mal in google "iegd 10.1 download"
Ja, habe ich von gehört. Und ja, das habe ich auch schon in Google eingegeben. Aber nein: Dort finde ich keinen 10.1-Download für Windows XP. Sonst hätte ich nicht gefragt.


btw, Schlaubi-Schlumpf:

[FelixPaul]

hallo captain!

die IEGD 10.1 hab ich hier her: http://forum.eeeuser.com/viewtopic.php?pid=613371

lass dich von dem großen download nicht verunsichern, du brauchst eigentlich nur die Dateien aus dem Unterverzeichnis /drivers.

Also OpenGL Spiele auf Quake3 Engine funktionieren ganz gut, auch in ein paar Benchmarks hat sich einiges getan. 3Dmark2001 ist im gegenüber dem aktuell XP Treiber (...1009er) von ca. 1000 Punkten auf 1900 gesprungen.

Auch bei den GDI und D2D Werten unter Crystalmark2004R3 hat sich einiges getan, gegenüber Vista/Win7 sind diese fast 10x so schnell. Das könnte auch erklären warum sich XP im täglichen Gebrauch besser "anfühlt".

Kannst das Ding ja mal testen, ist vom 01.06.2009, was neueres gibts glaube ich nicht. ABER: frei von Bugs ist das Ding nicht, aber probier es ruhig mal aus.

Gruß,
Felix

[loewe]

Was das jetzt heisst, müsst ihr mir allerdings sagen :biggrin:

Wie dumm von mir, das ist ja die 0.5 Version!

Hier : http://www.mitrax.de/files/archmark_alt.exe ist noch mal die alte 0.22er Version.
Dafür habe ich entsprechende Vergleichswerte von den alten KYROs und vom SGX535. Auch wenn ich nicht erwarte das die beiden Versionen sich sehr verschieden verhalten, man kann nie wissen! Kannst Du bitte den Test noch einmal mit dieser Version wiederholen?

Erst einmal nur zwei Dinge:

1. Eigentlich sollten sich die Ergebnisse zwischen beiden Versionen massiv unterscheiden. Ich würde bei Flush von einem Tiler sehr viel höhere Werte bei allen Füllrate Tests erwarten, dazu später noch einmal mehr, wenn Deine neuen Werte vorliegen. :)
2. Mich verwundern sehr die Texel-Füllraten. Ich hätte da auch Werte jenseits der 300 MPixel/s erwartet, auch wenn diese Werte alles bestätigen was ich selbst, egal mit welchem Treiber ;) , gemessen habe!
Warum hat SGX535 nur 50 MTexel Füllrate???
Danke!

[Captain Future]

hallo captain!

die IEGD 10.1 hab ich hier her: http://forum.eeeuser.com/viewtopic.php?pid=613371

Fantastisch! Vielen Dank. :)

[FelixPaul]

Hallo Loewe, also die alte version vom ArchMark scheint nicht gut bei mir zu laufen. Bei der Flush Option ist alles deutlich langsamer, und bei swap Buffers gibts sogar nen error.


ArchMark 0.22.05
Driver: Gallium 0.1, pipe/psb/Poulsbo on IEGD v2.0 Mesa 7.1
1024x768 @ unknown refresh rate (assuming 85Hz)
Comment:
Flushing commands, no buffer swaps
1.450 GHz timer speed (should match your CPU clock)
Fillrate
32 bits
Mode: RGBA8888 Z24 S8
92.867 MPix/s color only
95.135 MPix/s z only
93.674 MPix/s color and z
95.336 MPix/s z tested (pass), color and z
95.306 MPix/s discardable by LEQUAL depth test
95.282 MPix/s discardable by GEQUAL depth test
95.727 MPix/s discardable by EQUAL depth test
96.035 MPix/s stencil writes
96.423 MPix/s discardable by EQUAL stencil test
stencil test passed
96.236 MPix/s pure stencil updates
96.138 MPix/s z fail (LEQUAL), stencil update
z test passed (LEQUAL)
96.643 MPix/s stencil update
95.827 MPix/s stencil update, z update
94.267 MPix/s color replace
94.256 MPix/s z update, color replace
91.784 MPix/s stencil update, color replace
94.802 MPix/s stencil update, z update, color replace
16 bits
Mode: RGBA8880 Z16 S0
80.718 MPix/s color only
83.209 MPix/s z only
83.301 MPix/s color and z
84.172 MPix/s z tested (pass), color and z
83.902 MPix/s discardable by LEQUAL depth test
84.643 MPix/s discardable by GEQUAL depth test
84.381 MPix/s discardable by EQUAL depth test
Bandwidth
Mode: RGBA8888 Z24 S8
available to buffer clears
1.258 GB/s all buffers
438.648 MB/s color only
493.479 MB/s depth and stencil
286.731 MB/s depth only
95.022 MB/s stencil only
1.676 GB/s worst case draw bandwidth
267.387 MB/s burned by the RAMDAC
1.943 GB/s estimated physical bandwidth
Geometry
Mode: RGBA8880 Z16 S0
Plain vertices
388.002 kTris/s as triangle fan
194.449 kTris/s as triangle list
174.957 kTris/s clipped
Vertex shading speed
185.765 kTris/s lit (one directional light)
179.237 kTris/s lit (one point light)
135.864 kTris/s lit (eight point lights)
Texturing
Mode: RGBA8880 Z16 S0
Textured fillrate
Bilinear filter
80.539 MPix/s w 1 layers
76.394 MPix/s w 2 layers
67.988 MPix/s w 3 layers
47.861 MPix/s w 4 layers
40.836 MPix/s w 5 layers
34.404 MPix/s w 6 layers
29.797 MPix/s w 7 layers
36.001 MPix/s w 8 layers
Trilinear filter
66.769 MPix/s w 1 layers
60.056 MPix/s w 2 layers
51.216 MPix/s w 3 layers
34.788 MPix/s w 4 layers
29.634 MPix/s w 5 layers
24.523 MPix/s w 6 layers
20.902 MPix/s w 7 layers
22.718 MPix/s w 8 layers
Texture cache
Mode: RGBA8888 Z24 S8
0B using RGBA textures
Tiling
Mode: RGBA8888 Z24 S8
preferred block alignment
updating all buffers
16 pixels wide
16 pixels high
in color buffer
16 pixels wide
16 pixels high
in depth buffer
8 pixels wide
32 pixels high
in stencil buffer
none detected in x-direction
4 pixels high


@Captain: berichte doch mal ob der IEGD 10.1 bei dir was bringt! Welches Notebook benutzt du eigentlich? In dem DellMini Forum hab ich gelesen das Starcraft bisher nur über Umwege läuft, mit dem IEGD10 rennt das bei mir 1A :wink: weitere Klassiker hab ich allerdings noch nicht testen können.

Gruß,
Felix

[mboeller]

3Dmark2001 ist im gegenüber dem aktuell XP Treiber (...1009er) von ca. 1000 Punkten auf 1900 gesprungen.


Ein Lenovo Ideapad S12 mit einem Atom N270 @ 1.6GHz und einer Intel GMA950 IGP erreichte beim letzten c't Test (Heft 16; 2009 Seite 120) 2810 Punkte. Dh. von ~1/3 der Leistung der Konkurrenz auf ~2/3 mit nur einem Treiberupdate. Da sollte allerdings noch was zu machen sein, oder?

Edit:
Auf Beyond3D ist jetzt ein Vergleich zw. O-GL Treiber und Scitechs Wrapper zu sehen:
http://forum.beyond3d.com/showpost.php?p=1315720&postcount=65

Der Wrapper ist meistens um ca. 50% schneller als der Open-GL Treiber von Intel. Da ist wohl wirklich noch jede Menge Optimierungspotential vorhanden.

[Captain Future]

Ehrlich gesagt, FelixPaul, kann ich mit den komischen Dateien dort nur wenig anfangen...

[FelixPaul]

Hehe, ich ehrlich gesagt auch nicht so viel :) Hattest du denn Erfolg mit den IEGD 10.1 Treibern?

Achja, ich hab grad gesehen das Acer einen neuen XP Treiber rausgebracht hat, lade den grad runter und teste fröhlich drauf los ob´s was neues gibt.

Version: 6.14.11.1012
Download: http://support.acer-euro.com/drivers/downloads_gd.html
Müsstest dich da ein bisschen durchklicken: Netbook > Aspire One > AO751h > XP

Gruß,
Felix

[loewe]

Hallo Loewe, also die alte version vom ArchMark scheint nicht gut bei mir zu laufen. Bei der Flush Option ist alles deutlich langsamer, und bei swap Buffers gibts sogar nen error.


Hallo Felix, danke für die Tests! :)

Der PowerVR Treiber läuft mit dem alten Archmark durch, mit der 0.5er Version leider nicht.
PowerVR hat auch nur einen Treiber für eigene Demo Zwecke entwickelt, den eigentlichen Treiber für Poulsbo muss intel entwickeln, das ist so vereinbart und hat sicher auch sehr viel mit Geld zu tun.

Soweit erst einmal egal, fakt ist, der SGX535 verhält sich mit dem intel Treiber nicht wie ein TBDR!
Ich kann die SGX535 Werte nicht veröffentlichen, aber sie sind vom Verhalten her den KYRO Werten ähnlich. Das ist jetzt nur eine Aussage bzgl. des Verhaltens, ich habe nicht gesagt sie sind ähnlich hoch oder höher oder niedriger! ;)
Wenn Du Dir einmal die KYRO Werte hier: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=1337117&postcount=43
anschaust, stellst Du fest, mit Flush Buffers sind die Werte extrem hoch und damit natürlich falsch! Aber das muss so sein bei den TBDRs.
Durch das pixelgenaue HSR wird grundsätzlich alles aussortiert, was nachher nicht dargestellt wird. Die HSR Einheit ist im verwerfen extrem schnell und da der Benchmark ja versucht den Core mit Masse zu erschlagen, dabei auch noch mit sehr vielen gleichen Daten, werden diese eben einfach nur sehr schnell verworfen aber natürlich für den Benchmark gezählt.

Der intel Treiber zeigt dieses Verhalten nicht, womit sich der Verdacht bestätigt, das intel das PowerVR HSR faktisch nicht verwendet. Intel scheint den SGX535 wie einen IMR zu betreiben und das eher auch noch schlecht implementiert! Gerade der OpenGL Treiber scheint noch absolut am Anfang zu stehen.

Ich vermute mal der aktuelle intel Treiber, und da schließe ich den schnelleren IEGD 10.1 mit ein, erreicht so 1/5 bis 1/3 der möglichen Leistung des SGX535. Da ist noch sehr viel Raum für Optimierungen! :)

[Coda]

Intel scheint den SGX535 wie einen IMR zu betreiben und das eher auch noch schlecht implementiert!
Ich glaube kaum, dass das der Treiber beeinflussen kann. So etwas ist grundlegend in Hardware implementiert. Du interpretierst da sicher was falsch.

[stickedy]

afaik "zwingen" gewissen Spiele/Anwendungen die alten Kyro-Chips auch in einem IMR-Modus. Das sollte dann doch per Treiber aktivierbar sein. Evtl. lässt sich die "HSR-Engine" bei Bedarf deaktivieren?

Wobei das aber eigentlich irgendwie keinen Sinn macht, wenn Intel das als default machen würde, da PowerVR-Chips ja in Hardware extra dafür designt wurden und der Treiber für solche Späße ja eigentlich nicht wirklich gebraucht werden sollte - womit ein Grund entfallen würde, das wegen schlechter Treiber zu machen (was für mich der einzige sinnvoll erscheinende Grund wäre wenn ich drüber nachdenke...)

[Coda]

Also falls das so ist, dann ist es wirklich erbärmlich.

[Ailuros]

Ich glaube kaum, dass das der Treiber beeinflussen kann. So etwas ist grundlegend in Hardware implementiert. Du interpretierst da sicher was falsch.

Dumme Frage (die nicht direkt relevant ist): angenommen Du stehst in einem Spiel in einem einfachen Flur; wenn Du Dich zur linken Wand drehst steigt die Leistung um einiges und wenn Du Dich zur rechten Wand drehst faellt die Leistung um einiges (gleiches Phaenomen sowohl auf einem IMR als auch auf einem TBDR)...was genau ist schuld daran und wieso kann ein TBDR nichts daran aendern?

Wie dem auch sei ich will hoffen dass die Herren von Tungsten (oder wie zum Henker sie heutzutage heissen) endlich mal entdecken dass der chip ein onboard firmware hat pfff..........

[mboeller]

Ich vermute mal der aktuelle intel Treiber, und da schließe ich den schnelleren IEGD 10.1 mit ein, erreicht so 1/5 bis 1/3 der möglichen Leistung des SGX535. Da ist noch sehr viel Raum für Optimierungen! :)


Nur beim Archmark, oder auch bei Spielen und anderen Benchmarks wie zB. 3DMark0x?

[stickedy]

Macht wohl Tungsten Graphics die Treiberentwicklung für Intel bei dem Chip?

[Coda]

Dumme Frage (die nicht direkt relevant ist): angenommen Du stehst in einem Spiel in einem einfachen Flur; wenn Du Dich zur linken Wand drehst steigt die Leistung um einiges und wenn Du Dich zur rechten Wand drehst faellt die Leistung um einiges (gleiches Phaenomen sowohl auf einem IMR als auch auf einem TBDR)...was genau ist schuld daran und wieso kann ein TBDR nichts daran aendern?

Der TBDR-Vorteil ist nicht so groß wie du immer tust. Wenn grob von vorne nach hinten sortiert gerendert wird, dann killt auch ein IMR die meiste unsichtbar Geometrie schon bevor sie in den Rasterizer geht.
Angenommen man rendert direkt vor der Kamera ein Bildschirmfüllendes Polygon ganz am Anfang eines Frames - der Rest dahinter würde den Pixelshader nie sehen. Egal ob IMR oder TBDR.
Die Engine macht zumindest Frustum-Culling, d.h. es kann sehr gut sein, dass um einiges mehr Geometrie an die GPU gesendet wird wenn man in eine andere Richtung schaut.
Es muss immer die komplette Vertex-Arbeit erledigt werden, dazu kommen mehr Batches und der API-Overhead.

[loewe]

Nur beim Archmark, oder auch bei Spielen und anderen Benchmarks wie zB. 3DMark0x?

Ich interessiere mich eigentlich nicht besonders für Benchmarks, eher schon für entsprechende Spiele.
Ja, ich meine das ganz allgemein.

Macht wohl Tungsten Graphics die Treiberentwicklung für Intel bei dem Chip?
AFAIK, Ja!

[mboeller]

Ich interessiere mich eigentlich nicht besonders für Benchmarks, eher schon für entsprechende Spiele.
Ja, ich meine das ganz allgemein.


ouch!

also da hat wohl jemand was dagegen das die eigenen chipsets gegenüber dem sgx zu schlecht aussehen. na sowas auch.

[Ailuros]

Der TBDR-Vorteil ist nicht so groß wie du immer tust. Wenn grob von vorne nach hinten sortiert gerendert wird, dann killt auch ein IMR die meiste unsichtbar Geometrie schon bevor sie in den Rasterizer geht.
Angenommen man rendert direkt vor der Kamera ein Bildschirmfüllendes Polygon ganz am Anfang eines Frames - der Rest dahinter würde den Pixelshader nie sehen. Egal ob IMR oder TBDR.
Die Engine macht zumindest Frustum-Culling, d.h. es kann sehr gut sein, dass um einiges mehr Geometrie an die GPU gesendet wird wenn man in eine andere Richtung schaut.
Es muss immer die komplette Vertex-Arbeit erledigt werden, dazu kommen mehr Batches und der API-Overhead.


Es gibt in meiner Frage eben keinen EINZIGEN Vorteil fuer einen TBDR welches erstmal Deine Antwort bestaetigt, Deinen ersten Satz als komplett idiotisch erscheinen laesst und beantwortet auch indirekt Dein voriges Zeug. Oder anders OHNE DASS JEGLICHE SW RICHTIG MITSPIELT KANN DIR EIN TBDR IN SACHEN HSR GAR NICHTS ANRICHTEN. Einfacher geht's gar nicht.

[Coda]

Blödsinn. Das HSR wird von der Hardware gemacht. Wenn der Intel-Treiber den SGX im IMR-Modus laufen lässt, dann muss er den Chip so konfigurieren. Das wird irgend ein Kompatibilitätsmodus sein.

Aber wenn es den nicht gäbe, hätte die Software da rein gar nichts zu sagen.

[Ailuros]

Blödsinn. Das HSR wird von der Hardware gemacht. Wenn der Intel-Treiber den SGX im IMR-Modus laufen lässt, dann muss er den Chip so konfigurieren. Das wird irgend ein Kompatibilitätsmodus sein.

Aber wenn es den nicht gäbe, hätte die Software da rein gar nichts zu sagen.

Ach und wie laeuft das angebliche HSR in hw wenn der Treiber in irgend einem "Kompatibilitaetsmodus" laeuft?

Mir war auf KYRO kein IMR Kompatibilitaetsmodus bekannt; der chip verhielt sich lediglich als ein IMR in Grenzfaellen wenn ihm die Puste ausging und dabei war natuerlich seine rohe Fuellrate viel zu karg.

Die einzige zuverlaessige Info die ich ueber GMA500/Tungsten bis jetzt habe ist dass der Tungsten Treiber die onboard firmware des SGX nicht benutzt und daher das Ganze oefters zu sw rendering fuehrt. Ob sich daran jetzt etwas geaendert hat oder nicht weiss ich nicht und auch nicht wieso genau die chips sich so verhalten.

Ich hatte zu KYRO2 Zeiten sowohl eine solche als auch eine GF3 in Castle Wolfenstein damals verglichen. Ein leehrer Gang; wenn man sich zur einen Wand drehte schoss die Leistung wie zu erwarten um ein gutes Prozentual nach oben auf beiden. Drehte man sich nun auf die andere Wand purzelte die Leistung unerklaerlich nach unten auf beiden obwohl es die gleiche oede Wandtextur war. Hier war eben die engine nicht zustande zu erkennen was hinter der zweiten Wand lag und beide GPUs wurden quasi gezwungen nutzlose bzw. unsichtbare Information zu bearbeiten. Hier hilft das hw HSR eines TBDRs rein gar nichts.

[RainingBlood]

nicht "wenn ihm die Puste ausging", sondern weil es schlicht keinen Content gab, der hätte weggelassen werden können.
Deshalb sah der Kyro2 in Shootern gut aus und bei Strategiespielen fiel er deutlich hinter die Konkurrenz.

Heutzutage sind die Chips ja weiter als eine GF2/3 und verhalten sich beim rendern eh intelligenter.

[Coda]

Ich hatte zu KYRO2 Zeiten sowohl eine solche als auch eine GF3 in Castle Wolfenstein damals verglichen. Ein leehrer Gang; wenn man sich zur einen Wand drehte schoss die Leistung wie zu erwarten um ein gutes Prozentual nach oben auf beiden. Drehte man sich nun auf die andere Wand purzelte die Leistung unerklaerlich nach unten auf beiden obwohl es die gleiche oede Wandtextur war. Hier war eben die engine nicht zustande zu erkennen was hinter der zweiten Wand lag und beide GPUs wurden quasi gezwungen nutzlose bzw. unsichtbare Information zu bearbeiten. Hier hilft das hw HSR eines TBDRs rein gar nichts.
Ja, weil es sich so verhält wie ich es oben erklärt habe. Beide müssen immer die volle Geometriearbeit machen, und die Quake-3-Engine rendert front-to-back, also cullt die GF3 auch einiges weg.

Was möchtest du mir jetzt damit sagen?

[robbitop]

Ja, weil es sich so verhält wie ich es oben erklärt habe. Beide müssen immer die volle Geometriearbeit machen, und die Quake-3-Engine rendert front-to-back, also cullt die GF3 auch einiges weg.

Was möchtest du mir jetzt damit sagen?
Erzwingt sie f2b-Rendering? Das würde natürlich die Beobachtungen erklären, aber es wäre ungünstig für GPUs aufgrund der potenziellen vielen Texturwechseln, was zu vielen Wartezeiten führen müsste, weil der Texture-Cache dann Misses hat und die neue Textur laden muss. Das war doch der Grund, warum man bis dato immer quasi "random" gerendert hat. Also Objekt für Objekt, die aber nicht nach Z sortiert waren. Oder bekam ich da etwas in den falschen Hals?

[Aquaschaf]

Ein "Objekt" hat immer nur eine Textur bzw. einen Satz an Texturen. Und wenn eine Engine front-to-back rendert, dann auf Objektebene. Sie sortiert Objekte nach dem Abstand, nicht einzelne Dreiecke. D.h. mit der Texturcache-Hitrate gibt es keinen direkten Zusammenhang.

[robbitop]

Ein "Objekt" hat immer nur eine Textur bzw. einen Satz an Texturen. Und wenn eine Engine front-to-back rendert, dann auf Objektebene.
Ein Objekt kann aber in Richtung Z von ... bis ... gehen. Und dann ist das nicht mehr klassisches Front2back mMn.

[Ailuros]

Was möchtest du mir jetzt damit sagen?

Dass die hw ohne die dementsprechend sw nichts von sich aus anrichten kann vielleicht?

[stickedy]

Aber das widerspräche doch der ganzen TBDR-Technik?!

[Aquaschaf]

Ein Objekt kann aber in Richtung Z von ... bis ... gehen. Und dann ist das nicht mehr klassisches Front2back mMn.

Welches "klassische FtB"? Es funktioniert (mit an Sicherheit grenzender Wahrscheinlichkeit) in jeder Engine so, anders geht es sinnvoll auf dieser Ebene nicht. Man sortiert anhand des Pivots der Objekte, dem der Kamera am nächsten Punkt ihrer Bounding-Box, Bounding-Sphere oder was auch immer. Genau ist das natürlich nicht, aber im Vergleich dazu draw-calls ungeordnet zu machen spart es je nach Situation viel Overdraw.

[Ailuros]

Aber das widerspräche doch der ganzen TBDR-Technik?!

Es gibt keinen Widerspruch solange man im Hinterkopf high und low level HSR separieren kann.

[Coda]

Dass die hw ohne die dementsprechend sw nichts von sich aus anrichten kann vielleicht?
Das ist eben nicht so. Du scheinst nicht zu verstehen wie ein Deferred Renderer wirklich funktioniert.

Wenn überhaupt, dann muss wie ich schon gesagt werden irgendwie ein IMR-Modus erzwungen werden, ansonsten werden vom Chip automatisch für jedes Tile nur die Fragmente berechnet die sichtbar sind. Das hat nichts mit den Daten zu tun die reinkommen.

Erzwingt sie f2b-Rendering?
Q3 rendert die BPS-Leafs von vorne nach hinten. Nicht einzelne Polygone. Die Leafs sind übrigens alle konvex, es gibt deshalb keine Überschneidungen.

Noch was: Bei modernen Renderern mit Z-First-Pass rendert man natürlich nur diesen so, der Rest kann dann in beliebiger Reihenfolge kommen.

[Gast]

Wie sind eigentlich die Linuxtreiber, die Intel für GMA500 zur Verfügung stellt? Und wie sieht IMGTecs Treiberpolitik unter freien Betriebssystemen aus?

[Coda]

Also soweit ich es mitbekommen habe sind die Intel-Treiber absoluter Crap.

[stickedy]

Und ImgTecs Treiberpolitik ist genauso crap. Zumindest bisher...

[loewe]

Wie sind eigentlich die Linuxtreiber, die Intel für GMA500 zur Verfügung stellt? Und wie sieht IMGTecs Treiberpolitik unter freien Betriebssystemen aus?

AFAIK sind die Linux Treiber, die intel hier heraus gibt, nicht anders als die Windows Treiber. :mad:

Soweit mir bekannt gibt es von ImgTec keine freien Linux Treiber, es können nur ihre Module entsprechend eingebunden. Soweit mir bekannt haben sie auch nicht die Absicht, die Treiber frei zu geben.

[mboeller]

Loewe hat anscheinend seinen Treiber-Artikel zum Poulsbo fertig gestellt: http://www.mitrax.de/ [neuests News]

folgender Abschnitt der News ist schon wirklich erschreckend:

wie gegenwärtig intel, bei Werten zwischen 10% und 30% hängen bleiben.


Ouch!

Aber anscheinend ist Abhilfe in Sicht [ENDLICH!!]:

In dem Zusammenhang sollte man vielleicht aber auch die Ausschreibungen von mehreren Stellen von Ingenieure für die Treiberentwicklung für Windwos 7, Windows Vista und Windows XP sehen, die man auf der ImgTec Seite finden kann!

Wenn's stimmt OK. Wird aber auch Zeit das IMG aufwacht.

[FelixPaul]

gute nachrichten! ich hoffe das loewe bald ein paar zahlen veröffentlichen "darf". fürs zocken nutze ich aktuell die IEGD 10.1 treiber unter XP, welche eine ganz akzeptable leistung bieten. hätte echt nicht geacht, dass mir couter-strike nach 10 jahren immer noch spass macht... auf dem netbook ;)

mal sehen was die zukunft so bringt :redface:

[grobi]

Ich habe mit dem neusten Treiber v.6.14.11.1012 keinen Filter über den Videos im Mediaplayer. Mit dem v.6.14.11.1007 geht das ohne Probleme.

mfg grobi

[Shink]

Wie sind eigentlich die Linuxtreiber, die Intel für GMA500 zur Verfügung stellt?
Problematisch. Anscheinend gibt es noch immer keine Treiber (auch nicht closed-source) für etwas das neuer ist als Ubuntu 8.04; man will wohl auch für 9.10 nichts liefern.

Dafür ist der GMA500-Treiber unter Linux anscheinend einer der komplettesten was Videobeschleunigung betrifft (besser als die Intel X4500 oder AMD-Treiber).

[loewe]

Problematisch. Anscheinend gibt es noch immer keine Treiber (auch nicht closed-source) für etwas das neuer ist als Ubuntu 8.04; man will wohl auch für 9.10 nichts liefern.
Gilt in ähnlicher Form auch für die Windows Treiber, was 3D anbelangt. Intel scheint sich für diese Dinge nicht zu interessieren und auf OpenGL verzichten sie gleich ganz.

Dafür ist der GMA500-Treiber unter Linux anscheinend einer der komplettesten was Videobeschleunigung betrifft (besser als die Intel X4500 oder AMD-Treiber).
Auch das gilt ähnlich für Windows. Ab Windows Vista ist Video eigentlich perfekt, für Windows XP gibt es auch Lösungen oder eben PowerDVD.

[loewe]

Ok, ich hole den Thread mal wieder hoch.

Zweiter Artikel zum GMA500: http://www.mitrax.de/?cont=artikel&aid=36 :)

[grobi]

Danke für den Artikel. War sehr informativ für mich. :massa:

ps:
Die Intelcodecs lassen sich sehr bescheiden Downloaden. Alle Dateien einzeln. Ich habs bis jetzt nicht geschaft.

[loewe]

Danke für den Artikel. War sehr informativ für mich. :massa:

Gern geschehen, obwohl ich lieber etwas anderes geschrieben hätte.
Selbst ImgTec war mit meinen Ergebnissen nicht so ganz zufrieden! Sie sollten es doch eigentlich am besten wissen.

ps:
Die Intelcodecs lassen sich sehr bescheiden Downloaden. Alle Dateien einzeln. Ich habs bis jetzt nicht geschaft.
Offene Quellen sind rar, Sony hat die Codecs auch für den Vario P heraus gegeben. Sieh mal in dein Postfach. ;)

Hier ist aber z.B. noch ein Link für ein komplettes ZIP File: http://www.file-upload.net/download-1722666/Intel_Video_Codecs_GMA500.zip.html

[AnarchX]

Flash 10.1 Support wohl nun auch offiziell:
For the Atom/Intel® GMA 500 chipset, hardware decode is supported starting with the graphics driver version 5.2.1.2020 (8.14.10.2020) for 32-bit Windows ® 7
http://labs.adobe.com/technologies/flashplayer10/releasenotes.pdf

Das macht die Netbooks mit Z-Atom (http://geizhals.at/deutschland/?cat=nb12&asuch=%22Atom%20Z%22&asd=on&v=e&plz=&dist=&sort=p)doch um einiges attraktiver.

[loewe]

Ja, die Beta 3 funktioniert jetzt richtig gut.

Leider gibt es aber sonst nichts Neues was den Treiber anbelangt.
Immer noch keine OpenGL Unterstützung und D3D ist noch so schlecht wie vor einem Jahr! :(
Ich erwarte da für Poulsbo auch nicht mehr viel!

[mekakic]

Wieviel bringt dann der GMA 500 Chipsatz bei Video? Reicht es in der Komination für YouTube HD Videos z.B.?

[grobi]

Wieviel bringt dann der GMA 500 Chipsatz bei Video? Reicht es in der Komination für YouTube HD Videos z.B.?
Ich probiere es gleich mal aus. :wink:

Edit: Ich kann die Beta 3 nicht installieren, bricht mit einer Fehlermeldung ab. Ich nutzte Windows 7 32Bit.

[stickedy]

Ich probiere es gleich mal aus. :wink:

Edit: Ich kann die Beta 3 nicht installieren, bricht mit einer Fehlermeldung ab. Ich nutzte Windows 7 32Bit.
Was denn für eine Fehlermeldung?

[grobi]

Er bricht die Installation ab(Installer/De-Installer funktioniert nicht mehr).

mfg grobi

[stickedy]

Er bricht die Installation ab(Installer/De-Installer funktioniert nicht mehr).
Hast du die andere Version vorher deinstalliert?

[grobi]

Ja natürlich. Ich werd nachher nochmal ne Runde frickeln.

[Gast]

Er bricht die Installation ab(Installer/De-Installer funktioniert nicht mehr).

mfg grobi

Ich habe das gleiche Problem... Die Flash Beta werde ich wohl nur noch durch eine Systemwiederherstellung los...

[Gast]

Ja dieser Sascha Pallenberg tickt so. Kritik ist da ein Fremdwort, kann er gar nicht leiden. So wird man schnell zum Troll, sein Lieblingswort. Hab ich selber schon bemerkt und sieht man auch an vielen unverschämten Kommentaren dort. Der letzte Kommentar (http://www.netbooknews.de/6874/bilderserie-hands-on-mit-dem-msi-wind-u200/) dort ist pfui.

Musste direkt an den Post denken, als ich das hier gelesen habe: http://www.netbooknews.de/23557/kommentar-zum-ruecktritt-des-neofonie-geschaeftsfuehrers-quo-vadis-wetab/#comment-84244371
:rolleyes:
(gut ich kenne diese andere Seite nicht aber allein was der Typ sich rausnimmt... ).