Shogmaster
Sloppy seconds
aaaaa0 said:
Don't ask. That's just Vince playing his angry tech duder thing again. :lol
-
Hey Guest. Check out your NeoGAF Wrapped 2025 results here!
Xenon GPU - Unified shader > *(plus high res Ruby vid)
- Thread starter jedimike
- Start date
Don't ask. That's just Vince playing his angry tech duder thing again. :lol
aaaaaa00 said:
The former, and while in pathological cases it is highly varient, summed over the entire potential landscape of rendering programs the bound will overwhelmingly be on fragment shading programs which increase in number and size.
I responded to this above in an edit as it only appearened from you after the initial post, but on the PC developers and engine developers (the ones we care about) are more concerned with functionality and the final output/result than they are with preformance, which is a function of time. They, unlike console developers who design a game around a given architectures limitations (eg. PS2), are a better indication of where resources should be devoted.
To even argue about the fragment bias is a waste of time as it's beyond dispute. Hell, nVidia's fragment pipeline is a testiment to the rising relative time spent on computing arbitrary arithmatic programs over texture sampling.
And yes, after the way you responded douche was fitting.
Tenacious-V
Thinks his PR is better than yours.
Shogmaster said:
No kidding he's like a Snapping Turtle, only coming outa his shell to violently bite something off....
Blaster1X said:
Hardly, I was responding to his pre-edit post in which he didn't comprehend what I was saying yet was dismissive of me with some comment about not writing a line of code (heh). I'd have taken the dismissive attitude if he responded correctly as that's his choice but you really can't pull it off when you're just wrong.
Probably because I'm only compelled to post when I see something totally obtuse, namely you or one of Shog's posts... which also answers the question why I always pop up where I do Shog.
Vince said:
Uh, that's exactly what I said. NVidia's PC cards are heavy on the pixel shaders and light on the vertex shaders because they analysed PC games and discovered they are heavy on the pixel shaders and light on the vertex shaders. They did this because they need to win benchmarks in order to sell cards.
A unified architecture running one of those games that NVidia got its 1,000 common fragment programs from isn't going to gain a whole lot, because the apps are biased towards fragment programs in the first place.
That's exactly what the paper points out multiple times, saying that their analysis is using a frame from UT2004, which is not necessarily representative of what would utilize a unified archictecture optimally.
I was merely pointing out that the 8% efficiency gain Klee highlighted is irrelevant on a closed platform like 360. App developers are going to find ways to use the increased vertex shading throughput, because that's what console developers do.
Likewise, I also pointed out this was evidence suggesting that Xenos is clearly a console oriented GPU, because what it is good at is NOT what today's PC GPUs win benchmarks with.
Shogmaster
Sloppy seconds
Speevy said:
I'm rooting for myself, personally.
Vince said:
Stopped reading right there. When one has to resort to infantile barbs, this usually means "I really have nothing to say, but since I just had my ass handed to me let me call you something."
Did you answer him by the way. I have you ever written a single line of game code?
DAVEW
Shogmaster
Sloppy seconds
Speevy said:
Is that what I just stepped on?
aaaaa0 said:
Ok, we're having a failure of understanding here. Your argument is contradictory, I'll explain again:
Consoles are form-fitting, you design your game around what the hardware excels at; not what you as a developer would do if given the choice. Which is why even the Graphic Synthesizer didn't suck as much ass as it should have relative to, say, the NV2A. Thus, they are really not a good place to look if you're questioning what developer's want.
On the PC, it's an open platform. The potential landscape of rendering programs which can be implimented is vastly more open than on a console; we've seen commercial voxel renderers for example. Developer's and engine developers are more concerned with getting a given output than they are the speed and implimentability of a given technique as speed/preformance is a function of time on the PC, unlike a console.
Yet, on the PC we've seen this massive bias towards more and longer fragment programs which require resource allocation that vastly outstrips that of per-vertex work.
Just think about it, Vertex processing, back to the protean hardwired T&L, was bolted on to the 3D ASIC pipeline way before fragment work; yet it never was adopted by developers to the extent as fragment shading. They had the chance to change the paradigm but they chose not to and we have the currently evolved GPU because of it....
Now, if a developer, given the freedom, chose this current bias towards fragment processing -- why should 'you' force them to find uses for the vertex potential of this hardware as you're positing with the XGPU when they're trends pushed the GPU towards the fragment bias? I'm not saying anything about the XGPU, but rather your argument isn't sound.
Vince said:
Enh.. i don't really buy this line of reasoning. It's true that PC GPUs have evolved this way, but the reason isn't well defined. You seem to be trying to peg that reason as placing more importance on pixel shaders, but that's far too convenient, and the real answer I'm sure is much more complicated.
Vince said:
Granted.
Vince said:
And sure, yes, absolutely, the trend on the PC has been towards longer fragment programs (though this has really only picked up steam relatively recently).
HOWEVER, the point is KLee picked out the 8% efficiency gain from this paper, in a thread about Xenos, which is a GPU intended for use on the 360, a closed environment.
I'm completely willing to grant that if you run a PC game on the Xenos, you might not see a whole lot of benefit from a unified shader, given that the paper tries to demonstrate as much. (And that's before arguing if the paper is correct or not, since the paper itself admits its analysis is incomplete.)
But what I am trying to point out that this 8% is irrelevant anyway -- you'll be running 360 games, not PC games on the Xenos.
Vince said:
This is faulty logic. I know nothing about programming, but I know logic. What you have here is a bi-conditional. Meaning PC GPU's are built this way because PC developers develop this way. PC developers also likely develop this way because PC GPU's are built this way. Its a biconditional, you cant say one causes the other because they both cause each other.
There may be a good reason why it developed this way, and at one point it may have been a conditional instead of a biconditional, but at this point the two are inseperable. A GPU manufacturer cant make a GPU that breaks this trend because the games are written for a different sort of GPU, and likewise a game maker cant make a game that focuses on something the GPU's are weak at.
Tenacious-V
Thinks his PR is better than yours.
StoOgE said:
In laymens terms
<--->
:lol
Basically it's not causal, it's covariational.
rastex said:
I peg the reason as inherient to fragment programs, what they output, and how their requirements scale. If you look at typical GPGPU utilization, for an excellent example of how computation (and, thus, requirements) on the GPU is shifting, the vertex units are often sitting idle. At SIGGRAPH 2004 it was suggested that you divide up your GPGPU fragmen program for this reason.
Fragment processing requirements vastly outstrip those of vertex processing. This isn't to say anything about the XBox360 or PlayStation3.
Vince said:
Click
http://www.ga-forum.com/showthread.php?p=2338272#post2338272
Programmer or not, his opinion on anything is worthless.
Better yet, do a search on his name and read the second page. :lol He calls the Xbox 360 garbage on at least 3 occasions.
I'm certainly not lumping you in with him, since you posted nothing so ridiculous as to deserve his vote of confidence.
Nah, that's just a sign someone isn't very civil. Now, pointing out the namecalling to the exclusion of everything else a person said, *that* tends to be a sign that someone has lost the argument, or just wants to ignore it altogether.Blaster1X said:
Fortunately, aaaaa0 and Vince are old hands at this. You should really just sit back and enjoy the show.
aaaaa0 said:
Ohh, see I totally agree with you here -- beyond dispute X360 games developed for X360 will kick ass (haha). My overarching point of contention is that the subset of tasks which are well suited towards a unified shader, unbalanced/varient workload, may not map all that well with the set of tasks that a developer wants to utilize and run.
StoOge said:
No, there is causation if you knew how the programs scale in terms of computational complexity and fnctionality. There is also ample precendence in that accelerated vertex work predates fragment processing, yet it was purposely overlooked and surpassed by fragment shading. Current trends are even further reinforcing my point as the SIMD array's are being utilized in GPGPU work, where as the vertex shaders are sitting idle.
It's more akin to evolutionary selection due to morphology, which is conditional.
Vince said:
Nope programming doesnt break the rules of logic, I just think your horribly confused on how logic works.
You stated "It's not an inverse chicken-egg situation (which your argument requires)".. which makes no sense because there CANT be a reverse chicken-egg situation. the chicken-egg situation IS a bi-conditional.. one leads to the other and so forth, so neither one can be causal.
Like I said, its possible (even likely) at some point there was a good reason PC development took this path.. but if GPU's are built for a certain strength of course programmers are going to use it... it could be the case at some point a GPU was designed this way because programmers were doing these things, but at this points its irrelevent because you have a biconditional situation.. its become an infinite regress of sorts, the two are interdependent.
Speevy said:
I can bust out some really nice deontic or epistimic logic and really confuse the shit out of people, or I could bring in bivalents.. oh how I miss school
I think Im going to write a really long proof to show my point, I dont have to go into work till late.drohne said:
Anything that can be expressed by any human language is a question of logic. Logic is the basis of all human language, you really cant escape it. To say something isnt a question of logic is absolutely stupid.. and anyone from Wittgenstein to chomsky would agree with that (for those who arent into linguistics or the development of language, they are polar opposites on the nature of language, but agree on the above comment, its a basic truism, I could try and explain it, but it would take alot longer than Im willing to dedicate to this).
his arguement begs the question. He assumes A is true (GPUs are built around x). Then proves this by saying B (GPU's are good at x). The problem is he is trying to prove A not B.
So his arguement goes soemthing like
B
A->B
therefore: A
A may be sufficient for B, but it is not necessary for B. A would need to be both necessary and sufficient for B in order to prove A.. the problem is, if A is both necessary and sufficient for B, then B is also necessary and sufficient for A. So either A doesnt give us B or A is sufficient for B, in which case B is also sufficient for A and then we fall into the epistemic regress I allready discussed.
Cant escape it, its flawed logic. No amount of technical jargon is going to get out of it to, its circular.
Panajev2001a
GAF's Pleasant Genius
A quick thought: IMHO the chip efficiency comments were related to die area usage considering the number of logic transistors/Shader and Texture processors utilized.
A statement such as Xenos' 235 MTransistors are worth like RSX 300+ Million Transistors and you have not counted the Duaghter die and all that jazz... are misleading, always IMHO.
A statement such as Xenos' 235 MTransistors are worth like RSX 300+ Million Transistors and you have not counted the Duaghter die and all that jazz... are misleading, always IMHO.
how grossly irrelevant. he's not assuming that a causes b; he's arguing that a causes b from his knowledge of the field (an argument that i can't follow, incidentally). you've arbitrarily asserted that a and b are biconditional:
"if GPU's are built for a certain strength of course programmers are going to use it"
what is this "of course?" surely you're not suggesting that unidirectional causal relationships can't exist. it's nice that you can say "wittgenstein," but no, a philosophy degree does not necessarily equip you to "destroy arguments" in fields you know "jack shit" about, and your philosophy degree hasn't equipped you to make any semblance of a rigorous argument.
"if GPU's are built for a certain strength of course programmers are going to use it"
what is this "of course?" surely you're not suggesting that unidirectional causal relationships can't exist. it's nice that you can say "wittgenstein," but no, a philosophy degree does not necessarily equip you to "destroy arguments" in fields you know "jack shit" about, and your philosophy degree hasn't equipped you to make any semblance of a rigorous argument.
drohne said:
I never said he assumes A causes B. I said he assumes A is true (thats what he is trying to prove, therefore we must assume he is holding it to be true)... the problem is, he never really showed A to be true. He showed B to be true.. but B being true isnt sufficient to mean A is true. Even if you think he showed A to be true it isnt a necessary condition for B to be true, and the only way he can show a direct NECESSARY causal link between the two is either through a bi-conditional or an INUS condition. The latter of which gets him nowhere because at best he can prove it is a necessary part of a sufficient condition. So either his arguement is circular or inconclusive. Either way, he fails.
Either A must cause B and be necessary for B (in which case the opposite is true) or his arguement is incomplete and I could just as easily claim
B -> A
A
therfore B
and be just as conclusive as his arguement.
drohne said:
actually I would. I personally think causation is probably bullshit, but our language is structured on it, so you cant really escape it when communicating. I think logic is mostly bullshit as well, but you cant escape it either... if language is based on logic, you cant use language to disprove logic, and since I dont have any other way of communicating, we're sorta stuck.
I sort of buy Mackie's arguement for causation, but its an arguement thats uses extreme probability to try and prove a necessity.
Vince said:
Let's think that through.
Unified shader hardware by definition runs both pixel and vertex shader programs. Both pixel and vertex shaders define roughly the same basic math operations and control flow instructions. (There are some differences but realistically they're implementation details.)
The key difference between them lies in the way they take input and supply output.
Vertex shaders have traditionally been extremely limited in their input and output due to their location in the graphics pipeline. Vertex shaders took in a vertex, some interpolated inputs and some constants, and spit out a vertex.
A big limitation was that vertex shaders couldn't sample textures or write to textures in GPU memory. This greatly limited their usefulness for GPGPU (even in SM3.0 hardware, where ATI doesn't really support vertex texture, and NVidia's is horribly slow and not fully functional).
This is what drove people to move the more interesting computations to pixel shaders, where at least you can treat a texture as an array in GPU memory and access it without as horrible performance.
BUT
A vertex shader running on unified shader hardware by definition has access to efficient texture samplers, since it is the same hardware running both type of shader. Add the ability to arbitrarily write to GPU memory with something like MEMEXPORT, and you've essentially removed all existing limitations of vertex shaders for GPGPU purposes versus pixel shaders.
The point is, once you get to unified hardware, vertex and pixel shaders are interchangable, and so mapping one to the developer's workload (be it graphics or GPGPU) should in fact be easier than on a traditional architecture.
This is not to say that it is inconceivable that one has to make other tradeoffs for implementing unified hardware of course.
aaaaa0 said:
This is where my argument started from, Klee's stance on the trade-off's involved.
aaaaa0 said:
Better watch it, the resident philosopher is going to notice that this is a subset of my argument on fragment shading and call out another EQV/Biconditional and that you can't tell if the people drove the hardware or the hardware drove the people.... *roll*
Vince said:
Well he does have something of a point.
Realistically, I don't think it's disputable that the PC's games and GPUs did co-evolve to some degree and have been doing so since the beginning of accelerated 3D graphics.
Evidence of this is clear every time Carmack complains that he had to rewrite so-and-so code path for id-game-N because it ran like crap on vendor A's card, which results in the next card from that vendor not being so crappy on so-and-so code path, meanwhile id-game-N+1 is using a something-else code path which the vendor B has optimized for, etc.
The software evolves to run on the hardware evolves to run the software. Neither truly exists in complete isolation.
Panajev2001a
GAF's Pleasant Genius
StoOgE said:
You are mixing the logic that governs closed systems and open systems like the PC: think about DOOM 3 and how performance and graphical quality varied completely ranging from Minimum Required specs to Suggested specs and lastly to Well If You Have The Money specs.
On consoles, traditionally, the user is not given the ability to upgrade any component and is accustomed NOT to have to vary the game's graphics to change performance to his liking having more in control the balance between graphics and frame-rate basically.
On the PC, and that is not limited to games programming, the evolution of performance (especially for CPU's if you broaden the sample of programs you analyze) granted developers to optimize algorithmically, to choose beautiful and structured ways of writing code, to worry about long term maintanability, code readability, etc... (the Golden Age of programming). The PC was the platform focused by university teaching as well, pushing future developers to appreciate the rules of Object Oriented programming, Virtual Functions, etc...
On the PC usually you worry about how to properly write a program, not the maximum speed possible on a single target hardware machine. You know that by the time you release a program and especially by the time it gets adopted users will have probably upgraded their machine well beyond what you were targeting when you started development (not true for every applications though, but for many of them it is).
PC GPU's also follow this evolutionary path: vendors try to speed-up popular (at the time) applications and push new features that differentiate them from competitors (many times developers do not follow these features, sometimes they do when it makes sense for them, for what they want to do).
Console developers have a fixed hardware and iare not in 100% control of what the next-generation feature-set and performance will be.
Did all developers push for Xenon or CBE multi-core type approach ? No. Do they have to live with the decision ? Yes.
It depends, there are tons (ther have been) tons of vendors, tons of models from each vendor, tons of other parameters that affect final performance (such as CPU speed, RAM size and speed, etc...) that they can juggle around to reach the TARGET they want.
Look at DOOM 3: iD was looking for two paths in graphics and chose at the time the Unified Lighting and Shadowing path and the best approach they wanted to follow were Stencil Shadow volumes and new mapping technologies to map detail from high polygon models to low polygon models (creation of high resolution normal maps using both a high resolution mesh including inside a low resolution version of that mesh and ray-tracing algorithms that calculate how the lighting detail would basically have to map onto the low resolution mesh to make a long story short).
Do you think that double Z/Stencil rates for the GPU's Raster Operation units (or ROP's) came as a random new feature to force developer to use it ?
This argument is getting too much repetition though, in basic terms: in the console space you have a single and fixed hardware platform (multi-platform developers would not make your case any better if you think about it) you as developer HAVE to target while in the PC space you have a platform that is variable in performance at release date (many hardware configuration in a HUGE worldwide market with hundreds of million different PC's) and over time.
You say 1.) "PC developers might have been doing things in a way"... then you say 2.) "PC GPU's might have been designed to accelerate what developers are doing".
Then you say 3.) "If a GPU is designed in a way, developers are going to code for that GPU's strengths" and then 4.) "now there is a bi-conditional situation".
I have problems with how you generalized assumption 3.) ... on the PC space we have seen many developers developing a solution (their ideal solution) and then doing some optimization work on that solution to target several hardwares doing some specific rendering paths as and and if they need to target from low end to high end configurations (the discussion over ARB, ARB2, NV30, R200, etc... DOOM III rendering paths got enough attention over here too), but leaving a generalized rendering path which contains their preferred solution targeting the constant refreshes of products that keep increasing performance over their predecessors and if you are a big name developer with much influence on the market you can probably get GPU developers to accelerate your algorithms rather than having to simply look at what GPU is available and designing around that processors capabilities every aspect of your engine. You do not have to and so far that has been the beauty of programming on PC (for those who like it).
You also push a little to the side on assumption 3.) and on assumptions 1.) and 2.) appropriately to convey what is your thought of inter-dependency: you push the assumption that the extent which PC developers affect GPU's development is equal to the extent which GPU's development affects PC developers practices. That exact world IMHO does not exist and it is an over-generalization to make:
I also have problem with the statement 4.), I think you are not proving how that conclusion necessarily follows from your logic argument. You describe a "some point in time" past and make fast0forward to the NOW and state that the situation si different and there is a "bi-conditional situation".
It does not matter the size of your logic, but how you use it
. How sure can you be of decomposing the argument in clear logic passages if, as you said, do not really know the argument itself ?Using logic to destroy arguments is nice, but it is not very useful or constructive in debates especially if you do not have a solid base of discussing the argument itself (and that can happen to anyone at any level... I am not assuming to be Einstein here): you criticize yet you do not posite.
Panajev2001a
GAF's Pleasant Genius
aaaaa0 said:
True, but we have seen Carmack developing his path first, then having to add rendering paths for some cards and the IHV making those cards was already hurrying to accommodate DOOM III's rendering performance in their drivers and in their next-generation architectures.
Not even in the console arena there is a clear complete isolation (it is not true that developers have 0 input over what features, how much performance and the hoops to pass through to access it given the vendor's implementation of said features and performance improvements). My point is that in both markets, so far, there has been a difference in how hardware makers and software makers influenced each other, although it is changing in both markets (it is a dynamic relationship).
Developers willing or not, even on the PC side sooner or later we will get to have to deal with multi-core processing: of course I'd argue that any sane developers looking for ease of coding and transport of his clean and idealized OOP code to a multi-processor architecture would want to go to a 2-4 way Opteron/Xeon system with gobs of cache, uber-advanced OOE, SMT, Branch Prediction, Prefetching, etc... so we won't see CELL or XeCPU on PC anytime soon, but a less radical push to multi-core. The markets are different and so are their evolutionary paths IMHO.