Archiv verlassen und diese Seite im Standarddesign anzeigen : Ist Larrabee ein TBDR?
turboschlumpf
2008-08-05, 13:31:23
Ist Larrabee jetzt ein TBDR oder nur ein TBR?
Hier gibt es das PDF von der SIGGRAPH:
http://softwarecommunity.intel.com/articles/eng/3803.htm
stickedy
2008-08-05, 14:07:38
Da zitiere ich mal Ailuros:
Uhmmm BS Larabee hat eine sehr wichtige Einzigartigkeit des PowerVR, aber nicht auf HW-Level. Es ist eine komplette Eigenentwicklung von Intel's Larabee Team.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6696768#post6696768
Ich würde sagen, dass das Rendereing bei Larrabee ebenfalls verzögert wird, aber das alles durch den Treiber geschieht!
Abraxus
2008-08-05, 14:13:37
Steht doch alles in dem Paper, das ist ein Software-Sort-Middle-Renderer der einem SGX gar nicht so unähnlich operiert. Ich bin zwar der Meinung das sie sich damit einen Bock schießen, aber interessant ist es allemal.
turboschlumpf
2008-08-05, 14:42:00
Steht doch alles in dem Paper, das ist ein Software-Sort-Middle-Renderer [...]
Aha, und was ist/heißt das? XD
Ailuros
2008-08-05, 14:57:29
Ist Larrabee jetzt ein TBDR oder nur ein TBR?
Hier gibt es das PDF von der SIGGRAPH:
http://softwarecommunity.intel.com/articles/eng/3803.htm
TBDR durch den Treiber.
Ailuros
2008-08-05, 15:03:28
nochmal, es ist kein TBDR, es ist ein TBR, kein Deferred!
Es ist ein tile based deferred renderer (durch den Treiber) und nicht auf HW-Basis. Es wird verzoegert und jetzt bitte aus damit.
was ich gerne wissen würde aber sehr wahrscheinlich wird das nie ans Tageslicht kommen.
Inwiefern bzw. inwieweit hat IMG/PowerVR Intel dabei geholfen einen guten effizienten TBDR-Software Renderer für Larrebee zu schreiben? Ich kann mir einfach nicht vorstellen das Intel sowas von alleine hinbekommt wo die Leute es doch noch nicht einmal schaffen gute Treiber für die X3100 zu schreiben.
Ob der Treiber wirklich "gut" und "effizient" ist bleibt abzusehen. Inwiefern sollte IMG Intel in irgendeiner Art damit helfen? Intel experimentiert (vergebens bis zu Larabee) mit TBDR und ja das Larabee SW Team ist ein eigenstaendiges Team (und ein ziemlich grosses dazu) und hat absolut nichts mit dem chipset team zu tun.
Wie ich schon sagte Larabee klingt nach "naiver HW mit intelligenter SW". Ob die SW nun doch wirklich intelligent ist und inwiefern bleibt trotz allem abzusehen. Und nein SW kann nicht so einfach HW ersetzen; zumindest nicht eine Kombination von intelligenter HW mit intelligenter SW hm? ;)
robbitop@work
2008-08-05, 15:07:39
Es ist schon ein wenig mehr als das, wenn ich das richtig verstehe. Auch das gesamte Resolving, Blending ect passiert in den Tilecaches.
Allerdings scheint es kein Sortierung der Dreiecke zu geben. Diese anscheinend alle transformiert und durch Z-Tests entfernt. Hatte aber nur kurz drüber gesehen. Auf jeden Fall ein interessanter Ansatz.
Allerdings ist TBDR nicht immer der heilige Gral. Die IGPs von Intel sind (bis auf X3000 und X4500) auch TBDRs. Allerdings mit Flaschenhälsen beim Trianglebinning. Das muss nichts heißen. TBDR ist eben nicht TBDR.
Angeblich ist Larrabee keine PVR Entwicklung.
Die geometrie wird nirgens gespeichert und am ende durch die pipeline tile-weise gejagt. es wird normal forward rasterisiert, aber aus effiziensgruenden immer tile-weise, das ist bei NV und AMD aber nicht anders. die sagen dazu dann z.B. 512Threads, was einfach nur ein tile ist mit 32*16 pixel.
Es ist ein tile based deferred renderer (durch den Treiber) und nicht auf HW-Basis. Es wird verzoegert und jetzt bitte aus damit.
"Unlike some other tile-based rendering methods, there is no attempt at perfect occlusion culling before shading, reordering of shading, or any other non-standard rendering methods" http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf
Es wird nichts deferred. Alles wird so gezeichnet wie es kommt. Es wird lediglich in tiles eingeteilt, genau wie es auf anderen GPUs auch passiert.
So, und jetzt bitte aus mit unsinnigen gegenteiligen Behauptung als es im Intel Paper ist.
Es ist schon ein wenig mehr als das, wenn ich das richtig verstehe. Auch das gesamte Resolving, Blending ect passiert in den Tilecaches.
Allerdings scheint es kein Sortierung der Dreiecke zu geben. Diese anscheinend alle transformiert und durch Z-Tests entfernt. Hatte aber nur kurz drüber gesehen. Auf jeden Fall ein interessanter Ansatz.
Allerdings ist TBDR nicht immer der heilige Gral. Die IGPs von Intel sind (bis auf X3000 und X4500) auch TBDRs. Allerdings mit Flaschenhälsen beim Trianglebinning. Das muss nichts heißen. TBDR ist eben nicht TBDR.
Angeblich ist Larrabee keine PVR Entwicklung.
In dem PDF steht das alle transformierten Vertex "gebinned" werden. Und zudem das man einige dieser "gebinned" Vertex durch ein HirZ verwerfen kann.
Wenn du dir jetzt einige PowerVR Patente durchliest steht da fast genau das gleiche drin.
Das andere GPUs in Tiles einteilen wäre mir aber komplett neu. Es gibt kein Binning auf einer GeForce oder Radeon. Die "Tiles" dort beziehen sich auf die Branching-Granularität.
Was Larrabee macht ist zuerst alles zu transformieren und es in einer Datenstruktur abzulegen die die Polygone in die "Bins" verteilt. Daraufhin wird jeder dieser Bins gerendert wodurch man komplett in den Cache rendern kann.
"Unlike some other tile-based rendering methods, there is no attempt at perfect occlusion culling before shading, reordering of shading, or any other non-standard rendering methods" http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf
Es wird nichts deferred. Alles wird so gezeichnet wie es kommt. Es wird lediglich in tiles eingeteilt, genau wie es auf anderen GPUs auch passiert.
So, und jetzt bitte aus mit unsinnigen gegenteiligen Behauptung als es im Intel Paper ist.
Seufz;
sie schreiben selbst das es ein TBDR ist. Das was du da anführst hat nichts damit zu tun ob es ein TBR od. TBDR ist. Selbst die PowerVR chips haben nie (außer vielleicht die erste von 1996) ein perfektes Occlusion Culling vor dem Shading durchgeführt. Dafür hatten und haben sie (zumindest Kyro und MBX, vom SGX weiß ich zuwenig) einen Onboard Z-Buffer zusammen mit dem Tile-Buffer.
TBDR heißt nur das die Vertex nicht sofort gerendert werden sondern zuerst "gebinned" und den Tiles zugeordnet werden. Wenn das passiert ist startet das normale (Pixel)-Shading.
Seite2
The PowerVR* MBX and SGX series [PowerVR 2008],
the Intel® Graphics Media Accelerator 900 Series [Lake 2005],
the ARM Mali* [Stevens 2006], and Talisman [Torborg & Kajiya
1996] have been generally classified as sort middle architectures.
Seite5
This section describes a sort-middle software renderer designed
for the Larrabee architecture that uses binning for load balancing.
Section 5 provides performance studies for this software renderer.
Ob der Treiber wirklich "gut" und "effizient" ist bleibt abzusehen. Inwiefern sollte IMG Intel in irgendeiner Art damit helfen? Intel experimentiert (vergebens bis zu Larabee) mit TBDR und ja das Larabee SW Team ist ein eigenstaendiges Team (und ein ziemlich grosses dazu) und hat absolut nichts mit dem chipset team zu tun.
Auch ein ziemlich großes Team wird es wohl nicht sofort schaffen TBDRendering ohne Probleme nur mit Simulationen in Software auf die Beine zu stellen. Meine Idee hinter dem Kommentar war nur das sich Intel IMHO wahrscheinlich Hilfe von IMG geholt hat um den TBDR-software renderer hinzubekommen da Intel mit dieser Truppe inzwischen anscheinend ziemlich intensiv zusammenarbeitet. Das würde für mich auch den Kommentar von JohnH auf Beyond3D erklären "good things come to..."
Ailuros
2008-08-05, 15:53:07
Es ist schon ein wenig mehr als das, wenn ich das richtig verstehe. Auch das gesamte Resolving, Blending ect passiert in den Tilecaches.
Allerdings scheint es kein Sortierung der Dreiecke zu geben. Diese anscheinend alle transformiert und durch Z-Tests entfernt. Hatte aber nur kurz drüber gesehen. Auf jeden Fall ein interessanter Ansatz.
Allerdings ist TBDR nicht immer der heilige Gral. Die IGPs von Intel sind (bis auf X3000 und X4500) auch TBDRs. Allerdings mit Flaschenhälsen beim Trianglebinning. Das muss nichts heißen. TBDR ist eben nicht TBDR.
Angeblich ist Larrabee keine PVR Entwicklung.
Wenn Larabee das schafft was er verspricht dann ist es eine nette Ohrfeige ins Gesicht des chipset Treiber teams, die das TBDR auf ihren Dingern nie richtig hinbekommen konnten.
Was das triangle binning betrifft hat der Gast oben schon beantwortet. Die Frage ist eigentlich nur ob es diesmal funktioniert und wie effizient.
Ailuros
2008-08-05, 15:57:07
"Unlike some other tile-based rendering methods, there is no attempt at perfect occlusion culling before shading, reordering of shading, or any other non-standard rendering methods" http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf
Es wird nichts deferred. Alles wird so gezeichnet wie es kommt. Es wird lediglich in tiles eingeteilt, genau wie es auf anderen GPUs auch passiert.
So, und jetzt bitte aus mit unsinnigen gegenteiligen Behauptung als es im Intel Paper ist.
Die "unsinnige gegenteilige Behauptung" (die Du sowieso anscheinend nicht richtig interpretieren kannst) wurde direkt von jemand von IMG bestaetigt. Waere es anders wuerden sie es als erste bestreiten.
Ailuros
2008-08-05, 15:59:46
Auch ein ziemlich großes Team wird es wohl nicht sofort schaffen TBDRendering ohne Probleme nur mit Simulationen in Software auf die Beine zu stellen. Meine Idee hinter dem Kommentar war nur das sich Intel IMHO wahrscheinlich Hilfe von IMG geholt hat um den TBDR-software renderer hinzubekommen da Intel mit dieser Truppe inzwischen anscheinend ziemlich intensiv zusammenarbeitet. Das würde für mich auch den Kommentar von JohnH auf Beyond3D erklären "good things come to..."
Nein es gab keine Hilfe von IMG. JohnH meinte eigentlich IMG's zukuenftige Ankuendigungen fuer neue noch unbekannte SGX Modelle und die weiteren Maerkte die diese anzielen moechten und hat nichts anderes damit gemeint. Total OT: John arbeitete vor vielen Jahren bei ATI LOL ;)
Wenn Larabee das schafft was er verspricht dann ist es eine nette Ohrfeige ins Gesicht des chipset Treiber teams, die das TBDR auf ihren Dingern nie richtig hinbekommen konnten.
Das ist doch in Hardware bei den IGPs, oder nicht? Was kann dann da das Treiberteam dafür?
Bevor ihr euch darüber streitet ob es nun ein TBR oder TBDR ist, solltet ihr vielleicht erst mal die Begriffe definieren. Sonst hat jeder nach seiner Definition recht, aber keiner weiß mehr als vorher. ;)
Es wird lediglich in tiles eingeteilt, genau wie es auf anderen GPUs auch passiert.
Welche anderen GPUs meinst du denn genau?
Selbst die PowerVR chips haben nie (außer vielleicht die erste von 1996) ein perfektes Occlusion Culling vor dem Shading durchgeführt.
Wo hast du das her?
TBDR heißt nur das die Vertex nicht sofort gerendert werden sondern zuerst "gebinned" und den Tiles zugeordnet werden. Wenn das passiert ist startet das normale (Pixel)-Shading.
Gibt es deiner Meinung nach überhaupt einen Unterschied zwischen TBDR und TBR?
Bevor ihr euch darüber streitet ob es nun ein TBR oder TBDR ist, solltet ihr vielleicht erst mal die Begriffe definieren. Sonst hat jeder nach seiner Definition recht, aber keiner weiß mehr als vorher. ;)
Welche anderen GPUs meinst du denn genau?
Wo hast du das her?
Gibt es deiner Meinung nach überhaupt einen Unterschied zwischen TBDR und TBR?TBDR und TBR ist bezg. Intels binning algorithm identisch. Es gibt kein occlusion culling vor dem shading. Intel sieht den Bandbreiten-Vorteil einfach nur in der Einteilung der Polygone in tiles, welche vollständig im 2nd level cache (256KB) eines Larrabee cores bearbeitet werden können. Dabei wird die tile-Größe der (festen) cache-Größe angepaßt. Im Vergleich zum immediate renderer mit hierarchical depth culling (ATI/NV GPUs) spart das Bandbreite zum Grafikspeicher, weil speziell bei viel overdraw und hohen Auflösungen die texture, depth und color caches nicht groß genug sein können, um erneute Zugriffe auf den Grafikspeicher zu puffern.
TBDR und TBR ist bezg. Intels binning algorithm identisch. Es gibt kein occlusion culling vor dem shading.
Gerade letzteres ist allerdings der Punkt an dem viele Leute TBR und TBDR unterscheiden.
Gerade letzteres ist allerdings der Punkt an dem viele Leute TBR und TBDR unterscheiden.Stimme zu - für mich auch. Eventuell aber für Intel nicht, da im strengen Wortsinne bereits ein deferred rendering im Vergleich zum immediate renderer vorliegt. Daher mein Aussage mit dem Wort 'identisch', quasi als Einschätzung von Intels Sicht der Dinge. Dies ist aber eine Unterstellung, die ich nicht belegen kann. Nichtsdestotrotz, Intel erkennt auch schon bei TBR großes (Bandbreiten-)Einsparungspotential, bedingt durch Larrabees Architektur.
Ein TBDR, also ein TBR mit Polygon-Sortierung zwecks occlusion culling, ist jedenfalls gegenwärtig Spekulation. Ich muß meine Aussage also anteilig revidieren. Meine Unkenntnis des Algorithmus läßt keine Aussage zu, ob hier nun ein TBDR der 'überwiegenden Meinung' vorliegt, oder doch nur ein TBR im wörtlichen Sinne.
Wie auch immer. Das Feature erscheint jedenfalls vorteilhaft im Vergleich zum immediate renderer.
Und wenn es nicht vorteilhaft ist kann man ja immer noch normal rendern. Flexibel ist das Ding ja, das muss man Intel lassen.
Schon ein interessanter Ansatz, aber diese Softwarelastigkeit macht micht doch arg skeptisch.
Und wenn es nicht vorteilhaft ist kann man ja immer noch normal rendern. Flexibel ist das Ding ja, das muss man Intel lassen.
http://arstechnica.com/news.ars/post/20080804-larrabee-intels-biggest-leap-ahead-since-the-pentium-pro.html
Right now, games can take six different paths through Larrabee's software renderer, and the software team intends to add more. Different games will take different paths on different frames, depending on what's optimal for performance. Furthermore, Larrabee's software team can optimize the renderer for specific games by profiling those games and having the renderer recognize them and adapt accordingly.
Das andere GPUs in Tiles einteilen wäre mir aber komplett neu. Es gibt kein Binning auf einer GeForce oder Radeon. Die "Tiles" dort beziehen sich auf die Branching-Granularität. Du bist ja auch noch jung und hast viel zu lernen. Jede gpu (fast, die PS2/PSP macht das nicht) teilt bei der rasterisierung alles in Bins, nur sind es keine Deferred Tiles, sondern werden direkt abgearbeitet. Der Grund dafuer ist nicht dass tiles an sich 'genial' sind, sondern wegen der koherenz von framebuffer-speicher (der schon in dieser anrodnung vorliegt), dadurch erreicht man nebenbei auch eine bessere koherenz bei den texturefetches.
Grobes rasterisieren wird von einer einheit gemacht (also einsortieren in tiles/bins), die einzelnen samples/subsamples koennen dann von anderen einheiten errechnet werden.
Was Larrabee macht ist zuerst alles zu transformieren und es in einer Datenstruktur abzulegen die die Polygone in die "Bins" verteilt. Daraufhin wird jeder dieser Bins gerendert wodurch man komplett in den Cache rendern kann.das was euch hier als so geniale neue technik angeprisen wird, ist nichts neues, so macht man das schon ewig. wieviel in die Bins kommt steigert sich dann auch pro gpu-generation.
und das beim larrabee alles in zwischenspeichern abgelegt wird, waehrend ne 'echte' gpu das in einer pipeline macht (sprich: sehr kleine caches), ist kein tolles 'feature', sondern die loesung fuer ein sonst starkes sync-problem zwischen den 'pixelshading' und 'rasterizer' einheiten (in software).
hier ein sehr altes paper dass ein wenig auf Bins eingeht.
http://www.cs.unc.edu/~olano/papers/2dh-tri/
Bins sind nicht zwingend tiles!
TBR - intel marketing
Bins - intel techniker
Mal deine unglaubliche Arroganz beiseite gelassen, sollte es da zumindest den Unterschied geben dass ein IMR immer nur einen Renderauftrag binnt. Larrabee binnt alles bevor es überhaupt anfängt das Bild zu rendern.
Überhaupt glaube ich du verwechselst dort "binning" bei den Rasterizern damit, dass die Dreiecke nicht mehr in Scanline-Order gerendert werden sondern mit einem cachefreundlicherem Muster. Genau das beschreibt nämlich das verlinkte Paper. Das hat mit den "Bins" die Intel bei Larrabee verwendet aber rein gar nichts zu tun.
Ailuros
2008-09-05, 11:58:59
Schon ein interessanter Ansatz, aber diese Softwarelastigkeit macht micht doch arg skeptisch.
Die wichtigere Frage am Ende (fuer D3D11) wird sein, wieviel SW-lastigkeit gerade genug ist. Ich persoenlich erwarte sowieso eine Tendenz in diese Richtung von allen Seiten, egal was zeitlich jeglicher Marketing-Heini von A,B,C IHV erzaehlen will.
IMG's SGX hat "reine" MIMD Einheiten und es wurde auch hier ein gesundes Prozentual von ff HW entwertet und dabei ist es auch wurscht dass es sich um einen echten TBDR handelt.
Ailuros
2008-09-05, 12:09:17
Das ist doch in Hardware bei den IGPs, oder nicht? Was kann dann da das Treiberteam dafür?
Ich hab keine Ahnung was die IGPs betrifft; ich muss zugestehen dass ich mich mit den Dingern zu wenig beschaeftigt habe. Wenn es auf HW auf den IGPs beruht dann ist die Ohrfeige gegen das chipset Team noch groesser, wenn das Larabee Team es hypothetisch schafft das Zeug in SW anzulegen. Auf den IGPs laeuft das Zeug auf jeden Fall nicht und mir persoenlich ist es auch wurscht ob es sich um verkokste HW oder miese Treiber handelt. Beschissen sind die Intel IGP Treiber ja schon immer. Ich las gerade auf B3D dass sie D3D10 auf einem beta Treiber endlich eingeschaltet haben. Mit 2 Jahren Verspaetung wuerde ich liebend gerne wissen wieso es so lange dauerte heh.....
Und wenn es nicht vorteilhaft ist kann man ja immer noch normal rendern. Flexibel ist das Ding ja, das muss man Intel lassen.
http://arstechnica.com/news.ars/post/20080804-larrabee-intels-biggest-leap-ahead-since-the-pentium-pro.html
Right now, games can take six different paths through Larrabee's software renderer, and the software team intends to add more. Different games will take different paths on different frames, depending on what's optimal for performance. Furthermore, Larrabee's software team can optimize the renderer for specific games by profiling those games and having the renderer recognize them and adapt accordingly.
Flexibel ja, aber wenn das Larabee Treiber Team jegliche Applikation mit profiles fuer optimale Leistung verpassen muss, klingt mir das Ganze persoenlich nicht als Vorteil. Eher in einer Art in Richtung SLi-profiling.
Kann, nicht muss.
Das ist bei den GPUs die wir jetzt haben auch nicht anders.
anddill
2008-09-05, 15:43:48
Kann, nicht muss.
Das ist bei den GPUs die wir jetzt haben auch nicht anders.
Stimmt, da heißt es dann AI :biggrin:
Ailuros
2008-09-06, 08:52:52
Kann, nicht muss.
Ob es muss ist relativ ob man beschissene Leistung haben will oder nicht. Und nein ich meine natuerlich nicht nur die handvoll meistgebrauchten Benchmark-Applikationen.
Das ist bei den GPUs die wir jetzt haben auch nicht anders.
Erstens stecken bei diesen Jahre von Arbeit drin (ergo sie muessen nicht von "0" anfangen) und zweitens will ich ernsthaft bezweifeln dass es bei single GPUs so viele render paths fuer Spiele gibt (ausser natuerlich den problematischen Faellen). Hat der code eines Spiels nicht irgendwelchen Bloedsinn der einer heutigen GPU nicht gut schmeckt oder es gibt nicht irgend eine idiotische "Blase" im Treiber muss der letztere gar nichts anstellen um "optimale Leistung" zu erreichen.
Rein hypothetisch wird es ja schoen und gut sein wenn so ein Ding gut in Crysis z.B. ablegt, aber wehe wenn jemand die "Frechheit" haben sollte einen z.B. x-beliebigen flight simulator auszuprobieren der nie in reviews auftaucht.
Was ich am obrigen nicht verstehe ist wie der SW renderer verschiedene Pfade fuer verschiedene Frames packen will.
Ob es muss ist relativ ob man beschissene Leistung haben will oder nicht. Und nein ich meine natuerlich nicht nur die handvoll meistgebrauchten Benchmark-Applikationen.
Gewagte Aussage, bei vollem Load-Balancing. Ich sehe nicht, dass das Verfahren das sie verwenden irgendwo speziell einbrechen sollte.
Es geht darum in Spezialfällen noch etwas mehr Leistung durch Anpassungen rauszukitzeln, wie bei normalen GPUs auch.
loewe
2008-09-06, 19:09:26
Ob es muss ist relativ ob man beschissene Leistung haben will oder nicht. Und nein ich meine natuerlich nicht nur die handvoll meistgebrauchten Benchmark-Applikationen..
Ich stimme Coda voll zu.
Wenn sie mit dem "Treiber", eigentlich ist es ja eher ein vollwertiges Programm, und dem Scheduler nicht richtig Mist bauen, kann das schon was werden!
Erstens stecken bei diesen Jahre von Arbeit drin (ergo sie muessen nicht von "0" anfangen) und zweitens will ich ernsthaft bezweifeln dass es bei single GPUs so viele render paths fuer Spiele gibt (ausser natuerlich den problematischen Faellen). Hat der code eines Spiels nicht irgendwelchen Bloedsinn der einer heutigen GPU nicht gut schmeckt oder es gibt nicht irgend eine idiotische "Blase" im Treiber muss der letztere gar nichts anstellen um "optimale Leistung" zu erreichen.
Rein hypothetisch wird es ja schoen und gut sein wenn so ein Ding gut in Crysis z.B. ablegt, aber wehe wenn jemand die "Frechheit" haben sollte einen z.B. x-beliebigen flight simulator auszuprobieren der nie in reviews auftaucht.
Nicht so negativ AiL! :)
Auch wenn es sehr lange her ist, sieh dir doch die alten KYRO Treiber an, dort wurde auch für fast jede Aplication ein eigenes Profil im Treiber angelegt und bei vielen war es auch äußerst wirkungsvoll.
Etwas frei programmieren zu können ist ansich erst einmal ein Vorteil, wenn die ganze Sache dann noch schnell genug ist.
Was ich am obrigen nicht verstehe ist wie der SW renderer verschiedene Pfade fuer verschiedene Frames packen will.
Das fand ich nicht so kompliziert. Ich verstehe hier unter Pfand genau das was da steht, grundsätzlich kann jeder Frame auf einem anderen Teil der GPU abgearbeitet werden. AFAIK ist das völlig frei und wird durch den Scheduler entsprechend Auslastung der ALUs bestimmt.
Was mich nur ein wenig irritiert ist, das sie so wie es aussieht zwar einen Tiler bauen aber kein pixelgenaues HSR vor dem Pixelshader machen wollen, also dann eben doch "nur" einen TBR gebaut haben.
Ich denke das ist nicht effektiv und eigentlich schade.
Demirug
2008-09-06, 19:18:24
Was mich nur ein wenig irritiert ist, das sie so wie es aussieht zwar einen Tiler bauen aber kein pixelgenaues HSR vor dem Pixelshader machen wollen, also dann eben doch "nur" einen TBR gebaut haben.
Ich denke das ist nicht effektiv und eigentlich schade.
Patente. Sie könnten durchaus auch noch mit dem was sie jetzt machen wollen Probleme bekommen. Nvidia hat sowas in der Art vor Jahren mal patentieren lassen.
loewe
2008-09-06, 20:13:06
Patente. Sie könnten durchaus auch noch mit dem was sie jetzt machen wollen Probleme bekommen. Nvidia hat sowas in der Art vor Jahren mal patentieren lassen.
Sehe ich ähnlich.
Von der Sache her ist der Larrabee auch dem SGX sehr ähnlich. ImgTec hat zu keinem Zeitpunkt die ALUs oder eben ihre universellen Shader-Einheiten näher definiert, es werden dort ja auch von SGX Version zu SGX Version durchaus verschiedene USSEs verwendet.
Es bleibt trotzdem Schade, es wird viel Potenzial verschenkt. Die am schnellsten Gerenderten Pixel beliben die nicht gerenderten Pixel, ein Tiler gibt ihnen die Möglichkeit sowohl auf das Clipping zu verzichten, als auch wirklich nur die Pixel durch die Shader zu jagen die sichtbar sind, beides nutzen sie nicht mit Larrabee.
Ailuros
2008-09-07, 19:26:12
Ich stimme Coda voll zu.
Wenn sie mit dem "Treiber", eigentlich ist es ja eher ein vollwertiges Programm, und dem Scheduler nicht richtig Mist bauen, kann das schon was werden!
Ich lass mich gerne angenehm ueberraschen, aber das Ganze klingt momentan nur gut auf Papier. Wenn Intel wirklich ernsthaft in den Grafik Markt eindringen will, dann muessen sie sich verdammt gewaltig anstrengen. Und obwohl es sich "nur" um IPGs handelt und es sich tatsaechlich um ein anderes Team handelt, probier mal ein heutiges Intel IGP aus. Nach 2 vollen Jahren wurden erst die angeblichen D3D10 Dinger mit D3D10-Treibern (noch in beta Form) bestueckt und der OGL Treiber ist zum heulen nutzlos.
Nicht so negativ AiL! :)
Auch wenn es sehr lange her ist, sieh dir doch die alten KYRO Treiber an, dort wurde auch für fast jede Aplication ein eigenes Profil im Treiber angelegt und bei vielen war es auch äußerst wirkungsvoll.
Etwas frei programmieren zu können ist ansich erst einmal ein Vorteil, wenn die ganze Sache dann noch schnell genug ist.
Wenn wir schon in der Vergangenheit herumwuehlen muessen, KYROs hatten in ihrem OGL Treiber eine mickrige Anzahl an extensions im Vergleich zu GeForces der Zeit. Dennoch lief das Ganze groesstenteils problemlos. Intel's heutiger OGL Treiber fuer X3xxx hat irgendwo 2.5x mal weniger Extensionen als ein GeForce Treiber, das Zeug laeuft in seiner Mehrzahl eben aber doch nicht wie es sollte. Meine negative oder positive Einstellungen oder Vorbehaltungen haben durchaus zu einem Prozentual geschichtliche Wurzeln und Intel hat mich ueber Jahrzente nicht ueberzeugen koennen dass sie sich wirklich ernsthaft um den Grafik-Verbraucher zu stark scheren, egal was dieser am Ende bezahlt hat.
Um auf's obrige zurueckzukommen ein einfacher "fix" im Treiber (ob transparent oder nicht zum Verbraucher, ob via profile oder nicht ist eigentlich hier egal) ist nicht das gleiche mit einer gesunden Anzahl an rendering-paths.
Von der Sache her ist der Larrabee auch dem SGX sehr ähnlich. ImgTec hat zu keinem Zeitpunkt die ALUs oder eben ihre universellen Shader-Einheiten näher definiert, es werden dort ja auch von SGX Version zu SGX Version durchaus verschiedene USSEs verwendet.
Nur hat jeder USSE nur einen einzigen shader compiler, was zwar nichts mit dem obrigen zu tun hat, aber jemand kann sein Leben schon leicht machen wenn man es will bzw. kann.
Ich lass mich gerne angenehm ueberraschen, aber das Ganze klingt momentan nur gut auf Papier. Wenn Intel wirklich ernsthaft in den Grafik Markt eindringen will, dann muessen sie sich verdammt gewaltig anstrengen. Und obwohl es sich "nur" um IPGs handelt und es sich tatsaechlich um ein anderes Team handelt, probier mal ein heutiges Intel IGP aus. Nach 2 vollen Jahren wurden erst die angeblichen D3D10 Dinger mit D3D10-Treibern (noch in beta Form) bestueckt und der OGL Treiber ist zum heulen nutzlos.
Ich denke nicht, dass Larrabee viel mit den Leuten die die IGPs machen zu tun hat. Völlig andere Technik und ganz andere Ansprüche.
Dein Problem verstehe ich auch nicht. Nur weil sich etwas von Hardware in Software verschiebt und dadurch flexibler wird heißt das noch lange nicht, dass der generelle Pfad schlecht sein muss.
Patente. Sie könnten durchaus auch noch mit dem was sie jetzt machen wollen Probleme bekommen. Nvidia hat sowas in der Art vor Jahren mal patentieren lassen.
sie wollen den leuten lediglich eine leistung bieten die zu den jetzt gemachten spielen auch passt. wenn man pixelgenaue HSR haben will, muss man einen ZPass machen. Die leute waeren schwer angepisst wenn ihr zpass die sache noch langsammer machen wuerde, nicht so sehr die entwickler, als eher die user. dann haette intel sich viel mehr arbeit gemacht in software ihren zpass zu machen um anschliessend schlecht dazu stehen.
deswegen nur ein TileBasedRendering, ohne deferred.
loewe
2008-09-07, 20:59:12
Ich lass mich gerne angenehm ueberraschen, aber das Ganze klingt momentan nur gut auf Papier. Wenn Intel wirklich ernsthaft in den Grafik Markt eindringen will, dann muessen sie sich verdammt gewaltig anstrengen. Und obwohl es sich "nur" um IPGs handelt und es sich tatsaechlich um ein anderes Team handelt, probier mal ein heutiges Intel IGP aus. Nach 2 vollen Jahren wurden erst die angeblichen D3D10 Dinger mit D3D10-Treibern (noch in beta Form) bestueckt und der OGL Treiber ist zum heulen nutzlos.
Wenn man es richtig macht kann solch ein Design durchaus funktionieren, davon bin ich überzeugt. In einigen Jahren werden alle GPUs so ähnlich aussehen, denke ich.
Zum Thema IGP von intel, mit dem Poulsbo ist ja der erste IGP auf SGX Basis im Markt und wie nicht anders zu erwarten, die intel Treiber sind sch...! :(
Was ich daran nicht verstehe, sie haben von PowerVR funktionierende Treiber, bringen aber einen Treiber, der 3D nicht oder nur minimal unterstützt. Kann das einer erklären?
Wenn wir schon in der Vergangenheit herumwuehlen muessen, KYROs hatten in ihrem OGL Treiber eine mickrige Anzahl an extensions im Vergleich zu GeForces der Zeit. Dennoch lief das Ganze groesstenteils problemlos. Intel's heutiger OGL Treiber fuer X3xxx hat irgendwo 2.5x mal weniger Extensionen als ein GeForce Treiber, das Zeug laeuft in seiner Mehrzahl eben aber doch nicht wie es sollte. Meine negative oder positive Einstellungen oder Vorbehaltungen haben durchaus zu einem Prozentual geschichtliche Wurzeln und Intel hat mich ueber Jahrzente nicht ueberzeugen koennen dass sie sich wirklich ernsthaft um den Grafik-Verbraucher zu stark scheren, egal was dieser am Ende bezahlt hat.
Was meinst du hier, die OGL Extensions oder Optionen des Treibers? Wenn Extensions fehlen, werden bestimmte Feature durch den Treiber, aber wohl auch durch die Hardware, nicht unterstützt. Das geht dann halt nicht.
Um auf's obrige zurueckzukommen ein einfacher "fix" im Treiber (ob transparent oder nicht zum Verbraucher, ob via profile oder nicht ist eigentlich hier egal) ist nicht das gleiche mit einer gesunden Anzahl an rendering-paths.
Du sagst es!
Aber bei Larrabee ist nahezu alles programmierbar, es muss dann nur noch schnell genug sein; sprich mit einem guten Treiber bei Larrabee sollte man eigentlich alles zum Laufen bringen können. Mag sein das manches Spiel dann mit 1FPS läuft, aber es sollte auf jeden Fall toll aussehen! :biggrin:
Ailuros
2008-09-08, 12:54:37
Ich denke nicht, dass Larrabee viel mit den Leuten die die IGPs machen zu tun hat. Völlig andere Technik und ganz andere Ansprüche.
Und es haelt Intel inwiefern davon ab fuer anstaendigere Treiber im Vergleich zur IGP Konkurrenz zu liefern? Was mir an Intel generell bis jetzt nie richtig geschmeckt hat, ist ihre Gleichgueltigkeit und nein die IGP der Konkurrenz sind auch nicht teurer am Ende.
Dein Problem verstehe ich auch nicht. Nur weil sich etwas von Hardware in Software verschiebt und dadurch flexibler wird heißt das noch lange nicht, dass der generelle Pfad schlecht sein muss.
Nein heisst es tatsaechlich nicht; aber meine jegliche Vorbehaltungen sind durchaus nicht ungerechtfertigt.
Wenn man es richtig macht kann solch ein Design durchaus funktionieren, davon bin ich überzeugt. In einigen Jahren werden alle GPUs so ähnlich aussehen, denke ich.
Zum Thema IGP von intel, mit dem Poulsbo ist ja der erste IGP auf SGX Basis im Markt und wie nicht anders zu erwarten, die intel Treiber sind sch...! :(
Was ich daran nicht verstehe, sie haben von PowerVR funktionierende Treiber, bringen aber einen Treiber, der 3D nicht oder nur minimal unterstützt. Kann das einer erklären?
Weil sich eben seit Jahren bei Intel kein Schwein richtig ueber Grafik schert. Hauptsache man verkauft gut, der Rest ist "nebensaechlich".
Was meinst du hier, die OGL Extensions oder Optionen des Treibers? Wenn Extensions fehlen, werden bestimmte Feature durch den Treiber, aber wohl auch durch die Hardware, nicht unterstützt. Das geht dann halt nicht.
Intel's X3xxx ist nach Intel ein D3D10 IGP und sollte um viel mehr faehig sein als nur OGL 2.0.
Du sagst es!
Aber bei Larrabee ist nahezu alles programmierbar, es muss dann nur noch schnell genug sein; sprich mit einem guten Treiber bei Larrabee sollte man eigentlich alles zum Laufen bringen können. Mag sein das manches Spiel dann mit 1FPS läuft, aber es sollte auf jeden Fall toll aussehen! :biggrin:
Zu viel Programmierbarkeit und/oder Flexibilitaet koennte eventuell auch zum Bumerang werden. Irgendwann in der weniger vorhersehbaren Zukunft wird ff HW hoechstwahrscheinlich erneut erscheinen; solche Zyklen sind ja normal in diesem Markt. Ich bezweifle nirgends dass Intel nicht den "Weg" finden koennte mit Larabee; meine Zweifel liegen eher in Richtung "Wille"....
Und es haelt Intel inwiefern davon ab fuer anstaendigere Treiber im Vergleich zur IGP Konkurrenz zu liefern?
Ich würde mal sagen, dass sowieso fast niemand mit IGPs spielt. Das ist einfach keine große Priorität.
Intel's X3xxx ist nach Intel ein D3D10 IGP und sollte um viel mehr faehig sein als nur OGL 2.0.
Mehr als 2.0 verwendet sowieso kein Spiel. NVIDIA hat vor allem so viel Extensions weil sie noch viel altes Zeug von sich selber drin haben.
Und überhaupt, OpenGL ist tot. Sogar Rage wird wahrscheinlich D3D9 als Backend haben unter Windows.
Ailuros
2008-09-08, 20:33:02
Ich würde mal sagen, dass sowieso fast niemand mit IGPs spielt. Das ist einfach keine große Priorität.
Schoen. Ich hab aber trotzdem mehr Grund als Verbraucher in jeglichem Schlepptopp-Kauf ein Intel IGP wie der Teufel das Weihwasser zu vermeiden, wenn ich weiss dass auf anderen Dingern zumindest das minimalste anstaendig genug laufen kann. Und die Entschuldigung fuer Intel ist genauso mies wie Intel's Einstellung: zu jeglicher Grafik-einheit gehoert ein anstaendiger Treiber.
Mehr als 2.0 verwendet sowieso kein Spiel. NVIDIA hat vor allem so viel Extensions weil sie noch viel altes Zeug von sich selber drin haben.
Doom3 als Beispiel laeuft auf X3xxx eben nicht; warum sollte es auch? Wenn man sowieso kein Zeug wie Crysis mit IGPs beruehren kann, wuerde wohl doch jemand erwarten dass man zumindest etwas aeltere Spiele auf dem Mist laufen.
Und überhaupt, OpenGL ist tot. Sogar Rage wird wahrscheinlich D3D9 als Backend haben unter Windows.
Fuer Intel war es schon anscheinend schon immer tot. Dabei frage ich mich ernsthaft wieviel Muehe und Unkosten es wirklich brauchen wuerde einen anstaendigen OGL Treiber zu schreiben. IMG hat nur 40 Treiber-fritzen afaik und dennoch unterstuetzen sie zich APIs und SW-Platformen problemlos.
MadHatter666
2008-09-08, 20:44:21
Und überhaupt, OpenGL ist tot.
Schön wärs, wenns nicht nur im Spiele-Sektor so wäre...
Fuck Quadro :mad:
Demirug
2008-09-08, 20:52:06
Fuer Intel war es schon anscheinend schon immer tot. Dabei frage ich mich ernsthaft wieviel Muehe und Unkosten es wirklich brauchen wuerde einen anstaendigen OGL Treiber zu schreiben. IMG hat nur 40 Treiber-fritzen afaik und dennoch unterstuetzen sie zich APIs und SW-Platformen problemlos.
OGL ist so ziemlich der übelste Sumpf den es inzwischen gibt. Alleine die ganzen gegenseitigen Abhängigkeiten der ganzen Extensions sind kaum noch beherrschbar.
Und bitte nicht mit OGL ES verwechseln. Da hat man ja mal aufgeräumt.
Ailuros
2008-09-09, 10:03:35
OGL ist so ziemlich der übelste Sumpf den es inzwischen gibt. Alleine die ganzen gegenseitigen Abhängigkeiten der ganzen Extensions sind kaum noch beherrschbar.
Und bitte nicht mit OGL ES verwechseln. Da hat man ja mal aufgeräumt.
Demi kein Zweifel. Intel ist aber als IHV nicht (zumindest theoretisch) abwesend vom ganzen OGL Entwicklungs-prozess.
Natuerlich ist OGL_ES um einiges besser und IMHLO eher weil nur ein IHV die ersten Fundamente fuer OGL_ES1.0 damals legte. Nebenbei wuerde es mich kein bisschen wundern wenn in der weniger absehbaren Zukunft OGL_ES OpenGL irgendwann mal aufsaugen wuerde.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.