Anand on Parhelia vs NV30

Nappe, not sure if I can make it this year. I'll keep your location in mind if I do!

Hellbinder, Flipper sure has a kickbutt texturing block, but I'm not sure there's anything deferred ("held back") about the rendering it does... I don't really know it, though. I know Kyro gets the 4+4 layers in single pass (one geometry setup) because of the on-chip hardwired "framebuffer" (tilebuffer) -- not because it defers the polygons to do the tiling thang. Somebody correct me if I'm ass-backwards.

[Side note: God, I'm getting too old for the name game. Now TMUs are TCUs? Me goes check if I have anything cold and refreshing in my Refrigeration Processing Unit ;) ]
 
Gunhead said:
Nappe, not sure if I can make it this year. I'll keep your location in mind if I do!

umm.. is it because that you have planned something else or is it because of ticket problem?

because at the moment it looks like very likely that we have one computer place too much... ;) One of my friend wasn't sure about his situation so we took one place for him "just in case". and now it is pretty clear that he can't make there...

Just let me know what's the situation...
 
DemoCoder said:
I'm not saying Matrox engineers are stupid, but if they didn't put enough effort into bandwidth efficiency, their 20gb/s could be more like 12-15gb/s in practice.

Matrox has already been quoted as explaining this will be the case is simple, dual-textured games (i.e. Quake3), but also explains the product will really pull away when using anisotropy and AA.

The point was, "raw" peak theoretical bandwidth (or of the past clock speed x pipe throughput) in it's best case scenario/theory versus occlusion/memory architecture bandwidth. Whether the former carries some profound set of circumstances (i.e. single texures, bilinear only with no Z-buffer or something similarly humorous) or whatnot due to underlying technology still remains to be seen.

In general though, raw and lesser-specialized "fat" bandwidth is much preferred over occluded or memory optimization "fake" bandwidth as not all software can benefit from the latter. Someone upgrading hardware in an effort to improve performance in select games can already experience this today, with hardware claiming substantial improvements in bandwidth/occlusion, yet performing lesser in the handful of poorly written, back to front sorted, high overdraw games that somehow "miss" the occlusion technology custom tailored benchmarks are designed to illustrate.

Loopholes in implementation can be theorized about the former approach (pipes x clock peak theoretical bandwidth), but this is what cries out for the benchmarks.. from which I already know will be soured once the product is released. Lots of greenbacks will be slapped down to continue the trend of ensuring no anisotropic filtering or anisotropic + AA benchmarks are published at "the big 5," nor are they analyzed. Here's to B3D for never subscribing to the "Big 5" mentality. :)
 
the problem being i *suspect* they are refering to 8 sample Ansio and FAA.

the big problems i see....

- Lets face it 8 sample Ansio has VERY minimal effect on IQ

-FAA will not be compatible with TONS of big name games comming out like DOOM3 and the zillion games that are based off it.

-With no apparent loopback capabilities they are going to take a BIGGER hit that GF4 and 8500 with MAX ansio. Something I use every day with my 8500. They will likely be slower not faster.
 
-FAA will not be compatible with TONS of big name games comming out like DOOM3 and the zillion games that are based off it.

Compatible , is a big word.. i mean , everything will be AA except a few things.. i mean i can live with that

can't you ? and i'm pretty sure they'll find a way to fix that ..

i'm pretty sure eh ...
 
Nappe, looks like busy elsewhere during that time :(

Hellbinder, yeah, those are my fears too. Just to be helpful... it's "an-iso-tropic" ("non-uniform-shape") instead of ansio, although the latter has become quite common on various boards -- indication that IQ is getting broader attention! :)

Muted, but we don't know what the artifacts actually are. If it's just "no AA effect" then no problem, but if it's something else then yes problem. (Somebody with connections could clarify this with Matrox?)
 
You guys should just submit questions on the news page ..

john is supposed to call matrox tomorrow..

or if you guys can send me a digital camera , a bunch of question

and an agenda , i could go down to their office ..

it's just 40 minutes from here..
 
Muted, you want a night suit and a ski mask too? ;)

Hey Hellbinder, think "anime", how's that? -- Well okay, it's easier for me, my native language is a lot more phonetic than English (which a Mr. Caxton screwed up about six centuries ago. The bastard chose an archaic spelling variety when he imported printing from Germany and locked the language in place. Now every foreigner has extra hard time learning English. This nitpicking is probably just retaliation for all the sufferings :LOL: Did you know that the last attempt to fix the situation, "Nue Spelling" [New Spelling] lost only by a few votes in the British Parliament in the 1940's? If it had won, BrEn would look totally different from what it is now -- but sound the same, of course, still the same language. Am I off topic somehow?)
 
In general though, raw and lesser-specialized "fat" bandwidth is much preferred over occluded or memory optimization "fake" bandwidth as not all software can benefit from the latter. Someone upgrading hardware in an effort to improve performance in select games can already experience this today, with hardware claiming substantial improvements in bandwidth/occlusion, yet performing lesser in the handful of poorly written, back to front sorted, high overdraw games that somehow "miss" the occlusion technology custom tailored benchmarks are designed to illustrate.

Sharkfood,

That might hold stance if someone limits it to IMR´s, much to the contrary to a deferred renderer. It wouldn´t have been the first time for Matrox anyway and in the end it would have meant half the bandwidth on paper, same theoretical peak BW, times less TMU´s, smaller die, less transistors, faster AA, more textures per pass, higher internal colour rendering depth and 2/3rd if not even half the final price.

A TBR delivers quite balanced output while handling overdraw, wether it´s front to back, back to front or random order.

I´m anxious to see B3D´s previews/reviews myself, but I´m not willing to pay the price (400-500$) various sources indicate. Especially not if there´s a high possibility that an even more feature packed Tiler with half it´s price will show up not too long from Parhelia´s release.
 
[quote="AilurosEspecially not if there´s a high possibility that an even more feature packed Tiler with half it´s price will show up not too long from Parhelia´s release.[/quote]

Go on? Which one?
 
Ailuros-
That might hold stance if someone limits it to IMR´s, much to the contrary to a deferred renderer.

That is correct, and I should have been more specific. A deferred renderer/tiler would of course be the exception, which is why Anand's commentary on the NV30 are either confusing, or at least very interesting. It's either that or the Parhelia is ridden with exceptions as Democoder theorized, in which case an IMR + z-occlusion with substantially less "real" bandwidth could (in all general cases) topple an IMR w/ no z-occlusion + substantially more "real" bandwidth.

Of course, none of us know what the real bandwidth of the NV30 will be, which is why Anand's comments are interesting. From a "past history" standpoint, and inferring from 128-bit bus, as well as assuming the Matrox part can provide a good portion of it's bandwidth under "normal" conditions (i.e. not specialized)... this begs the NV30 to be either scalable or deferred on the surface of unknowing.
 
Or the other option (and what i personally believe)..

Anand is just a cheap Nvidia Flunky Dough boy. Simply doing what daddy told him to do, and make a mysterious commnet about a future product thereby stealing some of PArhelia's Thunder. Same exact pattern he always follows. Like his first Preview of the Kyro, talking the Kyro up really really huge, the very next week, He totally drops the subject and starts making inuendos about Kyros not being compatible with The current Intel chipsets...(something never proven to be true) He went totally cold overnight, and has never to this day made one posotive comment about the kyro. He has spread misinformation about Smoothvision, Ati in general and pretty much EVERY product not made by Nvidia. the truth is out there.

IMO anand is nothing but Guidos(nvidias) Cell mate.
 
Dunno, Anand has not always done the most competent reviews when it comes to 3D technology (not as incompetent as Tom anyway, hehe), but I never nitpicked the reviews enough to suspect him of favouring Nvidia over other companies. He's made many positive comments about other products, and often critisized NVidia's too, so I still see him as kinda neutral (again, unlike Tom).

I'm sure that, like most of us, at one time or another he's had some personal preferences, which might shine through in articles. Good reviews like Beyond 3D's are hard to come by these days... ;)
 
I usually have seen Anand pretty objective, but in his Parhelia article I noticed that He made pretty big noise about missing HSR features ( and IMO there is good reason for that.) but other hand, he didn't say a word about memory controller array...

And IMO that actually makes Parhelia look pretty much worse than what image you get when you read Tom's article...

Tom's got one chapter dedicated to Parhelia's 512Bit Memory Controller Array. And as many here has said it looks like much more complex than what GF4 Ti has. 2 main channels with Multiple dedicated caches and multiple transfer optimizing logics, almost everything on memory bus is done in bursts,etc. vs. GF4Ti's quad unified cache architecture for 4 channels.
 
Randell,

Just a feeling. ;)

Sharkfood,

I have also a very strong feeling that there's a very high chance that both R300/NV30 will utilize tiling without necessarily being defered renderers. Reference as in recently presented architecture should be the P10, and both companies have ArtX/Gigapixel experties accordingly to realize it.

While in a hypothetical scenario like that a chip can't reach the effecivity of a true tiler, it will save it from doing of a lot of unnecessary computational tasks.

Recent Radeon drivers (don't ask me if they are true) had the following extensions:

R300FFVSCacheDebug
R300FFVSCacheSizeLog2
R300FFVSCache
R300VSConstMgmt
R300VSConstGranularity
R300OptimizePVSCode
ForcePrefetch
128BitVectorWrites
ForceFPUs
LocalTextureTiling
LocalTextureMicroTiling
UserScissorEnable
AllowDitherWhileBlending
ColorCompression
CMaskEnable
TCLEnable

That of course does not mean that both will rely just on that fact, as it doesn't mean that Parhelia isn't possibly utilizing a tiling method already and we just don't know it. Previews relied so far on white papers and info thrown at them from Matrox. I didn't see someone have an actual test board with beta drivers in his hands and throw them through extensive tests.

edit: typos
 
deleted.

sorry, i misinterpreted the parhelia diagram, taking the displacement mapping adaptive tess. unit for a general primitive LOD unit. so anand's article is right on this account - parhelia does not have any primitive rejection/optimization circuitry (aside from the the one for displacement mapping). my bad.
 
Back
Top