Geen Hidden Surface Removal voor GeForce 1 & 2

Ondanks de geruchten dat ook de nVidia Detonator drivers zouden worden voorzien van Hidden Surface Removal bevestigt nVidia dat de huidige GeForce'en helaas niet gebruik zullen maken van deze feature. HSR zorgt ervoor dat voor de gamer onzichtbare gedeeltes niet worden gerenderd, wat erg gunstig kan uitpakken voor de framerate. 3dfx heeft dit al laten zien in de laatste Voodoo5 beta drivers, alhoewel er momenteel nog wat visuele fouten te betreuren zijn. Of de komende NV20 GPU van nVidia wel HSR ondersteuning heeft wil men nog niet kwijt helaas. Onderstaande info geleend van Planet GeForce:

With all the rumours floating around regarding the possibility of HSR debuting in a future set of the Detonator drivers, I thought it was about time to get word straight from NVIDIA on just what-the-heck was going on. Here's the copy-and-paste from Diane Vanesse's (PR girl) e-mail to us:

Hidden Surface Removal - z occlusion/z culling is not a feature which will ever be enabled for any of our current product line. As for NV20, we do not talk about any products before they are announced

Thanks wzzrd voor de link.

Reacties (46)

[jaspov]

Mmmm. Als ik het goed begrijp bepaald HSR van te voren wat er wel en niet gerenderd gaat worden door de videokaart. waarom zou er dan iets hardwarematigs in de kaart moeten zitten?

Heeft het er wellicht iets mee te maken dat de T&L engine ook al in de kaart zit en dat daardoor die beslissing TOCH pas wordt genomen nadat de kaart de hele geometrie heeft uitgerekend en zo weet welke vlakken niet zichtbaar zijn?

Ik vat hem niet. moet volgens mij met een driverupdate kunnen

Maar het zou voor Nvidia inderdaad beter zijn dit niet te doen.........Met de huidige geheugentechniek/prijzen wordt het toch al lastige de geforce3 veel sneller te maken dan de twee........

[-=bas=-]

Er is BackFaceCulling wat inhoud dat als een polygon (al dan niet met textures erop) met de achterzijde naar je toe staat je die polygon kan verwijderen omdat in de huidige 3D-engines er alleen met voorvlakken gewerkt wordt. Dit is zeer eenvoudig te implementeren in hard en software.

Maar als je een bepaalde view in een scene hebt, kan het ook zijn dat ondanks dat polygonen naar je toe staan (en dus zichtbaar zouden zijn als je er pal voor sond) je ze niet ziet omdat er een ander polygoon voor staat. Denk maar aan Quake dat je achter een pilaar staat : Alles wat achter die pilaar staat zou zichtbaar zijn als die pilaar er niet stond.
Een groot aantal videokaarten gaat dit toch zitten tekenen ondanks dat het niet nodig is en dus verspilling is van tijd die je Grafische Processor voor andere dingen kan gebruiken (of gewoon hogere framerates).
Het weghalen van wat toch niet zichtbaar blijkt te zijn noemt men HSR. Maar dat is niet makkelijk, althans niet zo makkelijk als een chippie bakken die dom maar heel snel een berg polygonen voorziet van textures.

Als je die stap in hardware toevoegd zal dat best een aardige performance verbetering zijn. Maar het kst gewoonweg veel transistoren at de chip veel duurder maakt. Maar in software moet het best te doen zijn ALS een stel knappe koppen er naar kijken.

Als de combinatie van software en hardware het toelaat moet een knappe kop dat best bij bestaande videokaarten kunnen toevoegen. Maar 3Dfx of nVidia verkoopt je liever een nieuwe kaart dus we hebben weer eens pech met z'n allen. Of wil iemand de geForce reverse-engineeren? Maar dat is haast niet te doen zonder volledige informatie van nVidia.

[EfBe]

Heeft het er wellicht iets mee te maken dat de T&L engine ook al in de kaart zit en dat daardoor die beslissing TOCH pas wordt genomen nadat de kaart de hele geometrie heeft uitgerekend en zo weet welke vlakken niet zichtbaar zijn?

Jij snapt um. Toch nog IEMAND die nadenkt hier.

[The Source]

Ze kunnen wel ontkennen dat ze gebruik gaan maken van HSR in de NV20 maar het lijkt me logisch dat het wel zo is. Alle feiten zijn aanwezig.

In de laatste drivers zijn ze er al mee aan het experimenteren. Uiteraard zal dat weinig effect hebben op de oude GeForce kaarten want die hebben de benodigde hardwareondersteuning niet.

Als ze in de NV20 geen gebruik gaan maken van HSR dan gooien ze veel potientele snelheid weg waardoor het product relatief (tov snelheid) duur wordt. De geheugenbandbreedte laat niet veel meer toe dus ze moeten wel toevlucht gaan zoeken naar technologieen als HSR.

<update>
idd wausmaus je hebt gelijk. Ze ontkennen het niet. Ik bedoelde eigenlijk: Ze kunnen het wel niet bevestigen...


* 786562 The

[WausMaus]

Ze ontkennen niet dat ze geen gebruik gaan maken van HSR op de NV20:

Hidden Surface Removal - z occlusion/z culling is not a feature which will ever be enabled for any of our current product line. As for NV20, we do not talk about any products before they are announced <g/s/smile.gif>

Ze zeggen dus dat het niet enabled gaat worden op hun huidige productlijn maar over de NV20 hebben ze niets te melden...

[Verwijderd]

Wat een smerige streek. Vanuit hun opzicht is het natuurlijk slim bekeken, want nu zal je eerder een nieuwe vga-kaart kopen. Met HSR zou je kaart misschien wat langer een acceptabele frame-rate halen. Mischien een idee voor een paar slimme rakkers om HSR om te bouwen zodat het wel geschikt is voor de Geforce 1 & 2 ??? HINT HINT

[Cyberdeck]

Er zijn al genoeg gehackte nvidia drivers dus dit zal ook wel komen. Er zijn altijd wel een paar "software"tweakers die handig genoeg zijn en die aanpassing waar maken.

[Zer0]

Als dat de taktiek van nvidia zou zijn dan zouden ze niet nog steeds drivers voor de TNT's uitbrengen die de snelheid positief beinvloeden.

[TheGhostInc]

Zou het niet kunnen dat er rechten op de techniek staat?
Want als 3dfx het wel kan en doet en nVidia er helemaal niks aan doet, lijkt het erop dat nVidia de techniek niet in huis heeft, en waarschijnlijk niet wil/kan kopen.

[The Source]

nee, er bestaan geen rechten op de techniek HSR. Echter wel op een bepaalde implementatie ervan. Dus zowel bij 3dfx (GigaPixel) als NVIDIA zal de onderliggende technologie anders zijn, maw een andere aanpak. Toch zal het eind resultaat min of meer hetzelfde zij.


* 786562 The

[Verwijderd]

Volgens mij praat je over features van dx8 die je vervolgens in je drivers moet zien te verwerken.
Dat betekent dat de techniek al bestaat, immers daar komt microsoft al mee.
Moet je alleen nog wat regeltjes code krassen om het ook daadwerkelijk te gebruiken

[blissard]

DirectX 8 is toch in samenwerking met NVidia gemaakt? Dan zullen ze de opties daarvan toch ook wel ondersteunen. (nu of met de NV20)

[Verwijderd]

Nee hier zitten geen rechten op. Dit is een algemene techniek die al jaren wordt toegepast (voor het bestaan van 3d-accelerators)...

[Verwijderd]

maar waarom wordt in de eerste plaats dan de hidden surfaces mee geprorammeerd in de betreffende software.
Als je het niet ziet, waarom wordt het dan gemaakt?

[WausMaus]

Omdat normaal gesproken de rekenkracht die nodig is om uit te rekenen welke delen NIET op het scherm moeten worden afgedrukt zo cpu-intensief is dat je framerate enkel maar omlaag gaat ipv omhoog....

[curry684]

Hidden surface is viewafhankelijk, niet stupiditeit van de developer. Als je een grote solide bol zet om een kleine bol, ja goh vreemd dan heb je hidden surfaces.

Het gaat er hier om dat je de achterkant van een huis niet hoeft te renderen als je er van de voorkant tegenaan kijkt: dat scheelt je ruim de helft van de surfaces. Om daarentegen 100% zeker te zijn dat je niet ergens door een doorschijnend raam of een open deur of weet ik het wat een pixeltje van de achterkant kunt zien is wiskundig zwaar pompwerk....

[raptorix]

Erg jammer, maar ik denk niet dat het snel zal gebeuren, ik denk dat de makers van de kaarten meer met de makers van engines moeten overleggen hoe het beste resultaat kan worden bereikt, echter vergeet niet dat de makers van de kaarten op de lange termijn helemaal niet zoveel beter af zijn met software matige oplossingen want juist de hardware is hun brood!

[D-RiSe]

Waarom wordt deze techniek niet gewoon meteen in de chip gebakken?
lijkt me dat het dan nog sneller gaat of niet?

[-=bas=-]

Alles wat in de chip komt kost vele malen meer dan wat ze in de drivers doen. Een driver is 1 keer programeren maar 25% extra transistoren per chip is 25% minder chips per wafer is 25% duurdere chip.
En kijk maar eens wat een videokaart uiteindelijk extra kost als de chip 5$ duurder wordt.

Natuurlijk is het een enorme snelheidswinst ALS het te realiseren is in hardware. Dat is ook de snelheidswinst bij videokaarten die we de afgelopen tijd zien (naast sneller geheugen.)
Maar niet voor elk probleem is een eenvoudig algoritme beschikbaar om een probleem op te lossen zodat complexe problemen relatief veel transistorjes gaan kosten. En er zitten er al zo'n berg op een grafische processor.

Een S3 was ook een 3D-kaart maar verwacht maar niet dat daar veel 3D-features op zaten. (Hooguit het tekenen van een punt of zo )

[Zer0]

Als ik kijk naar het huidige prijsbeleid van bv nvidia dan denk ik niet dat het voor nvidia uit maakt dat een chipje wat meer kost. De hogere kosten van snel DDR geheugen heeft ze ook niet weerhouden de Ultra op de markt te gooien, en de geruchten spreken nu al over een hoge prijs voor de nv20.

[Onno]

is 25% minder chips per wafer is 25% duurdere chip.

Hmmmmm... dat klopt niet hoor.

situatie A:
100 chips per wafer, f1,- per chip. opbrengst = f100,-.

situatie B:
75 chips per wafer, f1,25 per chip. opbrengst = f93,75.



(als het aantal naar 0.75 daalt moet de prijs per unit naar 1 / 0.75 stijgen, en dat is dus geen 1.25, maar 1.33 -> 33% duurder)

[The Source]

Zoiets heeft de Radeon al in de vorm van Hyper-Z. Dat is een vorm van Hardwarematige Zbuffer compressie.

[irrelevant]

Het is toch een hardnekkig misverstand dat HyperZ alleen om z-buffer compressie gaat. Dat is een onderdeel van HyperZ. Een ander onderdeel, Hierarchical Z lijkt idd op HSR.

Lees het nog eens na:
www.tomshardware.com/graphic/00q3/000717/radeon256-10.html

[arjenk|IA]

Hyper-Z op de Radeon is idd z-buffer compressie. Dus iets totaal anders dan HSR, ook al is de achterliggende gedachte hetzelfde: bij beperkte bandbreedte de hoeveelheid data beperken.

[arjenk|IA]

Waarom wordt deze techniek niet gewoon meteen in de chip gebakken?
lijkt me dat het dan nog sneller gaat of niet?

Dat kan, maar het hoeft niet. Waar het om gaat is dat de grootste bottleneck de bandbreedte is. Daar komt nog bij dat implementeren van HSR in hardware veel complexer is, en eigenlijk alleen echt goed werkt als applicaties rekening houden met de beperkingen van HSR. Daarom is het zinniger HSR in DirectX in te bouwen - voor een applicatie is HSR dan een feature die kan worden uitgebuit via een goed gedocumenteerde API.

[Tripp]

HHmm

heeft de voodoo5 wel hardwarematige ondersteuning voor HSR

dat heb ik namelijk nergens gelezen.

misschien wil nvidia juist wel niet dat we met de huidige kaarten met HSR kunnen spelen.
omdat dan de aankoop van de NV20 minder interessant is.(tis maar een speculatie hoor hoeft niet zo te zijn natuurlijk)

[biobak]

heeft de voodoo5 wel hardwarematige ondersteuning voor HSR

Het schijnt dat ze daar die T-buffer voor die motion blur voor gebruiken.

[Cheetah]

Natuurlijk gaan die slimmerikken bij Nvidia HSR nooit "enabelen" bij de GF1&2 .
Nvidia wil de verkoopcijfers van de GF3 natuurlijk opkrikken en als je met een GF1 met HSR GF2 performance gaat halen verkopen ze niet veel meer

Het is echter natuurlijk een kwestie van tijd voordat een slimmerik die de Nvidia Detonator drivers ff omprogrammeerd zoudat deze functie WEL enabeled wordt

[Verwijderd]

Hier zie je mooi wat voor een bedrijf nVidia is: alleen €€€ in de ogen.

Hoewel ze hun huidige klanten dolgelukkig zouden kunnen maken met HSR, zeggen ze liever "koop onze nieuwe kaart maar"

Petje af voor 3DFX in dit geval.


* 786562 Loki

[MaxxMark]

Nah ! ik voorzie dat er wel iets gaat gebeuren als met die Detonator drivers... ze worden backwards compatible e.d. en als een kaart et aankan dan doet et dat ook!

Maar das mijn mening! (niet als "-hun-teentjes-getrapte-nvidia-kind" ofzo)

[blouweKip]

Ik geef toe dat 3dfx de laaste tijd de indruk wekt dat ze niet echt meer om geld geven, maar waarschijnlijk draait het ook bij 3dfx om geld...

De HSR bij 3dfx is verre van perfect, dus echt pratisch is het nu nog niet (en dus ook niet gevaarlijk voor nvidia)

Als HSR goed werkt bij 3dfx dan zullen de andere chipbakkers echt niet achetr kunnen blijven...

[Verwijderd]

Even offtopic

Wat een stelletje slimmerikken lezen hier eea. Lijkt wel dat ze nooit naar school zijn geweest

Als je de 'die' van een cpu 25% groter maakt (bijv. voor meerdere functies) dan betekend dat zeker niet dat de opbrengst van een wafer ook met 25% naar beneden gaat!

Een wafer is rond. De oppervlakte van een wafer is dus Pi/4*d^2

Als je de diameter met 25% verlaagd; of anders geredeneerd minder chips produceerd; (want elke chip neemt nu een groter gedeelte van de oppervlakte in beslag), zal je zien dat het verlies aan het aantal chips dat opgebracht kan worden stukken groter is!!!

Reken zelf maar na.... wilde dit gewoon even kwijt en heb er even geen in


Ps. meerdere functies op een 'die' geeft ook veel meer kansen op afkeur van de gehele chip. Ten tweede kost het ontwikkelen van functies in hardware vele malen duurder dan puur een softwarematige oplossing!