Binnenkort ook HSR in nVidia detonator drivers?

Zaterdag berichtten we nog over de HSR-support in de Voodoo5-drivers, vandaag staan de eerste geruchten over ondersteuning van deze technologie door de nieuwste Detonator Drivers al online. De techniek zorgt ervoor dat het renderen van onzichtbare textures overgeslagen wordt, om zo de frame-rate te verhogen. Volgens Giga zal ondersteuning voor Hidden Surface Removal in versie 7.27 beschikbaar zijn, waarvan de officiële release binnenkort te verwachten is. Let niet op de enorm brakke Engelse quote, AltaVista Translations is de schuldige:

From the diagram chip manufacturer nVidia there are also some pleasing News. As it, gets along one looks with the driver development relatively well. Apparent one seems to be finished already with nVidia with the new 7,27 drivers. Beside DirectX 8 the drivers support also HSR (Hidden Surface rem oval). With HSR it concerns a technique, which promises better Frameraten by Overdraw. Not visible textures are not calculated, what leads evenly to better performance results. When this detonator driver can down-load you, remains being waiting. In the Help News I will hold you up to date.

Met dank aan Jake en tigger voor de tips.

Reacties (54)

[Verwijderd]

Hier dan maar eventjes een gewoon Nederlandse vertaling vanuit het Duits:


Ook van de chipfabrikant voor grafische kaarten nVidia is er heuglijk nieuws. Zoals het er naar uitziet, gaat het met de ontwikkeling van de drivers werkelijk de goede kant op. Het lijkt er op dat nVidia de nieuwe 7.27 drivers al klaar heeft. Naast DirectX 8 ondersteunen deze drivers ook HSR (Hidden Surface Removal). Bij HSR gaat het om een techniek die er voor zorgt dat er door middel van Overdraw betere framerates behaald worden. Bij deze techniek worden niet zichtbare textures niet berekend, hetgeen tot betere framerates leidt. Wanneer deze drivers te downloaden zijn is nog niet duidelijk. We houden je op de hoogte.

Is Duits nu zo moeilijk?

[Verwijderd]

"When this detonator driver can down-load you"

HET MOET TOCH NIET GEKKER WORDEN!

[Verwijderd]

Waarom eigenlijk nu pas?
Nu de grafische kaarten snel genoeg zijn (te snel voor de meeste systemen) komt men opeens voor een functie die zorgt dat alle grafische kaarten nog sneller worden....Ok...altijd leuk....maar waarom niet eerder???

[Verwijderd]

Das gebeurt met elke techniek wel een beetje. Zolang met met simpele dingen als clocksnelheid, meer texture units, hyperZ, e.t.c. de snelheid weet op te krikken is het niet zo nodig naar complexere oplossingen te zoeken... Echter nu dit een beetje op z'n einde begint te raken, moet men op zoek naar hogere orde oplossingen... daar is HSR er een van.

[Verwijderd]

Hoezo GFX kaarten te snel voor CPU?
kijk maar eens naar de benchmarks:
een Duron 700 is net zo snel als een P4 1.5 GHz op 1600x1200x32 . Dus het is zelfs zo dat de GFX kaarten een bottleneck zijn. Dit komt vooral doordat het geheugen van de kaartjes niet snel geneog is(waardoor meer dan 50% van de ruwe power van de GPU verloren gaat)Het geheugengebruik kan verminderd worden door HSR en S3TC en dus haal je meer FPS. Je maakt eigenlijk beter gebruik van je GPU.

[TheGhostInc]

Ik denk dat de reden dat dit soort dingen nu pas ontstaat omdat er nu pas ECHT vraag naar is.
Hiervoor waren de technieken soms nog verschillend (Voxels in DeltaForce is zo'n andere techniek), door het standardiseren van de hele zaak worden nu op zich eenvoudige verbeteringen mogelijk omdat de maker van het spel (programma ) niet voor 1 kaartje deze functie moeten inbouwen, maar dit doen voor (bijna) alle (nieuwe) kaarten.
Netzoals dolby op de geluidskaarten, dat wordt nu pas echt toegepast, want nu hebben veel meer kaarten dezelfde mogelijkheden, daarvoor had je ook nog quatrofonie (voor de oudjes onder ons )

[Verwijderd]

//off-topic

Werkt DF3 (Land Warrior?) ook nog met die crappy voxel zooi??
Laatst nog even DF2 op m'n nieuwe systeem (TB1000+TNT2) geprobeerd, niet om aan te zien EN baggertraag op 800x600 !!

\\off-topic

[punica]

Nee, is overgegaan op DirectX. Loopt errug lekker op 1024*768 op mijn amd 950 + GeForce2 MX

[Verwijderd]

Ja ik wil niet zeuren hoor, maar 3dfx claimt nog steeds dat het om het met software enablen van een hardware functie gaat, althans dat heb ik vernomen, als dit zo is dan zal de nVidia driver niet een evengrote impact hebben, en voor de ATi (lief)hebbers zal het alleen maar leuker worden want dan word HyperZ (=Hierarchical Z, FastZClear & Z buffer compression) met een software update mogelijk nog beter benut, want het lijkt er nu op dat er maar 2% geboekt wordt door de Hierarhical Z functie en dat is een soort HSR (voor meer info: www.ati.com/na/pages/technology/hardware/radeon/performance.html#3 ) dus als die optimaal benut word zijn we weer terug bij af met alle kaarten, maar wel een stuk sneller en bijkoment voordeel, je kan het nog ff uitzingen tot de volgende kaarten release, dus laten we hopen dat alle producenten er in slagen deze functie te benutten met enkel software, das het beste voor iedereen. keep the peace

[sonix666]

Het HSR algoritme van 3dfx is nog onvolledig tot zelfs fout. De scores van een algoritme wat exact de verkeerde polygonen niet tekent zijn nutteloos.

Het flikkeren waar ze het overal over hebben heeft te maken met dat niet iedere pixel op het scherm getekend wordt door minimaal 1 polygoon. Dit flikkeren ontstaat in combinatie met double en tripple buffering.

Totdat het algoritme daadwerkelijk correct is, zijn die scores van 3dfx misleidend, en zullen mensen die nu heilig er in geloven, dat de performance op hoge resoluties zo hoog blijft, tegen de lamp lopen.

Dit is overigens NIET de schuld van 3dfx, want het is een ongedocumenteerde beta feature.

[Kahlan]

Dit flikkeren ontstaat in combinatie met double en tripple buffering.

Vreemd.. Normaal gezien wordt bufferen gebruikt om flikkeren tegen te gaan.

[sonix666]

Dan zal ik proberen het beter uit te leggen.

Iedere populaire FPS zoals Quake 3, Unreal Tournament, Half-Life, etc. is gebaseerd op het feit dat de 3D wereld waar je je in bevind volledig afgesloten is. Dit is te vergelijken met dat jij aan de binnenkant van een holle bol (le gijs ;-) ) zit waar geen opening is waardoor je buiten die bol kan komen. Zelfs lucht en buitenomgevingen zijn daarop gebaseerd.

Dit betekent dus dat je gehele gezichtsveld oftewel iedere pixel van je scherm volledig bedekt is door die wereld.

Omdat het dus niet voor komt dat er pixels niet getekend worden, is het niet nodig dat het scherm eerst geleegd wordt (naar een standaar kleur zetten). Mocht dat namelijk wel voorkomen, dan zouden pixels die niet getekend worden nog de kleurwaardes bevatten van het vorig getekende frame.

Blijkbaar is de HSR van 3dfx nog niet af of foutief waardoor soms dus NIET iedere pixel wordt getekend (verkeerde polygonen die worden weggefilterd door HSR), dus blijft er een gedeelte van het vorige frame staan.

Als we dan double buffering gaan gebruiken, dan betekent dat dus dat de ene buffer de even frames en de andere buffer de oneven frames bevat. Niet het gehele frame wordt dus getekend waardoor nog delen van vorige oneven en even frames te zien zijn.

En omdat na het tekenen van ieder frame geswitcht wordt van buffer die getoond wordt, krijg je dat knipper effect. Dat zijn dus die gedeeltes van vorige frames die niet overschreven zijn.

Ik hoop dat dit duidelijk genoeg is.

[Kahlan]

Dank. Dit legt idd veel uit. Het flikker-effect dat normaal wordt tegengegaan door double buffering is dat het frame nog 'being displayed' is terwijl het nieuwe al getekend wordt. Ik was dus even in verwarring.

[blouweKip]

Volgens mij kwamen de echt grote verschillen bij 3dfx door de gedropte frames....

[XKB]

Toch verbaasd het me hoogelijk dat dit nu pas gebruikt gaat worden. Dit soort dingen zijn niet zo heel erg moeilijk uit te rekenen. Backface culling etc zijn redelijke standaard algoritmen. Ik denk dat engines zoals quake e.a. dit al gebruiken. Via drivers wordt dit natuurlijk wel makkelijker.

[Verwijderd]

Ware het niet dat backface culling iets heel anders is dan HSR. Backface culling is op hidden plane removal, de achterkant van een kubus wordt niet gerendered. Echter, staat achter deze kubus een kleinere kubus wordt die kubus nog steeds gerendered, bij HSR wordt die kleinere kubus helemaal niet gerendered. en dat scheelt dus drastisch in rendertijd, dus FPS

[XKB]

Het is dus niet heel iets anders, maar een verder doorgevoerde versie van dit principe. Werkt dit HSR met behulp van een BSP? Ik ben zeer geinteresseerd in het algoritme hiervan als het niet met behulp van BSP's werkt.

[Verwijderd]

het is denk ik meer bedoelt voor spellen die ECHT wat van je video kaart vragen...
half-life vraagt nix (maar is dan ook al 1,5 jaar oud)
bij nieuwe spellen als mafia (met VEEL npc's etc. )
kon het nog wel es schelen, guess
ik kijk er wel naar uit. hoewel bij mij de proc toch gaat bottlenecken denk ik .... (kut celly )

[Verwijderd]

Half-Life vraagt niks van je videokaart ?????
DACHT HET WEL........Quake III Arena loopt dubbel zo snel als die lelijke half-life, waarom snap ik ook niet !!!!!

[Verwijderd]

Je zegt het zelf al.. Quake III loopt dubbel zo snel.. Als je dan probeert na te denken kom je tot de conclusie dat quake wel goed gebruikt van je videokaart en half-life bijna niets vraagt van je GPU. Logisch gevolg daarvan is dat half-life van je CPU veel vreet. Omdat bij quake je CPU dus ontlast wordt draait het sneller

[.oisyn]

Nee quake3 loopt niet sneller omdat het meer gebruik maakt van je GPU, maar omdat de visibility algoritmes gewoon veeeel beter zijn... (Alle algoritmes zijn trouwens veel beter in Quake3, maar ja, dat is ook een van de redenen waarom de mensen als John Carmack ook een vrij hoge status hebben )

[bille]

hehe en uit welke taal moet ik dit nu gaan vertalen om het te kunnen lezen?? <br>
Maare, dat HSR is wel een goeie vooruitgang. Dat zal waarschijnlijk wel wat FPS schelen. Wat ik mij afvraag is in hoeverre bijvoorbeeld Half-Life dat nu zelf al regelt. Ik neem aan dat in Half-Life de niet zichtbare textures en polygonen niet worden berekend....anders zou het helemaal zuur draaien

[Verwijderd]

Uiteraard doet half-life dat. Alleen helaas niet helemaal perfect. Hij bepaalt welke faces zichtbaar zijn aan de hand van een BSP tree. Hij maakt dan afhankelijk van waar je staat een PVS van faces (possible visible set). Deze is echter nooit perfect, hij rendert altijd een paar faces extra die je toch niet kan zien. Er is wel een oplossing voor dit probleem, alleen die is er alleen in theorie... zelfs John Carmack was niet in staat die te implementeren...

Oh ja, en als je de nieuwste patch van Half-Life hebt (1.1.0.4), dan kan je zien welke faces Half-Life rendert door:

gl_wireframe 2

in je console in te typen!


<font color=#786562>* me&thepizza is moe van het typen man!</font>

[toraq]

welke algoritme moet dat dan zijn ?
heb je er url's bij ?
zou je mij hierover willen mailen ?
[e-mail]
bij voorbaat dank

[yiNXs]

Er staat me wel iets bij dat er een optie in half-life zit waarmee je het renderen van niet zichtbare polygonen uit kan zetten. Het uittesten van deze optie heeft me geen zichtbare verschillen opgelevert, maar het is mischien interessant het te testen met de fps optie aan (die er nu dus eindelijk inzit).

[Verwijderd]

Dat de Detonators voor elke Nvidia kaart vanaf de TNT is te gebruiken wil nog niet zeggen dat ze ook allemaal HSR gaan ondersteunen. De FSAA in de detonator drivers werken ook alleen maar op de Geforce serie...

[Verwijderd]

maar ik denk dat dit net als bij de voodoo drivers een software matige oplossing is.
Ik dacht dat ook de voodoo 3 die vage 3dfx drivers kon gebruiken alhoewel ik daar geen verdere resultaten van heb gehoord of gezien.

Wat me eigenlijk niet zo aanstaat is dat ze die kaarten eigenlijk al die tijd gelimiteerd hebben en persee hun eigen features koste wat kost door je strot douwe(zoals dat je nu bv weer wel op je geforce fsaa ken gebruiken(niet dat dat snel is))

[Ralph Smeets]

Het ligt er maar aan welke CPU in je systeem zit. Als dit 'n software matige HSR oplossing is, dan zal je er rekenkracht voor moeten inleveren. Je krijgt er echter GPU kracht voor terug.

Wat betekent dit in de werkelijkheid:
1) Je hebt 'n snelle CPU (>800 Mhz) en de enigste manier om meer fps te krijgen is 'n snellere grafische kaart. Hier zijn deze drivers 'n goede keus omdat niet de volle CPU capaciteit wordt gebruikt!

2) Je hebt 'n langzame CPU ( <500Mhz?) en je snelle grafische kaart staat op je CPU te wachten. Als je dan HSR gaat gebruiken, kan het best zijn dat je fps achteruit gaat!

[Dries Arnolds]

Als je het vanuit nVidia bekijkt, welke belang hebben zij er dan bij?

De NV20 staat voor de deur, dus zijn ze eigenlijk gebaat bij een groot verschil tussen de Geforce 2 en de Geforce 3. Als ze deze optie (HSR) nu al invoeren, is het verschil tussen Geforce 2 en 3 straks kleiner en misschien besluiten dan minder mensen om over te stappen.

Vanuit Tweakers oogpunt zou het natuurlijk prima zijn om nu al HSR te hebben

[Verwijderd]

Welk belang, betatesting natuurlijk
Stel je voor dat ze ermee uitkomen pas bij de Geforce3 en dat ding heeft problemen (aka zoals de beta drivers versies van de voodoos) = negative commentaar op hun product... allee ik denk dat het dat is....

Maar niet vergeten dat Nvidea 1 van de zelfzame bedrijven is dat zijn oudere producten juist sneller doet gaan detonator v3->v5->v6->v7
Tussen iedere was er altijd een goede snelheidsboost(behalve natuurlijk voor de Tnt eigenaars bij de laaste versies maar ja, dat is te verwachten dat men meer op hun nieuwe reeks gaat toespitsen dan op de oudere kaarten).

[qwerios]

Mijn Sega Dreamcast gebruikt deze techniek denk ik al. Ik heb toevallig eens wat leeswerk gedaan over het DirectX programmeren voor Windows CE en wat vond ik in MSDN? Inderdaad info over programmeren voor de Dreamcast. Hier stond vermeld dat het aantal polygonen wat je defineerd met zorg gekozen moet worden omdat de dreamcastr eerst het geheel "plat maakt" (onzichtbare delen verdwijnen dus) en daarna pas rendert. Op een PC wordt alles gewoon gerenderd (elk driehoekje dus).

[Verwijderd]

De dreamcast gebruikt een Videologic Power VR2 chip. Die chip maakt gebruik van tilerendering. Dat is inderdaad een soort van HSR. Maar het schijnt effectiever te zijn.