PCTuning fórum

s tou politikou nv mas pravdu do puntiku. Ale z poslednich let vidime ze se jim ta politika uz prestava vyplacet a firma defakto ztraci na vsech frontach. Mozna by to chtelo totalne vymenit vedeni co je odpovedne za marketing a prezentaci firmy na verejnosti.

A Sony jsem slyšel že koketuje s PowerVR což by byla bomba protože jejich tile-based rendering je mnohem efektivnější než ta hrůza na který funguje ATI nebo NV.

No už je to dost dávno , co se mluvilo o Kyro III a následně o Kyro IV

http://www.anandtech.com/show/558/3

http://www.theregister.co.uk/2001/06/11 ... _kyro_iii/

http://www.segatech.com/powervr/kyro3/index.html



a testik z Xbitlabs : http://ixbtlabs.com/articles/kyro2/

A přesto že tato architektura je velice zajímavá, tak její zásadní problém co si pamatuju je to, že jednak mělo STM Microelectronic/PowerVR problém implementovat hardwarovou T&L jednotku, což se nakonec asi nějak podařilo, ale s DX8.1 a DX9 se postupně začínaly objevovat hry, které začínaly ve větší míře využívat postprocessing efekty a to byl velký problém pro kartu která měla stále základy v DX6/DX7. Tyto efekty neumožňují využívat ani určité módy Multi GPU na dnešních kartách. (ATi Cross Fire A Nvidia SLI).

PowerVR později uvolnilo PowerVR Pixel and Vertex Shader 3.0 Demos http://forum.beyond3d.com/archive/index.php/t-7486.html ale to běželo přes softwarovou emulovanou DX8....

Problém je že se SMT Microelectronic/PoweVR nikdy nepodařilo implementovat plný DX 8.0 Pixel shader, problém je ten že by Microsoft musel pro tuto architekturu přepsat DX8.0 nebo respektive dodělat něco jako DX8.0 TBR extension, aby tyto karty mohly zůstat u tohoto způsobu vykreslování scény a zároveň používat programovatelnou shader jednotku. Microsoft se na to vys.ral a STM Microelectronic/PowerVR s relativně velice malým podílem na trhu nemělo možnost jak Microsoft k něčemu takovému donutit. Kdyby žilo 3dfx a vydalo svůj čip na architektuře Gigapixel, tak by to asi Microsoft ke změnám donutilo.....Nvidia bohužel Gigapixel pohřbila uplně....

Yes but these DX8-PVR-demos only use DX8 as a softwarelayer, but still run on DX7 hardware like KyroII and are designed to run on KyroI/II. The new DX9 demos on the other hand NEED PS/VS 3.0. So you should think about it! This is mentioned wrong at xbitlabs.com news too!

Series4 was an 250MHz DX7 part, not an DX8 part. Ailuros gave this info at 3DCenter.de. The Kyro3 should have been released at the end of 2001 or beginning of 2002. The Kyro3 would have been updated at the end of 2002 toward 300MHz. If you compare the Kyro2 ( 2x175) with the Kyro3 (4x250) the performance would have been very good even today. Especially when you include the rumored FSAA4FREE feature.

I think the truth is somewhere in the middle. I think PowerVR Series 4 would have had a Vertex Shader, but probably no Pixel Shader. Why i think so?...You can read it in the EE Times Interview:
Metcalfe said development of the Series-4 architecture of PowerVR was dropped when STMicroelectronics, a licensee of earlier PowerVR architectures, decided to pull out of the PC graphics chip market

The kYRO series is a different story. The architecture works as advertised out the box (no failed promises of a "powerful" T&L as with the S2K), the drivers are quite stable, the price is cheap, and the product simply works as expected. Is the K2 a GF3? No where near it, but most users could really give a care. Each card will play most popular games at 1024x768. Better yet, how many popular games actually require (not support, but require!) T&L or require pixel shading rendering conventions?

MS screwed the deployment of pixel shading by rushing the pathetic, non-standardized conventions available within DX8. Not until DX9 does MS plan to offer a hardware independant pixel shading interface. When DX9 software (not the interface, but actual programs!) is released to the public, we will be discussing the NV30, R300, and whatever next-gen chipset Matrox (G800 name no longer is valid) is currently developing. The K3 is simply not needed right now, as it does not follow STM's marketing approach. STM delivers results by providing hardware that provides acceptable performance across a wide varity of games at decent resolution and bit-depth; not lame PR reports that tell users about the wonders of upgrading to a "next-gen" product to increase their warped conceptualization of a benchmark score in 3DMark2001 by 5%.

Still, hardware T&L (though this is now an archaic terminology in the new world of custom graphics pipelines) is on its way for the KYRO series of chipsets. I expect STM to release a quite effecient solution, as the PVR architecture has been implemented with external T&L solutions within arcade systems for quite a long time now.

no a pak s pětkou se pak uplně přeorientovali na mobilní telefony a mobilní zařízení..... a to je konec story


Z.

Vyčerpávající post Jen bych se rád zeptal o jakých pokročilých post-processing efektech a módech Multi-GPU byla řeč? Dnešní CF/SLi využívají především AFR a veškeré dnes používané efekty jako např. indirect lightning a deferred shading/lightning zvládá.

už si přesně nepamutuju, ale v podstatě všechny které využívají programovatelných shaderů : motion blur, depth of field, soft shadow, light blooms, hdr, atd.

Co se týká těch Multi GPU, nevím jak je to dnes, ale pamatuji si že některé méně používané režimy měly za následek to , že nefungovaly ve Hrách (nebo špatně) postprocessing efekty.řešilo se to tím, že se ve hře tyto efekty vypnuly nebo tak že pokud existoval SLI profil pro konkrétní hru, tak ten už měl tyto tweaky v sobě.

Z.

Kyro III nikdy vydána nebyla a přesto z ní NV měla snad ještě větší vítr znež z teoretické 3dfx Rampage.

Co se TnL týče tak ta alespoň co jsem měl tu čest testovat KyroII, tak vůbec nechyběla, ta karta měla lepší 3Dmarky než Geforce a 3Dmarky byly doslova optimalizovaný na Nvidiáckou TnL. Navíc NV sama měla TnL jen na GF256, GF2. Na ostatních kartách kde byly už vertex shadery se TnL jen emulovala přes vertex shader.

Pokud Kyro III měla bejt 3x rychlejší než KyroII, kde by to asi tímto tempem bylo dnes. Tyhle newsky jsou všechny 2000-2001. Pak se PowerVR stahlo z PC trhu (nevim už přesně jak to bylo, myslim že v tom měla prsty NV), nicméně dodnes dělá nejpoužívanější čipy do mobilů smartphonů, atd. OpenGL maj velice solidně zvládnutý, dokázali by navrhnout hodně solidní čip, to beze sporu. A o ňákou DX kompatbilitu se nikdo starat nemusí, zpětná kompatibilitau konzolí stejně není žádána a pro konzole se bude programovat od prvních devkitů, ne s hledem na to jaký jsou ty dnešní.

Co se 3Dfx a Gigapixelu týče, nevím otom že by ňěco na tom vůbec plánovala, Rampage s tím neměla co dělat, byl to klasickej čip 3DFx rázu, klasickej rendering, velkej důraz na kvalitu obrazu, velkej hrubej výkon, perfektní škálovatelnost v multiGPU. Ale že by ta architektura byla ňák efektivní to ne, ihmo koncept byl ten jako má NV či ATI, ostatně ti to od 3Dfx přebrali. ala dosahnout výkonu hrubou silou, ne až tak moc optimalizacemi.

Kyro III nikdy vydána nebyla a přesto z ní NV měla snad ještě větší vítr znež z teoretické 3dfx Rampage

ano to všichni víme, jen jsem připomenul, že takhle nějak vypadaly původní specifikace

PowerVR serie 2 byl použit v konzoli Dreamcast v roce 1998 -2001, byl licensován NECu

v roce 2001 STM microelectronic uvedla svoji novou sérii PowerVR 3 (Kyro I a Kyro II)

Pak mělo přijít Kyro III ale protože se vývoj táhl a Kyro III bylo v podstatě "Kyro II s T&L jednotkou" (čip měl stále základ ve specifikacích DX7) a vše směřovalo k programovatelným shaderům, PowerVR přeskočilo tuto generaci a začalo pracovat na Kyro IV (PowerVR 5) s hardware T&L a DX8 a programovatlenými shadery.

celé se to komplikuje tím, že v roce 2002 chce STM microelectronic prodat grafickou divizi a není kdo by nové Kyro vydal.... V té době se o Kyro zajímala také VIA, která ale nechtěla koupit celou grafickou divizi, spíše ji zajímalo Kyro jako takové .

Jinak PowerVR je divize společnosti Imagination technologies a se samotným STM Microelctronic nemá nic společného.

Všechny tyto komplikace, neochota Microsoftu spolupracovat na DX8, chybějící peníze, problémy s implementací DX8 TBR a chybějící silný partner v podobě STM Microelectronic vedly k tomu že se nakonec žádné KYRO IV nevydalo.

Proto se PowerVR soutředilo na SGX Series5 Graphics IP Core Family , který vychází z původního návrhu pro Kyro IV, ale soustředí se primárně na platformu Open GL(OpenGL ES 1.1/2.0, OpenVG 1.1, OpenGL 2.0/3.0) Čip sice podporuje i DirectX 9/10.1 ale nejspíše jen softwarově....

Co se 3Dfx a Gigapixelu týče, nevím otom že by něco na tom vůbec plánovala, Rampage s tím neměla co dělat, byl to klasickej čip 3DFx rázu, klasickej rendering, velkej důraz na kvalitu obrazu, velkej hrubej výkon, perfektní škálovatelnost v multiGPU. Ale že by ta architektura byla ňák efektivní to ne, ihmo koncept byl ten jako má NV či ATI, ostatně ti to od 3Dfx přebrali. ala dosahnout výkonu hrubou silou, ne až tak moc optimalizacemi.

Co se 3dfx týče, tak snad každý fanoušek pamatuje, že 3dfx koupila společnost Gigapixel v roce 2000, protože Gigapixel měl velice schopné inženýry a také proto, že Gigapixel byl jedním z uchazečů o grafický čip pro novou konzoli Microsoftu X-box. Jejich čip GP-1 využíval technologii TBR.

One of the most interesting things we saw at the show was GigaPixel showing off an actual working board, their GP-1. Vaporware it is not.

Founded in August of 1997, GigaPixel offers IP (intellectual property) cores for the products of others. That means they don't plan on selling any boards of their own, rather, they plan on selling their design to others.

Highlights of their GP-1 design include: 4x, jittered, multi-sample anti-aliasing at full speed, visibility culling, and improved memory bandwidth handling.

Visibility culling is achieved through a system somewhat like VideoLogic's PowerVR series. The GP-1 takes 32x32 pixel tiles, determines what polygons are visible, and ignores the unseen polygons. This allows the GP-1 to render far fewer textures than traditional cards, which render every polygon. This technique saves heavily on memory bandwidth, especially in newer games with more complex scenes. GigaPixel claims around a 10X cut in memory usage. While seeming a bit disappointed at not being in the X-Box, GigaPixel's booth was still upbeat with a side-by-side comparison between their GP-1 and a GeForce running Quake III Arena with AA turned on. The GeForce was running NVIDIA's newest drivers, which have a button to turn on software AA. Not only was the GeForce running significantly lower frame rates with AA on, but the software AA looked significantly worse than GigaPixel's hardware AA. GigaPixel told us the box had a 100MHz GP-1 inside.

They also told us they had three licensees. They wouldn't give any names, but since we heard Microsoft was a major investor in GigaPixel and since GigaPixel expected their technology to be used in the X-Box, we're pretty certain that Microsoft is one of those licensees.

http://www.sharkygames.com/hardware/art ... 00/3.shtml

GP-1 was able to run Quake III at 200 fps at 1024 × 768. The chip 32-bit working along the pipeline while it is unclear that the geometry of the memory controller would have a controller with multi-channel bus, type crossbar but, in fact, was not a crossbar (remember that the first crossbar chip type consumer will be seen on the NV20, aka GeForce 3).

GP-1 fill rate 500 Mpixels/s , texel fill rate 2 Gtexels/s
clock 125 MHz

vyvíjené
GP-2 732-Mpixel/s fill rate
clock 183 MHz, texel fill rate 5.9 Gtexels/s

http://www.theregister.co.uk/1999/10/06 ... n_3dfx_s3/

http://tweakers.mobi/nieuws/6367

http://electronicdesign.com/article/dig ... tion-.aspx

Tato vlastnost se částečně přenesla do posledních oficiálních beta ovladačů od 3dfx a je známá jako HSR (Hidden surface removal)



http://www.anandtech.com/show/683

http://www.anandtech.com/print/558

po Voodoo 4/5 mělo přijít Rampage, které ještě využívalo klasickou rasterizaci, po něm čip Fear a nakonec Mojo ( a to měl být právě první čip vycházející z technologie Gigapixelu )


http://ixbtlabs.com/articles/3dfxtribute/index.html

http://forums.guru3d.com/showthread.php?t=171176

http://www.pcgameshardware.com/aid,6705 ... ws/?page=4

Z.


PS: více vám k tomu řekne Jirka souček (No-X)

Tož jak funguje HSR na V5 vim, škoda že artefaktí a jde jenom v Q3. Ono na VSA-100 čipu je to stejně jen SW forma. Rampage měla mít už HW HSR.

Zajímavé jsou taky obrovské nárůsty výonu při tom HSR. O HSR se později mluvilo i v souvislosti s ATI a NV že to tam "jako teď už od týhle generace maj", ale v praxi nikdy nikde nic vidět nebylo, žádný boosty v FPS se nikdy nekonaly.

A Mojo... no, o tom se neví zhola nic, respektive, asi tolik co o Fermi 2 měsíce před vydánim G80. Jen se ví že ATI R300 později byla taky codename "Mojo".... zvláštní toť fakt.

DOC_ZENITH píše:O HSR se později mluvilo i v souvislosti s ATI a NV že to tam "jako teď už od týhle generace maj"

Myslím, že implementovali akorát nějaké formy "cullingu/tilingu" ale ty využívají jiných algoritmů než byl původní 3Dfx HSR.

Tahle diskuze plná nostalgie je sice fajn, ale měli bychom se vrátit k původnímu tématu, tj. GPU (APU) pro next-gen konzole.

přesně tak a z toho vyplývá jen to, že žádný čip s TBR se v budoucích konzolách neobjeví

S dovolením bych rád uvedl na pravou míru pár podivností.

PowerVR nemělo s implementací TnL problém, ale usoudilo, že čipy výkonností úrovně ho nepotřebujou. A skutečně nepotřebovaly. TnL byl marketing nVidie, žádný jiný výrobce do toho tehdy nešel, protože to považoval za zbytečnost a skutečně to zbytečnost byla.

Problém s PP efekty byl - konkrétně v tom, že rádius různých PP filtrů se blížil velikosti tiles, takže by bylo třeba pro velkou část okrajových pixelů PP efekty přepočítávat. Pokud vím, uvažovalo PowerVR o implementaci jakýchsi macro-tiles (tzn. větších úseků), takže by sousedící pixely zabíraly procentuelně menší část z celého obrazu. Netuším, do jaké fáze se to dostalo.

Není pravda, že PowerVR nemá víc než DX7 čip. V roce 2005 uvedli SGX jako unifikovaný čip technologicky přesahující DX9/SM3.0, po vydání DX10 ohlásili, že splňuje i specifikace DX10 a po ohlášení DX10.1 se opakovalo totéž. Takže měli vůbec jako první DX10 a DX10.1 čip...

HSR na VSA-100 byla čistě SW záležitost, která nikdy nebyla dotažená do použitelné podoby (a podle lidí z 3Dfx by ani v případě, že by 3Dfx jela dál, na tom už nikdo nepracoval).

Rampage měla HSR používat, ale mělo jít o nějaký hybrid HW a SW implementace.

Gigapixel HSR bylo něco jiného, jelikož to byl tiler, tak nebyl problém na úrovni tile spočítat nejdřív celou geometrii a rendering začít v okamžiku, kdy je jasné, co vidět bude a co ne. To je jako u Power VR. Oproti tomu HSR na VSA-100, rampage, GeForce 3, Radeonech 7xxx a dalších podobných čipech bylo o něčem jiném. Je to složitější a hlavně ne 100% účinné.

Jinak ATi Xenos v Xboxu 360 používá v podstatě tile-based rendering, jen s tím rozdílem, že používá 1-2 tiles na celou obrazovku - v podstatě něco jako macro-tiles, nebo spíš mega-tiles

ještě k tomu renderování pomocí TBR:

http://www.beyond3d.com/content/articles/38/1

http://www.imgtec.com/factsheets/SDK/Po ... ternal.pdf

The problem with this deferred rendering approach is the fact that the entire scene must be cached before rendering. This "scene buffer" effectively takes the place of the z-buffer. The objection I have to this approach is that the size of the scene buffer is unknown before rendering, and so there are always going to be possible buffer overflow issues which could drastically impact performance. By contrast, the z-buffer's size is well-known prior to rendering. Immediate-mode renderers (pretty much any GPU available today) also have a number of techniques that improve efficiency, so I don't see a reason to go "all the way" to deferred rendering to solve problems that, in my mind, don't really need solving given today's rendering performance.
TBDR method of rendering polygons today is useful/efficient for small-scale implementations where power and memory bandwidth factors are a major concern, related to the target performance. All modern immediate rasterizer architectures from ATi, NV and the few others, are already using advanced methods of hierarchical representations of the depth information, fast caching and real-time compression of the data. And with the advent of APIs like OpenCL and DirectCompute, the monstrous ALU power of the GPUs can be harnessed to perform advanced GFX tasks like SSAO and OIT much more efficient, bypassing the traditional graphics pipeline methods, treating the GPU as a pure massive parallel compute device

No-X:PowerVR nemělo s implementací TnL problém, ale usoudilo, že čipy výkonností úrovně ho nepotřebujou. A skutečně nepotřebovaly. TnL byl marketing nVidie, žádný jiný výrobce do toho tehdy nešel, protože to považoval za zbytečnost a skutečně to zbytečnost byla

To že bylo Nvida T&L v době svého uvedení spíše jakýmsi "hype" to všichni víme, ale snadná ta implementace T&L do této architektury nebyla....Dnes už se těžko dohledávají ty články o tomto tématu, některé z těch stránek už neexistují, ale x-3dfx fóru se o tom hodně debatovalo.
Máš pravdu v tom, že v té době ji Kyro v podstatě nepotřebovalo a PowerVR ji tam dala spíše jaksi z "nutnosti", ale tímto směrem se vývoj grafik ubíral a bylo potřeba na to reagovat. 3dfx se to taky vymstilo.Nejdříve tvrdili jak je "nepotřebná" 32bitová barevná hloubka a pak jak "zbytečné" je T&L a kde je jim konec ??? (a to říkám jako jejich bývalý největší fanda)

PowerVR se používalo v herních automatech spolu s dedikovanou separátní T&L jednotkou, což by prodražilo výrobu karet Kyro II s T&L, proto muselo PowerVR předělat celý návrh čipu, pokud chtělo mít "all in one" chip s hardwarovým T&L.

Kyro II graphics card worked great and was a lot faster then the other graphics cards based on brute force in the pre T&L era.
After T&L was becoming more prevalent, the PowerVR became to expensive when compared because it needed a seperate DSP without redesigning the powervr principle

Interview with Imagination Technologies http://ixbtlabs.com/articles/interviewimaginationtech/



A další upřesnění je že, já netvrdím že PowerVR nemá DX9/10 hardware, jen říkám že v době plánovaného uvedení architektury pro Kyro III (series 4) to byl stále jen DX7 čip s emulovanými efekty DX8 (nic víc nic míň)

Možná jsem to jen špatně vyjádřil, ale do DX9.0 nebylo možné odděleně pracovat s pixel/vertex shadery, které byly předtím fixně svázané ve specifikacích DX8. Tam nemělo PowerVR možnost jak s TBR a programovatlenými shadery spolupracovat.

Edit předchozí příspěvek: měl jsem tam chybu, nepřesnosti opraveny

Moc se už PowerVR nezajímám, protože tyto karty de-facto vymizely z hráčského trhu a jak je to s jejich hardwarovou implementací DX10 doopravdy to nevím, protože tak hluboko do té architektury nevidím a neznám její přesné podrobnosti. Možná že nakonec PowerVR tu architekturu překopala mnohem víc než jsem se původně domníval, nicméně pravdou je stejně to že se mnohem více zaměřují na Open GL (OpenGL ES 1.1/2.0, OpenVG 1.1, OpenGL 2.0/3.0) Nicméně zajímavé na tom je to, že ve veškerých oficiálních prezentacích výhod PowerVR architektury jsou prezentovány výhradně benchmarky na bázi Open GL.

Series 5 (čili potencionální Kyro IV) využívá Universal Scalable Shader Engine (USSE) v každé pipeline, což je škálovatelný multithreaded GPU engine schopný zpracovávat jak grafické, tak i jiné matematicky náročné úlohy. Lze jej programovat GLSL jazykem, který je součástí OpenGL ES 2.0 specifikace, případně paralelním jazykem postaveným na C použitým v OpenCL.

Ať už je to s podporou DX 9/10 a podporou programovatelných unifikovaných shaderů jakkoliv, tato architektura má zřejmě svoje slabiny a úskalí, protože jinak by se jí dávno chopil nějaký velký výrobce (včetně Nvidie , která vlastní patenty Gigapixelu) a začal prodávat/navrhovat grafické karty na tomto principu





Ke Xenosu:

NO-X:Jinak ATi Xenos v Xboxu 360 používá v podstatě tile-based rendering, jen s tím rozdílem, že používá 1-2 tiles na celou obrazovku - v podstatě něco jako macro-tiles, nebo spíš mega-tiles

tím ale ztrácí výhoda TBR smysl, protože její síla spočívá v rozdělení scény na malé části , tiles.


O Xenosu je velice výživný článek tady na http://www.beyond3d.com/content/articles/4/5

As with ATI's current desktop parts, Xenos features a Hierarchical Z buffer. Hierarchical Z buffers contain "coarser" Z information than the full resolution Z buffer - usually Hierarchical Z buffers are tiled down versions of the full resolution Z buffers and the highest Z value of that tile is stored for that group of pixels. In Xenos's case the Hierarchical Z Buffer stores down to 16 sample groups, which equates to 2x2 pixel groupings with 4x FSAA enabled. Once a triangle is setup, its pixel coverage areas can be compared against the Hierarchical Z buffer and if all of their Z values are greater than the value on the tile then they can all be rejected before any work is carried out, however if some are lower then they will be compared against the full resolution Z buffer. Because the Hierarchical Z Buffer exists on chip the checking operation is very fast and can also reject numerous pixel groups in a single cycle. Xenos can discard up to 64 pixels per clock cycle based on hierarchical z. As the Hierarchical Z buffer is populated on the Z only pass it will have the final Z values for its tile coverage when the full pass is done. This will result in more efficient use of the Hierarchical Z buffer in comparison to normal (PC) graphics processors on software that doesn't have an early Z only rendering pass built within the engine.

Xenos čip používá tilling jen při použití FSAA na HDTV protože eDram 10MB(integrovaná pamět) je pro použití FSAA jako backbuffer nedostatečná. Zřejmě tedy nejde o TBR rendering jako takový, ale tento algoritmus je využit jen při připojení X-boxu k HDTV nebo jinému zobrazovacímu zařízení s vysokým rozlišením výhradně ve spojení s FSAA. Při běžném rozlišení nebo vyšším , ale bez FSAA je použit klasický rendering ve spojení s Hierarchical Z buffers.Viz obrázek:

With the eDRAM being the primary rendering target for Xenos there looks to be a potential issue with rendering FSAA at High Definition TV (HDTV) resolutions: space. With only 10MB of rendering space available, the resolutions and FSAA depths that can be natively supported by the eDRAM could be limited

proto Xenos dělí scénu na menší části, aby se vešly do eDram jako back bufferu pro FSAA.

At the moment XBOX 360 is supporting 720p (progressive scan) and 1080i (interlaced) resolutions - 720p equates to 1280x720 pixels and 1080i equates to 1920x1080 pixels, however interlacing means that only the odd horizontal lines are refreshed on one cycle and the even lives on the next, which means that the frame buffer is only ever needing to handle 1920x540 pixels per refresh.

Here are the frame-buffer sizes for these HDTV resolutions and 640x480 with a colour depth of 32-bit (which will cover both the standard integer 32-bit format and the FP10) and a 32-bit Z/stencil buffer. Naturally, the sizes will increase if a higher Z-Buffer depth or a higher bit colour depth is used:



As we can see, with these bit depths, all the resolutions will fit into the 10MB of eDRAM without FSAA and at 640x480 a 4x FSAA depth will stay within the eDRAM memory size, with these colour and Z depths. However, at HDTV resolutions nothing can fit into the 10MB of eDRAM with any mode FSAA enabled. Xenos was specifically designed to perform very well in these cases by dividing the screen into multiple portions that fit within the eDRAM render buffer space. This is similar to prior tile-based renderers, but with a much larger base tile and with additional functionality to optimize the tiling approach

ATI have been quoted as suggesting that 720p resolutions with 4x FSAA, which would require three tiles, has about 95% of the performance of 2x FSAA.

Taking the previous sampling requirements, the memory quantities required resolved to the following number of tiles being required:



Render to texture operations that have space requirements beyond 10MB can also operate in the tiled mode, however given that Xenos is going into a closed box environment its likely that developers of the system will consider what best fits the design of the console when they are developing their titles.

del42sa píše:tím ale ztrácí výhoda TBR smysl, protože její síla spočívá v rozdělení scény na malé části , tiles.

Ne, výhoda TBR spočívá v tom, že je obraz rozdělen na tak malé úseky, k jejich žpracování (Z-buffer) stačí interní paměť čipu, ke které je mnohem rychlejší přístup. Díky tomu je možné realizovat MSAA s minimálními dopady na výkon (to v desktomu PowerVR zrealizovat nestihlo, ale Gigapixel ano, proto měl propady s MSAA tak nízké) a že není třeba hardware pro kompresi z-bufferu.

Takže se tím ušetří tranzistory čipu a náklady na externí paměť se sníží (rychlost, kapacita, šířka sběrnice, pinout). U Xenosu tyhle výhody neodpadávají, jen je tile dlaždice (a tím pádem i interní paměť - zde v podobě EDRAM) výrazně větší. Ale základní myšlenka je stejná.

Z hlavy si nejsem jistý, kdyžtak mě oprav. Na první verzi Xenosu byla 10MB EDRAM vyráběná 110nm technologií a měla 100mm². Pokud bychom uvažovali o 32nm výrobě se zachováním 100mm² plochy, mohli bychom vytvořit 120MB EDRAM. Kdybychom ji udělali 128MB, vešlo by se do ní 1920*1080 @MSAA 8x.

To se jeví vcelku použitelně, ne?

Vraťme se ke tématu... zajímavé video, které se touhle myšlenkou zabývá. Charlie Demerjian si na GDC 2010 odchytl Tima Sweeneyho (Epic games) a Andrewa Richardse (Codeplay) a vyzpovídal je na téma budoucnosti GPU nejen v konzolích.

WHAT HAPPENS WHEN you get two very smart people, Tim Sweeney from Epic Games, and Andrew Richards from Codeplay, with diametrically opposed views together in the same room to talk about the future of graphics hardware? Easy, a debate. At GDC this year, that is exactly what SemiAccurate did, and through the magic of video cameras, you too can enjoy the spectacle.

GDC 2010 Part 1 (YouTube, HD 720p)

GDC 2010 Part 2 (YouTube, HD 720p)

Zajímavá debata o Larrabee a pár povzbuzujících myšlenek

NO-X: Ne, výhoda TBR spočívá v tom, že je obraz rozdělen na tak malé úseky, k jejich žpracování (Z-buffer) stačí interní paměť čipu, ke které je mnohem rychlejší přístup. Díky tomu je možné realizovat MSAA s minimálními dopady na výkon (to v desktomu PowerVR zrealizovat nestihlo, ale Gigapixel ano, proto měl propady s MSAA tak nízké) a že není třeba hardware pro kompresi z-bufferu

No ale o tom jsem právě psal Jirko. Myslel jsem to tak, že pokud čip scénu rozdělí jen na dvě velké "dlaždice", tak to nemůže být tak efektivní jako když se scéna rozdělí třeba na 20 malých "dlaždic".Síla TBR právě spočívá v rozdělení scené na mnoho malých částí , ne jen na dvě velké. A navíc u Xenosu nejde o opravdový TBR, je to jen jakási forma "Z-Buffer memory save" pro FSAA.

Dalo by se říct, že při použití 2 tiles je to v podstatě jako SFR (split frame rendering) bez "load balance"

Jestli se s použitím menšího výrobního procesu navýšila i pamět EDRAM to nevím, protože ta tam byla vedle toho GPU jako separátní čip.Možná že paměť zůstane stejná, jen se zmenší samotné GPU.



to Krteq:

zní to docela zajímavě, nicméně dokud nebudou konzole navrhovány tak, aby ta grafika šla pruběžně upgradovat (výrobcem), tak to bude mít negativní dopad na vývoj her

EDRAM funguje jako z-buffer stejně jako TBR čipy mají cache pro z-buffer. Efektivita není závislá na velikosti dané paměti nebo velikosti dlaždice. Zjednodušeně řečeno výhoda spočívá v rychlejším přístupu k z-bufferu (a rychlost přístupu k z-bufferu s jeho velikostí přímo nesouvisí)...

Dodnes jsem stejně nepochopil proč se něco jako Edram nepoužívá zcela běžně, prostě tu oblast nejvíce žeroucí bandwidth ala framebuffer dát do Edram, při dnešních procesech by mohl bejt klidně 256MB velkej a ničemu by to nevadilo a na kartě už pak třeba klidně slow 128-bit DDR2 paměi kterejch by tam klidně mohlo bejt 2 GB pro textury. Či dokonce tam dát slot(y) a ať si tam každej dá co se zamane, jako se to dělá u high-end raid řadičů.

no-X píše:EDRAM funguje jako z-buffer stejně jako TBR čipy mají cache pro z-buffer. Efektivita není závislá na velikosti dané paměti nebo velikosti dlaždice. Zjednodušeně řečeno výhoda spočívá v rychlejším přístupu k z-bufferu (a rychlost přístupu k z-bufferu s jeho velikostí přímo nesouvisí)...

ano, ale právě proto se ta scéna dělí na mensí části, aby se vešla do eDRAM Z-bufferu a nemusela se načítat do/z externí GDDR paměti.

Jen tak btw to že si Xenos občas dělí scénu na 2 části je způsobeno tím, že mu občas právě nestačí ta EDram, a v praxi to pak (nejčastěji výdáno u Unreal 3 enginu) končívá horizontálním tearingem.

no-X: tys v jednom clanku o larabee na EHW, zminoval, ze MS si pro dalsi generaci predstavuje zhruba 3 nasobek vykonu nejvykonejsi verze larabee...( coz je vubec kolik?) dokazal bys odhadnout, jaky parametry by mel mit cip od ATi pokud by vychazel (jakoze nejspis ne) z architektury nynejsich DX11 Radeonu? ciste jen pro zajimavost... jo a vubec, kdes sehnal to info?

Tuším, že to byl jeden z mých bývalých zdrojů Ale šlo o tehdejší verzi LRB a nevím, jak byla výkonná oproti současné. A ani nevím, jak je LRB výkoná oproti čipům ATi nebo nVidie. Asi to bude hodně velká slabota, když ji Intel nevydal jako GPU (možná jako G92? ale je to fakt jen hodně hrubej odhad)

DOC_ZENITH: edram se hodí tam, kde potřebuješ ušetřit energii a prostor (nepotřebuješ žádnou širokou paměťovou sběrnici ani prostor pro spoustu modulů)... což je přesně věc konzolí

ale pro desktop se to zatím nehodí, minimálně dokud paměti svým výkonem stačí (a ony nejen stačí, ale dokonce zatím nepřišel čip, který by podle mého mínění limitovalo použití 256bit sběrnice... ale o tom už jsme diskutovali )