Toch HSR in nVidia Detonator 7 serie?

Op NV Italia staat een Italiaans brabbelverhaaltje over HSR (Hidden Surface Removal) ondersteuning in de nieuwe nVidia Detonator 7.27 drivers. Ze vertellen dat de nieuwe versie over 10 dagen uit moet komen en dat de performancewinst zo'n 30% is in Quake3. nVidia ontkende vorige week nog dat er ooit HSR ondersteuning voor de GeForce1 & 2 zou komen.

Zoiah vertaalt het bericht wat uitgebreider in deze thread, het zou om een hardware-implementatie gaan en niet om een softwarepatch zoals 3dfx in haar drivers heeft toegepast. nVidia zou de registercombiners (ook bekend als NSR of nVidia Shading Rasterizer) gebruikt hebben om een removalmatrix te programmeren. Helaas werkt HSR voorlopig alleen in OpenGL:

I have no time to translate word for word but briefly they say this driver introduces hardware HSR support on geforce family cards. How? the site reports HSR is done trough registers combiners setting up a 'removal matrix' that is applied after 'scene setup'. Then a filtering is done in order to avoid artifacts(!?). That works only underl OpenGL and they say Quake3 with these feature activated gain about a 30% but is not possible to use HSR and NSR both at the same time. 7.27 should be public in 10 days. Then they reports having other leaked info about new drivers that will be put on line tomorrow.

Bedankt Zero en Crack voor de tip.

Reacties (46)

[Verwijderd]

Ja...nvidia brengt italiaanse drivers uit...

[Verwijderd]

Nee, maar als jij bij de eigenschappen van een bestand kijkt zie je ook de details in het Nederlands.

[GaMeOvEr]

Nee hoor, is bij mij gewoon in het Engels...

[Jake]

Nog een kewlere link van Zodiah himself...
<A href="http://zoiah.m3dzone.com/w2k731.bmp"" target=_blank>zoiah.m3dzone.com/w2k731.bmp"</A> target=_blank>zoiah.m3dzone.com/w2k731.bmp</A>

edit:
bij de weg: It's fake... Zoiah:
<font color=#786562><i>I don't have 7.31 I just wanted to prove how fake the picture at <A href="www.nvitalia.com is.</i></font>

[B. Stuff]

Gewoon even een gedachte die bij me opkomt.. Het gebruik van HSR voorkomt toch het See-Through effect wat we nu in de Asus drivers zien. [Dat je kunt cheaten doordat je door de muren kunt kijken]. Immers word dit niet meer gerendered, en dus ook niet laten zien.

Of zit ik er nu ver naast en haal ik 2 dingen compleet door elkaar heen?

[arjenk|IA]

Of zit ik er nu ver naast en haal ik 2 dingen compleet door elkaar heen?

Hidden Surface Removal staat voor een techniek die er voor moet zorgen dat er geen bandbreedte wordt verspild aan het renderen van objecten (driehoekjes, meestal delen daarvan) die je niet kunt zien. Daar is dan wel meer processing power (GPU als het in hardware kan, anders moet de CPU het doen) voor nodig. Maar omdat de grafische kaarten op dit moment de bandbreedte als bottleneck hebben kan het wat opleveren. Implementatie is niet eenvoudig - dat wordt wel bewezen door de nog verre van perfecte implementatie door - het voormalige - 3dfx. Ik moet nog zien trouwens dat het echt zo veel oplevert als het goed geimplementeerd is. HSR in software is lastig te implementeren (daarom zijn 3D programmeurs ook zo blij met OpenGL en wat minder met DirectX ) en wil het echt wat opleveren dan moet het eigenlijk op applicatie niveau worden gedaan omdat je daar nog het meeste weet over de scene & objecten. Daar kan je de API dan wel weer op aanpassen, maar of het al die moeite echt waard is? Tegen de tijd dat dat allemaal klaar is, is de bandbreedte van de hardware al weer minimaal verdubbeld en heb je het allemaal voor niets gedaan.

* 786562 arjenk

[irrelevant]

Ik weet niet hoe dat see-through effect van Asus werkt. Maar HSR staat natuurlijk nog steeds wel transparantie toe. Als Asus dus alle polygonen als transparant markeert dan moet het nog steeds werken. Maar mengen ze kleurtjes wanneer overdraw plaatvindt dan zal het idd niet meer werken.
--------------
edit: met see-through wil je natuurlijk helemaal geen HSR, dus hoe het ook werkt, je zet HSR gewoon uit!
--------------

Tegen de tijd dat dat allemaal klaar is, is de bandbreedte van de hardware al weer minimaal verdubbeld en heb je het allemaal voor niets gedaan.

Tegen de tijd dat de bandbreedte is verdubbeld is de kracht van je GPU verviervoudigd of meer, en zou je dus juist nog meer bandbreedte willen hebben.

Ik moet nog zien trouwens dat het echt zo veel oplevert als het goed geimplementeerd is.

HyperZ haalt zo'n 22% en kan nog verbeterd worden. 30% lijkt me dus best realistisch. Heel wat realistischer dan de superresultaten op de Voodoo5 met de agressiefste settings. Ik denk niet dat ze daarbij de beeldkwaliteit kunnen repareren en de snelheid behouden.

[arjenk|IA]

HyperZ haalt zo'n 22% en kan nog verbeterd worden. 30% lijkt me dus best realistisch. Heel wat realistischer dan de superresultaten op de Voodoo5 met de agressiefste settings. Ik denk niet dat ze daarbij de beeldkwaliteit kunnen repareren en de snelheid behouden.

Mee eens. Maar daarbij moet je dan ook nog vermelden dat HyperZ transparant is voor de applicatie, het is eigenlijk gewoon een verfijning van z-buffering - traditioneel de manier om HSR in hardware te doen. Simpel en elegant - met HyperZ iets minder simpel maar nog steeds elegant. Wat op de Voodoo5 superresultaten te zien gaf kan je toch moeilijk serieus nemen, IMHO is het een hack. HSR goed doen zit hem in de details. Ik heb onder Win 3.x wel eens een eenvoudige 3D modeler gemaakt die (noodzakelijkerwijze) GDI gebruikte en moest zelf HSR implementeren. Het painters algorithme deed het aardig (I know, dat is pas bandbreedte verspillen ) al ging het af en toe fout. Maar de hoeveelheid energie die je er in moet steken (geldt ook voor de CPU) om het dan in software goed te krijgen (heb me nog wel eens in BSP trees verdiept - ook in Quake 1 gebruikt als ik me niet vergis) staat niet in verhouding tot het resultaat. Achteraf was dat ook niet nodig, want toen was er al OpenGL.

Hoe dan ook, de Voodoo5 HSR route voelt niet goed. KISS.

[Verwijderd]

Wat maakt het voor ons uit of de NV20 niet zo snel wordt?!?
Ik ben wel heel blij als ik 30% extra krijg op mij Geforce 2 MX, dat zou behoorlijk schelen!

[GaMeOvEr]

Ja precies, voor "ons" maakt dat wel degelijk uit, maar denk jij nu echt dat Nvidia zich daar iets van aan trekt, als dat inhoud dat de product-launch van hun upcoming super-performance videokaart opeens een stuk minder spectaculair wordt, omdat de GF's en GF2's opeens 30%-50% sneller worden ?

Dacht het niet.

Het zou erg onlogisch zijn van Nvidia om dat _nu nog_ te releasen, aangezien het waarschijnlijk default bij de GeForce 3 zit, en een van de meest performance-enhancing middelen is voor die kaart.

[Verwijderd]

Ze willen waarschijnlijk de Detonator drivers compatible houden met de TNT's en de Geforce 1 en 2's

[The Jester]

Hoezo

Helaas werkt HSR voorlopig alleen in OpenGL:

??
OpenGL is beter, is Open Source en derhalve is dit uitstekend nieuws voor de Linuxgebruikers onder ons

Het is feitelijk ontzettend jammer dat M$ per sé een proprietary standard (DirectX) wil hebben, omdat dat de gebruikers op extra kosten jaagt. De vendors moeten namelijk meer ontwikkelingskosten in de drivers stoppen, vanwege de 2 standaarden.

Zeg nou zelf: Wat is de meerwaarde van Direct3D t.o.v. OpenGL?

[EfBe]

Sjezus wat een troll.

Register combiners is een OpenGL extensie, en zit niet in de d3d7 api. wel in de d3d8 api (vertex/pixel shaders).

OpenGL is niet beter, en zeker niet open source. Als ik _IETS_ haat dan is het wel DOM gezwam van linuxgebruikers die OpenGL als wapen gebruiken tegen windows of microsoft. OpenGL is platform onafhankelijk en behoort dat te blijven. Het Linux-Windows verhaal er bij betrekken is het domste wat je kunt doen: voor je het weet is OpenGL een Linux-minded techniek en dat schrikt developers af. Aangezien ik niet de indruk heb dat jij deel uit maakt van de OpenGL community en dus ook geen OpenGL applicaties maakt (ik wel) snap je wellicht ook niet dat de OpenGL community elke developer die te vinden is moet interesseren en behouden. Nogmaals: linux heeft daar niets mee te maken, die developers zitten op allerlei platforms.

Je snapt zo ongelovelijk NIETS van waarover je bazelt... erg triest. -> D3D drivers zijn nl. heel snel te maken, men maakt alleen een thin wrapper om de hardware. OpenGL drivers daarentegen vereisen een complete ICD implementatie per kaart. DAT kost juist geld.

Goed, dit zal wel snel naar -1 troll verhuizen, boeie verder. Ik hoop alleen dat tezamen met mijn posting de JOUWE OOK naar -1 troll verhuist, waar hij thuishoort. Ik bedoel maar: welke debiel lult er nu over "Wat is de meerwaarde van Direct3D tov OpenGL" ?

ga maar eens 20 codepaths programmeren die elke extensie per cardvendor ondersteunt.

yeah fun indeed.

[arjenk|IA]

D3D drivers zijn dan wel snel te maken, maar aan het maken van die OpenGL ICD ontkomt een chipmaker ook niet (en dat moet zo blijven ook). Dat een D3D driver snel te maken is, is vooral goed voor de acceptatie van DirectX als platform. Goed gezien en slim gedaan, dat moet je MS nageven. Uiteindelijk zijn het de developers die de API kiezen die het beste aansluit bij de applicatie. En als het progje het grafisch leuk doet, doet het er toch niet toe of het OpenGL of D3D is

[WausMaus]

Hoezo Helaas werkt HSR voorlopig alleen in OpenGL: ??
OpenGL is beter, is Open Source en derhalve is dit uitstekend nieuws voor de Linuxgebruikers onder ons

Ehm ja, dit zijn dus drivers voor WINDOWS.
Het heeft geen biet te maken met Opengl het zit hem in de drivertjes. En die drivertjes doen het dus echt niet onder linux.

Dus ik zie het hele voordeel voor de linux gemeenschap niet echt...

Het is feitelijk ontzettend jammer dat M$ per sé een proprietary standard (DirectX) wil hebben, omdat dat de gebruikers op extra kosten jaagt. De vendors moeten namelijk meer ontwikkelingskosten in de drivers stoppen, vanwege de 2 standaarden.

Ja, nu toch ook?! Ze ontwikkelen nu toch JUIST nieuwe drivers om het sneller te laten gaan?!
En dit zijn drivertjes die het onder OpenGL sneller moeten laten gaan... En niet onder direct3d dus die vlieger gaat niet echt op nu... toch?!

Just my 2 cents...

[blouweKip]

En die drivertjes doen het dus echt niet onder linux.

Nee, deze drivers niet, maar nvidia maakt ook zeer goede drivers voor linux en die gebruiken bij spellen OpenGL, dus de kans dat deze techniek (als dit bericht waar zou zijn) ook naar linux komt ipv alleen naar windows is hierdoor dus groter en dus goed nieuws voor de mensen die in linux spellen spelen....

[Verwijderd]

Daarnaast vindt ik persoonlijk opengl eerder een hell om voor te programmeren dan voor directx...
Als ik goed in m'n eigen code kijk kom ik ongeveer 100 a 200 opengl extensies tegen die MOGELIJK gesupport kunnen worden. En daarnaast zijn er nog een luttele 20 functies die standaard opengl 1.1 zijn.

DirectX heeft dit vindt ik netjes opgesplits in een aantal interfaces, die duidelijk aangeven waarvoor deze functies hierin bedoeld zijn.

Daarnaast DirectX komt zo nu en dan met een update in de zin van een nieuwere versie.backwards compatiblele drivers, maar wel met de nieuwste snufjes qua techniek.. OpenGL zit voor zover ik weet al >8 jaar op opengl 1.1.2 ofzo... en daar houd het gewoon op. Ik hoor vaak als argument dat dit juist aangeeft dat opengl superieur aan directx is, omdat het al zolang niet nodig is geweest een nieuwe versie te maken... maar gezien de hoeveelheid extensies doe ik dit af al pure onzin.

[WausMaus]

Ik programmeer meestal juist veel LIEVER in opengl dan in directx omdat opengl veel simpeler is en ik niet 200 a 300 regels aan initialisatie code nodig heb zoals bij direct3d wel het geval is.

Verder is het idd zo dat DirectX meer updates heeft maar OpenGL is een "Standaard" en dat pas je niet zomaar effe aan. Het is niet specifiek voor 1 OS ontworpen dus ontwikkelen kost tijd.
(Hoewel >8 jaar wel weer erg overdreven is... )

Hier: www.gamedev.net/reference/programming/features/dx8freshstart/ wordt zelfs verteld dat DirectX8 voor het eerst qua simpelheid een beetje in de buurt komt van OpenGL en dus idd ook simpeler aan het worden is en dat is in principe een goede zaak.

[EfBe]

Hahahah LOL

HSR dmv 1 (dat is 2-1) matrix in de register combiners....

Nou, humor hebben ze wel daar

tip: register combiners zijn voor texelcombinations, dus texel in texelunit A - texel in texelunit B is colorfragment.

Uit de nVidia OpenGL Extensions doc: (NV_register_combiners:

[...]
The register combiners fit into the OpenGL pipeline as a rasterization processing stage operating in parallel to the traditional OpenGL texture environment, color sum, AND fog application. Enabling this extension bypasses OpenGL’s existing texture environment, color sum, and fog application processing and instead use the register combiners.
The combiner and texture environment state is orthogonal so modifying combiner state does not change the traditional OpenGL texture environment state and the texture environment state is ignored when combiners are enabled. OpenGL application developers can use the register combiner mechanism
for very sophisticated shading techniques. For example, an approximation of Blinn’s bump mapping technique can be achieved with the combiner mechanism. Additionally, multi-pass shading models
that require several passes with unextended OpenGL 1.2 functionality can be implemented in several fewer passes with register combiners.
[...]

Next!

[arjenk|IA]

Ik begrijp er niets van, maar je zult wel gelijk hebben

Next!

[EfBe]

Nou, de pipeline van geometry info + textures naar pixels in een framebuffer heeft de register combiners NA de texelunits zitten. Dus stel je hebt een geforce, die heeft 4 texelunits. Hij is met een willekeurige pixel bezig van een polygon en op die polygon zitten 2 textures (bv een material texture en een environmap/reflection texture). Texture-unit 1 doet de material texture en levert een pixel op van kleur A. Texture unit 2 doet de reflection texture en levert een pixel op van kleur B. Standaard worden deze 2 kleuren ge'blend' via : (kleur A + kleur B)/2 = resultkleur van pixel, welk in de framebuffer wordt gezet.

Welnu, je kunt nu met de register combiners, texelunit OUTPUT (dus bv die kleur A) gebruiken als logische operand in een logische formule op 2 of meer resultkleuren van texelunits (hij heeft er 4, dus je kunt texelunit 1 resultaten laten genereren voor de logische formule van het combineren van pixels van texelunits 2, 3 en 4). Je zou dus op een geforce mbv register combiners 1 texture als lookup table kunnen gebruiken voor effecten op 3 andere textures, bv bumpmapping of subtractive blending (kleur A - kleur B is resultkleur voor framebuffer).

Waar het dus op neer komt is dat je met de register combiner functies texturemanipulatie kunt doen. En dus niet HSR wat in de geometry engine zit. De geometry engine is allang klaar.

[Chickendorp]

Ik zou nu echt niet meer weten wie ik moet geloven!!
NVItalia wordt wel vaak gebruikt om dingen te laten 'uitlekken' maar ja het wordt een beetje vaag nu.
ja nee ja nee. WAT IS HET!
Zou mooi zijn voor mijn Gefroc SDR.
30% performance booze

Ik zie het wel over 10 dagen!
(Das trouwens na de kerst dus dat is gelul!!

[MeNTaL_TO]

30% performance booze

zeker bijna weekend?


tweakers denken (volgens mij) alleen maar aan drank, vrouwen en overklokken

Edit
valt mij nog iets op... er staan 2 verschillende versies op het plaatje. de ene keer 5.12.1.727 de andere keer
5.12.01.0727.

[arjenk|IA]

valt mij nog iets op... er staan 2 verschillende versies op het plaatje. de ene keer 5.12.1.727 de andere keer 5.12.01.0727.

Die hoeven niet hetzelfde te zijn. De bovenste is de binaire FILEVERSION waarde (wordt gebruikt door Setup apps), de onderste is een string die onafhankelijk daarvan ingevuld kan worden en waarvan het format niet eens is vastgelegd. Wat de programmeur(s) hier hebben gedaan is typisch techie minded: in de source (rc) zullen ze hetzelfde zijn ingetypt. Maar Windows formatteert de nulletjes er weer netjes uit (iets minder techie georienteerd), maar de string wordt weergegeven 'as is'.
Kortom: ze zijn wel hetzelfde.

* 786562 arjenk

[Paraselsius]

Ik ben geen expert, maar toch een opmerking,

Een van de eerste kaarten die HSR ondersteunde was de PowerVR kaart die ten tijde van de Voodoo 1 uitkwam. Deze had 2 nadelen: de drivers ondersteunde een groot aantal spelletjes niet en de performance werd beperkt doordat de HSR voor een groot gedeelte software matig gebeurde wat de toenmalig machines, (p166 en minder) eigenlijk niet aankonden. Voordeel was wel dat je tot 1024x768 op 24 bits kleuren kon draaien (Het zag er ook nog redelijk mooi uit, voor die tijd).
Mijn vraag aan de Experts: Zou HSR niet gewoon software matig geimplementeerd kunnen worden, zoals toenmaals op de PowerVR?
(Ik hoop dat dit niet als totale onzin klinkt, maarja er bestaan alleen domme antwoorden, toch ) )

[WausMaus]

Ja het zal waarschijnlijk wel kunnen maar het probleem is dat je dan de CPU weer zwaar gaat belasten, en dat is nou net iets waar 3d-kaarten voor uitgevonden zijn... Die nemen immers een zware taak van de CPU weg zodat deze andere dingen kan gaan doen.

[Ralph Smeets]

Mensen met 'n Athlon/Duron/Pentium/Celeron die op 800Mhz of hoger draait, worden over het algemeen afgeremd door hun GeForce 2 GTS. Voor mensen die 'n GeForce 2 MX hebben ligt deze drempel zelfs nog lager. Dus deze bezitters zouden best 'n gedeelte van hun CPU power willen omzetten naar software matige HSR. Dus 'n optie om software HSR aan te zetten zou 'n uitkomst zijn voor deze mensen.

[arjenk|IA]

Klinkt aardig, maar het probleem is dat HSR in software een alles of niets kwestie is. En er zijn dingen die je met een z-buffer oneindig veel eenvoudiger en dus ook efficienter kunt doen (sprite achtige dingetjes bijvoorbeeld) waar HSR gewoon niet werkt of je verzand dreigt te raken in super complexe en dus dure code.

[Bokkie]

waarom zou dit niet waar zijn??
nu Nvidia 3dfx hb overgenomen hebben ze toch alle techniek tot hun beschiking?? lijkt me niet dat ze zichzelf nu in de vingers gaan snijden toch?

[TheBrain]

Maar je dacht toch niet dat men die techniek a la minute in de eigen driverset had ingebouwd ?

Daarnaast is er nog helemaal geen sprake van integratie tussen nVidia en 3dfx, 3dfx is eerst bezig om de zaak dusdanig te ontmantelen dat er een 'overdraagbaar' pakket ontstaat.

[markjuh]

En zeker binnen een dag of 3 deze techniek al in hun eigen drivers hebben geïnplementeerd!!?? Dacht ut nie.
Dusss......


* 786562 markjuh

[Verwijderd]

Weet iemand of dit de performance van mijn TNT2 zal verhogen?

[GaMeOvEr]

Ja, _als _ dit in de drivers gesupport _zou_ worden, (wat dus zwaar twijfelachtig is) zou dit een performance increase hebben op alle kaarten van Nvidia vanaf de TNT 1. (Detonator drivers zijn compatible op alles vanaf de TNT 1.)