blu
Wants the largest console games publisher to avoid Nintendo's platforms.
You got that backwards. Fixed-function = predefined shading model(s) you only pass parameters at. Programmable shaders = you define your shading model from the ground up.
-
Hey, guest user. Hope you're enjoying NeoGAF! Have you considered registering for an account? Come join us and add your take to the daily discourse.
WiiU "Latte" GPU Die Photo - GPU Feature Set And Power Analysis
- Thread starter Thraktor
- Start date
- Status
I thought all of the shading done in the fixed function units in the GC and Wii were custom shaders ie. defined by the programmer? I was sure I saw that in quite a few different places.
http://www.neogaf.com/forum/showthread.php?t=104248
http://www.giantbomb.com/wii/3045-36/forums/jett-rocket-392474/
http://forums.dolphin-emu.org/Thread-is-it-not-possible-to-use-the-operator-in-the-custom-shaders
http://wiinside.blogspot.com/2008/12/for-last-timethe-wii-is-more-powerful.html
https://handheldwii.wordpress.com/2009/01/15/7204382/
http://www.nintengen.com/2007/07/wii-has-more-power-than-you-think.html
http://www.ign.com/boards/threads/wiis-tev-unit.175866696/
I guess I've been reading false information all of this time.
lostinblue
Banned
^ Oh, c'mon.
That's semantics, TEV pipeline was fixed function; it was somewhat programmable/manipulable in the middle but really limited to what was already there.
That wasn't a problem (against xbox) bar the fact nobody took the time to understand it because Shader Model 1.1 was limited as well (limited being different than fixed function) by comparison with further shader model revisions so there really isn't anything the Xbox can do that GC and Wii can't match; it's in that sense that people said GC/Wii actually had shader units "of sorts".
But the boost you got in, say, EMBM being used on every surface of some games was pretty much a TEV and ETB (embedded texture buffer) combo; everything was cheaper to do because you were essentially combining fixed function hardwired calls to create something custom.
That's semantics, TEV pipeline was fixed function; it was somewhat programmable/manipulable in the middle but really limited to what was already there.
That wasn't a problem (against xbox) bar the fact nobody took the time to understand it because Shader Model 1.1 was limited as well (limited being different than fixed function) by comparison with further shader model revisions so there really isn't anything the Xbox can do that GC and Wii can't match; it's in that sense that people said GC/Wii actually had shader units "of sorts".
But the boost you got in, say, EMBM being used on every surface of some games was pretty much a TEV and ETB (embedded texture buffer) combo; everything was cheaper to do because you were essentially combining fixed function hardwired calls to create something custom.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
I'm afraid things are more complicated than that. Flipper is a fixed-function vertex pipeline combined with what is best described as ps1.4-ish pixel shaders (the TEV); the flexibility of the pipeline is largely bound by the vertex part. In comparison, 3DS' Picca is programmable vertex shaders (vs2.0) with what is best described as a predefined set of mix-n-match shading techniques (somewhat like a TEV, but aimed more at a certain set of shading models) . Of the two platforms, 3DS got the combination right - programmable vertex shaders are more important in the big picture of flexibility. Compared to both, a fully-programmable vertex + pixel (+ geometry) shading pipeline is way more flexible in expressiveness - it can be programmed to do things the other two pipelines cannot handle, like say, ray tracing. ..Well, it theory they might, but it would not be an efficient implementation by any stretch of the imagination.
Essentially, the efficiency / flexibility spectrum goes like this: fixed-function <--> entirely programmable.
Fixed function gives best performance per transistor towards the final goal (best possible efficiency), but that comes at the expense of limiting the final goal.
Programmability gives best expressiveness, but that comes at the expense of more transistors (and potentially lower clocks, and potentially lower performance), ie. less transistor efficiency per any given goal.
While neither Flipper nor Picca are sitting at the extreme left, a contemporary GPU is not sitting on the extreme right either - it also has its fixed function parts, and will likely keep those for generations to come.
That didn't really clear things up for me. In fact, that just makes me even more confused especially given things I've seen done on the TEV by factor 5 and by Nintendo like in Mario Galaxy 2. Your description makes everything seem so middling.
Seems to me that sticking with the fixed functions would be the overall best option. I haven't seen anything done on modern GPUs that couldn't be done by a more robust assortment of fixed function pipelines besides tessellation(though didn't someone say that was done in Wind Waker?). If the Wii having twice as many compared to the GC allowed for a shading increase of the likes seen from Mario Sunshine to Mario Galaxy, then what effect would doubling or quadrupling the number have?
Ah well, I guess its a moot point. I'd say it pretty well establish that the Wii U's GPU uses standard, modern shaders now. What do you call the lighitng that they used in ZombiU? I've honestly never seen lighting like that used before.
http://cdn1.sbnation.com/uploads/chorus_image/image/6699511/zombiu-super-wide.0_cinema_640.0.jpg
http://cdn.wegotthiscovered.com/wp-content/uploads/zombiu11-e1353875914692.jpg
http://image.gamespotcdn.net/gamespot/images/2012/320/reviews/673013_20121116_640screen002.jpg
Seems to me that sticking with the fixed functions would be the overall best option. I haven't seen anything done on modern GPUs that couldn't be done by a more robust assortment of fixed function pipelines besides tessellation(though didn't someone say that was done in Wind Waker?). If the Wii having twice as many compared to the GC allowed for a shading increase of the likes seen from Mario Sunshine to Mario Galaxy, then what effect would doubling or quadrupling the number have?
Ah well, I guess its a moot point. I'd say it pretty well establish that the Wii U's GPU uses standard, modern shaders now. What do you call the lighitng that they used in ZombiU? I've honestly never seen lighting like that used before.
http://cdn1.sbnation.com/uploads/chorus_image/image/6699511/zombiu-super-wide.0_cinema_640.0.jpg
http://cdn.wegotthiscovered.com/wp-content/uploads/zombiu11-e1353875914692.jpg
http://image.gamespotcdn.net/gamespot/images/2012/320/reviews/673013_20121116_640screen002.jpg
A
A More Normal Bird
Unconfirmed Member
Fixed functions would have been a great way of ensuring they got even less third party support than they do now. Developers don't want to throw out their shading model and be forced to try and recreate their visual direction using fixed hardware. Programmable shaders also allow a more flexible allocation of computing power.
As for the Zombie shots, the horizontal light beam effect coming off the bright light sources is called anamorphic lens flare.
frankie_baby
Member
I'm under the impression that accessing the fixed functions (should they exist) could be handled completely invisibily to the developer by the api or SDK or something
A
A More Normal Bird
Unconfirmed Member
I'm pretty sure this would still mean that existing shader code would not be able to be ported. If the API was capable of translating any programmable code into parameters that fixed function hardware could execute it would be positively miraculous. That said, I'm of the opinion that there is no evidence for any extensive fixed function shader hardware in the Wii-U GPU.
A
A More Normal Bird
Unconfirmed Member
It means you can. Plenty of current gen games use deferred lighting or deferred shading.
You really don't understand enough how these things work.
Fixed function is like a switch board. The TEV in the Wii has 16 stages. If i remember correctly, for each stage you specify two inputs, an operation and an output. Inputs can be a texture sample, the interpolated vertex colors, the final per-vertex lighting color, a constant value, the result of the previous stage or the value stored in a register. The output can be a register (don't remember how many there were, probably two) or the next stage. You could also use the result of a stage to modify the coordinates used to sample a texture in another stage (example: Mario Galaxy normal-mal-esque effects).
A sequence of operations with inputs and outputs does kinda sound like a program, doesn't it? This is why TEV and Register Combiners (the Geforce2 equivalent) are sometimes called proto-shaders. The problem is that it was horribly limited: your program can only have 16 "instructions" out of a very small palette (basically adds, muls and such).
DirectX10-class GPUs can run shaders with thousands of instructions and their instruction sets are massive, including things like square root, sine, cosine, matrix operations, conditional branching, loops and much more. This mean you can make truly complex stuff and there's enough headroom for rolling your own lighting algorithms. With the TEV, lighting was always done per vertex and all your "shader" could do is decide how it would get combined with the textures.
Nostremitus
Member
I've been thinking about this myself, but I'm under the impression that the opposite happens. The programmable shaders have been modified to effectivley emulate a fixed function part if it recieves the proper coding. Hence the backkward compatibility. For instance, it's a programmable shader, but if you feed it code meant for the TEV, the API translates it on the fly or the shader simply reads it as is and performs. My understanding is that this means that if Nintendo wanted to, they could still produce Wii U games using an updated version of their existing shader model while also allowing third parties to use theirs as well.
Does that make sense?
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
The API translating the TEV state & ops into shaders is the way more viable option here. You have two extra CPU cores that would twiddle their thumbs in wii mode, so you could let them do some translation work there.
frankie_baby
Member
Nostremitus
Member
So, the API redirect>CPU>scratchpad>GPU>render would have to happen just as fast as Hollywood>render?
I wonder if the odd sizes of the shaders account for silicon that would allow native rendering of TEV code. That would allow Nintendo to use their shader model outside of Wii mode.
Full disclosure: I'm guessing and don't really understand programming or hardware on this level. I participate here in order to learn.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
It surely could. Question is, how fast is the translation and the subsequent GPU DMA. On the Wii, that stuff was going predominantly over a write-gather DMA pipe. If the emulation can match that in terms of latency, it should be good.
lwilliams3
Member
On the subject of dx10/dx11 features for the Wii U, it should be noted that its API is modeled after OpenGL. The OpenGL 3.x is the feature equivalent to DX10.1, but they are different. For one, OpenGL 3.x didn't support hardware tessellation at all. In fact, hardware tessellation was one of the big additions to OpenGL 4.0, which is more of a dx11-equilivant in features. Compute Shaders was also not added until OpenGL 4.3. This may prove that Wii U GPU's features are beyond the base r700 from the API perspective.
Fourth Storm
Member
I've been wondering this more myself lately, as the 160 shader scenario does deserve serious thought. Also, according to Marcan, only 1 CPU core is active in Wii mode, so that seems to point to TEV instructions being read by the GPU.
A couple other short tidbits:
On Flipper/Hollywood, the Triangle Transform Engine performs the task of automatically filling up the embedded texture memory. Does this mean that it needs to be included on Latte or is there a way some other functional block can perform this task?
Many pages back, I proposed that Latte may include hardware interpolation units, fixed fucntion blocks which are also found in the R700 series. How did Flipper handle interpolation? Actually, I'm a bit fuzzy on what interpolation actually means in a graphics programming scenario, so anyone who could chime in with a short explanation would be welcome. Google searches on the topic are only feeding me pages that go straight over my head. haha
That's discounting vendor-specific extensions, which would be pretty relevant to a console.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
Interpolation in this context means the process of computing pixel attributes, which attributes originally come via per-vertex computations (or directly from vertex attributes). Such interpolation can be perspective-correct or linear (normally the former), and until the R800 there was dedicated fixed-function circuitry that was tasked with that. From the R800 onward the shader ALUs have taken over the function. The major reason for doing that shift of responsibilities is that since the number of interpolants can vary greatly from shader to shader, GPUs with dedicated circuitry have to either provide for the worst case, thus leaving this circuitry idle during the rest of the time, or provide for some average case, thus facing situations where shader ALUs starve as their interpolant arguments are not delivered at the optimal rate. The natural solution to that would be to make the shader ALUs capable of computing all the interpolants they need, which is what R800 does.
tkscz
Member
That and OpenGL 3.9 is simi-backwards compatible (best way I can put it in layman's terms) with OpenGL 4.0.
But you also have to think of opengl like the android platform. Different people can take the base platform and make it into what ever they want it to be. Its open source. If you want to add compute shaders to a version of opengl then you can. Its not a "you get what we have" approach.
That would be possible, but time consuming, money consuming and absolutely pointless being that a much more advanced and modern OpenGL was already available for free. What purpose would it serve to waste resources to tweak the old one to run like the current one when you could just use the current one? It is the same question I ask with the GPU base specs of the HD4XXX vs HD5550. Why spend all of that money to make an old GPU mimic the exact stats of a more advanced GPU that both already performs better, draws less power, and "costs less"?
There would be no rational logic to such things. Why are people insisting, almost hopingly, that Nintendo chose to spend more money for less efficient/capable technology? Its like they refuse to even consider anything more than the lowest denominator.
Iwilliam3 has made a good point. We do "know" that it is not using DX and that is does support hardware tessellation. There have also been many nuances that point to the features be DX11 level. It would make the most sense for them to be using OpenGL 4.0 at least.
Also, in the wake of it being discovered how customized the chip is, why do people absolutely refuse to let go of it being an R7XX chip when that was never more than just a rumor from the time it was said to have 768 MB of RAM and a 3.6 Ghz processor? Its so odd the way people are selectively denying and insisting on rumors based on whether they are higher end or lower end respectively.
I think that would be called forwards compatible, no?
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
Yes.
The R700 info comes from Nintendo's own developer fact sheet, which has been confirmed as legit a bunch of times. Now, it's obviously quite far removed from the original R700 after all the customisations, as we can see in the die shot, but that it's originally based on the R700 isn't really up for debate.
frankie_baby
Member
is it not possible the r700 bit is outdated though and refered to what was in dev kits at the time, as didnt early dev kits have a 4850 in them which obviously is r700
frankie_baby
Member
and flipper does?
I'm pretty sure it was still in the fact-sheets given out quite recently (ie after final hardware was in devs' hands).
We need to get back to the good old days when every games console was legally required to have a component named "Reality" somethingorother.
frankie_baby
Member
ah ok, we aint ever gonna really know what its like though
oh we've long since gone past reality, all systems now are more real than the real world
ExigentContact
Member
"Dolphin" and "Flipper", "Hollywood" and "Broadway". Nintendo does not usually use powerful names for their hardware's guts for whatever reason.
Fourth Storm
Member
Dude, did you ever watch the show, Flipper? That dolphin was taking out sharks left and right.
Thanks for explaining that to me! Makes sense. I do still wonder if they've kept the fixed function units. I know they presented limitations for the RV770, but Latte doesn't have quite the oomph of that chip, so perhaps it wouldn't be such a bad thing...
Smurfman256
Member
Hey guys, a dude working on the game and talking to PA said that they were able to add AA to Deus Ex: Human Revolution when they ported it to the Wii U, citing that this was due to the hardware.
http://www.penny-arcade.com/report/...-wii-u-has-graphic-improvements-new-game-play
A game actually looking better on Wii U due to hardware?!?!?! UNHEARD OF!!!!!!
http://www.penny-arcade.com/report/...-wii-u-has-graphic-improvements-new-game-play
A game actually looking better on Wii U due to hardware?!?!?! UNHEARD OF!!!!!!
Sweet.
DemonCleaner
Member
well "latte" also means errected penis in german . maybe that does more for you.
Nostremitus
Member
Here in the states (I know, trust me... I know...) When we say latte, we're actually referring to a café latte. The name just follows the whole "Project Café" name scheme.
I wonder how much of that is simply due to the larger memory pool the Wii U has.
When I look at NFS and why it has higher res textures on some assets the feeling I get was it had nothing to do with increased power but rather just more physical memory available.
The framerate is better as well.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
If you'd bother to read the DF article you'd see NFSMWU also draws more things per frame than the ps360 versions - namely more reflection geometry.
"Pedneault was cagey about details and wouldn't get into specifics, but said that the Wii U hardware allowed the team to feature a new lighting system, improved fog, improved shadows, and antialiasing."
I think it takes a lot more than memory to do all of that.
The new lighitng system has me most interested. I wonder if it will be like the lighting we saw in ZombiU.
I doubt it.
The 4850 is more powerful than what is in the Wii U, far more silicon and shader units. Why would they put more powerful hardware in the early dev kits only to disappoint developers once the final hardware came out.
It's not. Check out Need for Speed Most Wanted U.
Smurfman256
Member
If there was one thing about ZombiU that was "pretty", it was definately the lighting.
By better you mean more stable, right?
Yes. I think its pretty safe to say that the lighting capabilities of the Wii U are dx11 "level". Now, all that is left to see is the capability of the tessellater.
If the Froblins demo is anything to go by, then we can expect a graphical feast from Shin'en.
ElectricKaibutsu
Member
Edit: Nevermind, totally misread that
OG_Original Gamer
Member
What level of anti-aliasing is possible, if a port has no improvements technically other than maybe 4x anti-aliasing or 6x?
Smurfman256
Member
I was being a tad sarcastic, laddie.
Impossible to answer, as it would depend on the game/engine/porting job.
- Status
Similar threads
- Poll
- Poll