Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 54 reacties
Bron: Giga.de

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.

Moderatie-faq Wijzig weergave

Reacties (54)

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?
"When this detonator driver can down-load you"

:+ HET MOET TOCH NIET GEKKER WORDEN! :)
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???
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.
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.
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 :) )
//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
Nee, is overgegaan op DirectX. Loopt errug lekker op 1024*768 op mijn amd 950 + GeForce2 MX
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 :)
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.
Dit flikkeren ontstaat in combinatie met double en tripple buffering.
Vreemd.. Normaal gezien wordt bufferen gebruikt om flikkeren tegen te gaan. :?
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.
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.
Volgens mij kwamen de echt grote verschillen bij 3dfx door de gedropte frames....
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.
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
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.
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 :) )
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 !!!!!
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 :)
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 }>)
hehe en uit welke taal moet ik dit nu gaan vertalen om het te kunnen lezen?? :P <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 :(
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>
welke algoritme moet dat dan zijn ?
heb je er url's bij ?
zou je mij hierover willen mailen ?
a.mooij@student.fnt.hvu.nl
bij voorbaat dank :)
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).
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...
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))
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!
Half-Life gebruikt BSP (binary spacial partitioning ofzoiets) om te voorkomen dat het hele level gerenderd moet worden. Maar dan is er nog wel wat overdraw. HSR brengt dat verder terug, maar kan problemen geven (knipperende textures, wapens/armor door een muur heen zien).

Het wordt niet direct gezegd maar het kan zijn dat 3dfx en nvidia hardware support voor HSR hebben. Ook als dat niet zo is (dus enkel een driver feature is): zoveel win je niet met HSR, het is meer fine tuning dan een echt sensationele doorbraak.
halflife gebruikt idd BSP trees, maar dit zorgt er niet voor dat de decals (de textures die op muren geplakt worden, zoals kogelgaten ed) gaan knipperen.
Dat knipperen heet Z-fighting of flimmering, en dat komt doordat de decals op de muur als apparte polygonen gerenderd worden. De Z-buffer wordt ervoor gebruikt om pixels die achter een andere liggen niet getekend worden, maar omdat de decal OP de muur zit, zijn de Z-waarden van de pixels min of meer gelijk. Door onnauwkeurigheden in het uitrekenen van de Z-waarden komt het dus voor dat bepaalde pixels van de decal achter de muur komen te liggen, en weer andere ervoor. Omdat dat als je de camerastand verandert die onnauwkeurigheden net iets anders zijn, gaan de decals flikkeren tijdens het lopen of rondkijken

(Dit kan simpelweg opgelost worden door de decals een stukje van de muur af te zetten, maar de mensen van HalfLife schijnen dit niet echt te begrijpen denk ik, want ze hebben het nog steeds niet opgelost.)
Oh ik zie dat ik je post verkeerd heb gelezen.... |:(

Ik heb nix gezegd! :*)
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 :P
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).

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True