[QUOTE=J!NX;52773488]I'd believe it[/QUOTE]
You're talking about the man who wrote this:
[CODE]float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
return y;
}[/CODE]
Of course he can optimize better than nVidia or AMD techs. Just look at that beauty.
[QUOTE=Trekintosh;52773527]You're talking about the man who wrote this:
[CODE]float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
return y;
}[/CODE]
Of course he can optimize better than nVidia or AMD techs. Just look at that beauty.[/QUOTE]
He didn’t write that though
[QUOTE=J!NX;52773488]I'd believe it[/QUOTE]
And he's probably capable of proving it without dropping his maximum smugness face.
[t]https://i.imgur.com/TgfqTYO.png[/t]
[t]https://i.imgur.com/rAJ8z1v.jpg[/t]
Actually, could someone merge those two pictures?
[QUOTE=Tsanummy;52773613]
Actually, could someone merge those two pictures?[/QUOTE]
[t]https://i.imgur.com/AQ7KlKw.png[/t][t]https://i.imgur.com/Vwv8YRm.png[/t]
this isn't working out
Why are driver updates to increase performance in single game titles a thing in the first place? This needs to stop.
[QUOTE=Tsanummy;52773613]And he's probably capable of proving it without dropping his maximum smugness face.
[t]https://i.imgur.com/TgfqTYO.png[/t]
[t]https://i.imgur.com/rAJ8z1v.jpg[/t]
Actually, could someone merge those two pictures?[/QUOTE]
[t]http://puu.sh/xWyfb.png[/t]
[QUOTE=Anglor;52773544]He didn’t write that though[/QUOTE]
What?? I was certain that Carmack wrote the Fast Inverse Square function.
[QUOTE=Trekintosh;52773669]What?? I was certain that Carmack wrote the Fast Inverse Square function.[/QUOTE]
Be certain no more. It is a common misconception though.
[QUOTE=cartman300;52773649]Why are driver updates to increase performance in single game titles a thing in the first place? This needs to stop.[/QUOTE]
What do you mean? The drivers increase performance because they are more geared to work with the game in question. The difference is not always noticeable, but it can be for some systems. Maybe if all games and gpu's just worked together perfectly all the time then we could "stop this practice" but it's practically necessary for now.
[QUOTE=Tetracycline;52773796]What do you mean? The drivers increase performance because they are more geared to work with the game in question. The difference is not always noticeable, but it can be for some systems. Maybe if all games and gpu's just worked together perfectly all the time then we could "stop this practice" but it's practically necessary for now.[/QUOTE]
No it is not. It is backwards.
The game should be optimized to use the provided API per specification, not update the driver to bend the API so it runs better because the game misuses it.
[editline]12th October 2017[/editline]
It's like updating the operating system every other week because some programs are shitcoded and crash.
[QUOTE=Tetracycline;52773796]What do you mean? The drivers increase performance because they are more geared to work with the game in question. The difference is not always noticeable, but it can be for some systems. Maybe if all games and gpu's just worked together perfectly all the time then we could "stop this practice" but it's practically necessary for now.[/QUOTE]
But how would a driver be "more geared to work with the game in question" if all games are supposed to use same graphics APIs and stuff?
This means that these updates are probably a bunch of messy kludges in an `if(processImageName == "mygame.exe")` or similar. Which is basically shitcode and shouldn't be a thing.
And why does this even happen anyway, do some games use graphics APIs in a retarded way or what? Again, this feels like shitcode.
[QUOTE=mijyuoon;52773867]But how would a driver be "more geared to work with the game in question" if all games are supposed to use same graphics APIs and stuff?
This means that these updates are probably a bunch of messy kludges in an `if(processImageName == "mygame.exe")` or similar. Which is basically shitcode and shouldn't be a thing.
And why does this even happen anyway, do some games use graphics APIs in a retarded way or what? Again, this feels like shitcode.[/QUOTE]
Correct me if I'm wrong, but graphic drivers provide profiles for each game to use a certain value. New games usually use some modified engine, so then they release a driver update that has a new profile just for that game that has, what they think, the most optimized values for the driver to use with that game. Most of the time those profile values were made for a different game so they just use those instead of making new ones ie what used to be the case for skyrim when it first came out for ambient occlusion compatibility so I would have to change it myself to the setting value for oblivion or fallout new vegas (one of those). I think at one point even when they did release its own setting value, but it was better on one of those values. I'm pretty sure they could do better, but it's probably so much work that they don't bother.
It's because there's 10,000 ways to write a basic function and really most major optimisations are going to be engine or game specific because of this. A driver update that makes a UE4 game work better, will generally increase performance to some degree in all UE4 titles. Of course largely this comes down to each developer's engine, and methods. There's no single, universal, best implementation of a process in some cases. Shit lets just look at containers in C++ alone, (A container is just well, a container for classes, objects if you will, imagine a box for storing objects) you have vectors, arrays, deques, lists, forward lists, sets, maps, multi sets and multi maps, then you have the unordered set/multi set and unordered map/multi map. Think of it as everything from an organised filing system to a simple "stuff put in first is on the bottom of the box" kinda thing. So which one is literally the best container ever and everything else is "hello world" kiddie shit code? None of them. These all have pros and cons and there are reasons you would or wouldn't want to use them for certain applications, and times when even those rules of thumb may not apply to your specific program. Time and time again people may just use them for something that isn't quite optimal because well, idk, I'm not them. They may have to choose to sacrifice performance here in one aspect of their container operations because another set is far more critical to the program. It's hard to just attribute it all to "shit programming" when even on the most basic level you're going to finds stuff like this.
Lets get even more basic. Imagine you want to increment variable X by 1. How do you do it?
A. X = X+1;
B. X++;
C. X += 1;
If you answered any of those you're correct. They all end with exactly the same output, x is incremented by 1. However they're not the exact same process technically and have different performance impacts on an almost irrelevant level in most programs. Now imagine scaling this up to leagues more complicated processes on an entire engine and game scale, where these kinds of things are actually important. They're going to have pros and cons to each method and a developer probably picked their specific method because it worked best for how their game or engine is set-up. Alternatively they may not have and are just shit, but largely when a driver is able to make a game better it's engine level changes that are being accounted for. A game optimised driver just basically changes the priority and flow of the api to suit a specific engine or developer's implementations on said engine. So again, you'll usually find that a driver update containing a profile optimised for a certain game might actually improve performance across multiple games on the same engine for just that reason.
[QUOTE=F.X Clampazzo;52774182][...]
Lets get even more basic. Imagine you want to increment variable X by 1. How do you do it?
A. X = X+1;
B. X++;
C. X += 1;
If you answered any of those you're correct. They all end with exactly the same output, x is incremented by 1. However they're not the exact same process technically and have different performance impacts on an almost irrelevant level in most programs.
[...][/QUOTE]
But they all compile to literally the same machine code (assuming a native language is used and it's a primitive type without postfix increment overload)
[img]http://carp.tk/$/NLPD5q.png[/img]
Yeah they all compile to the same machine code but we're talking going from that machine code to the input and outputs we humans understand so really saying that "it's all machine code" is irrelevant. At the end of the day it's all just 1s and 0s but unless you can tell me that you're able to play just a stream of binary coming down a square wave at 3.5ghz or whatever the clock speed we're operating at then you're taking the piss. We're talking about shit happening on the higher level that has to be compiled and interpreted down to that lower level then brought back. Humans can't understand machine code. To a computer moving a register is pretty simple shit, it'll do thousands of those all day long, but we're talking going down, back up, and doing so millions of times in a time frame that effects our perception of the result as little as possible. It's like saying take care of the pennies and the pounds take care of them selves. Modern computing is too complex for us to take care of the pennies anymore so we had to write languages and APIs and such to take care of the pennies for us as best we can.
[QUOTE=F.X Clampazzo;52774335]Yeah they all compile the same machine code but we're talking going from that machine code to the input and outputs we humans understand. That is what takes time.[/QUOTE]
...what? If they compile to the same machine code, then anything that that machine code does is going to be [i]exactly identical[/i] to that same machine code being compiled from any of the other methods.
[QUOTE=geel9;52774342]...what? If they compile to the same machine code, then anything that that machine code does is going to be [i]exactly identical[/i] to that same machine code being compiled from any of the other methods.[/QUOTE]
You guys are intentionally dodging the question or not understanding the problem I feel. It's not about "the same machine code". It's about the individual instructions taking more time than others based on the hardware. Higher level code is just visualisation and emulation of the hardware. There's no "right way" to do things. Shit if it's all machine code why are Intel and AMD cpus different? Why do we have OS X, Linux and Windows? It's all the same machine code! The key difference is how the computer takes the higher level shit we humans understand and translates it to the real machine code for it to actually run down on the hardware level. Drivers are literally just profiles tweaking that process to make specific implementations of said process faster or better in certain circumstances for individual hardware.
If we want to talk basic machine level shit, lets take it to the concept of gates and really just make it super duper fucking simple. Game engine A and engine B are making a set of XOR gates, right? Now lets take CPU X and CPU Y. CPU X can process 1000 OR gates a second, 100 AND gates and 100 Inverters. CPU Y does 100 OR gates, 1000 AND gates and 1000 inverters. The numbers aren't really important but they do these things faster or slower respectively. Lets say that Game engine A. decides that it's going to take our high level virtual gate code and turn it into 5 OR gates chained up properly on the machine level. Engine B says that an XOR gate is 2 inverters, 2 AND gates and an OR gate. This, on a machine level, is the same thing, it's an xor gate, it runs the same computations yeah, but in a slightly different order. They're going to get the same result though. But cpu X is going to run this virtual gate faster in Game Engine A's configuration than engine B's. Cpu X is better at processing the logic for a bunch of OR gates due to its physical construction of handling OR gates much faster than either ANDs or inverters. Hardware differences impacting performance. So a driver update happens and the driver basically says, "okay guys, just, make this into 5 or gates." So now engine B is running as fast as engine A, and all it was was changing how the higher level code is being given down the line. But CPU Y does OR gates like ass in comparison to inverters and AND gates? Well, for CPU Y the driver is going to say, "alright guys, look, this is an XOR gate, run it like 2 inverters, 2 ANDs and only 1 OR gate because this CPU doesn't do OR gates this fast.
Of course the real world performance of a single XOR gates isn't really ever going to be something we humans would notice on our own. Like maybe nano second tier. But scale that sort of shit up to something that's actually demanding. CPU Y has to do 10 trillion XOR gates, well it can't do it as fast as CPU X does because CPU X has more/does it faster. Drivers just tell CPU Y that it can do this XOR thing in a way that it does it faster. It's not a disconnect at machine code, you're still virtual. You need to think how the hardware its self plays into the machine code's execution time.
Drivers aren't magic, they're taking specific, recognised parameters and changing them to make them more efficient on a given piece of hardware. Saying that developers should just "code better" is basically asking them to change their engine for literally every hardware configuration imaginable with insider knowledge of how hardware works that is possibly trade secret.
John Carmack?
huh never heard of him
he sounds like a pretty cool guy though
[QUOTE=Egon Spengler;52774504]John Carmack?
huh never heard of him
he sounds like a pretty cool guy though[/QUOTE]
he's the guy who made windows
Carmack still full of himself, I see. This man is not humble at all.
[QUOTE=Conna;52775400]Carmack still full of himself, I see. This man is not humble at all.[/QUOTE]
I don't think I'm exaggerating much if I say he's potentially one of the smartest people on the planet. His name is so legendary, I don't think he has much use for humility.
[QUOTE=Conna;52775400]Carmack still full of himself, I see. This man is not humble at all.[/QUOTE]
Why should he be humble? It's the same motherfucker who's started a new era of gaming [I]twice[/I] now.
Carmack seems like he's a down to earth dude but he's the kind of guy that doesn't bullshit you, even at the expense of seeming like an asshole. Personally, I've never seen the guy as an asshole or full of himself, but just take a look at even an incomplete list of the stuff he's accomplished and the sheer level of mastery he has over his fields. Dude is on a whole other level
[QUOTE=Egon Spengler;52774504]John Carmack?
huh never heard of him
he sounds like a pretty cool guy though[/QUOTE]
eh fights demons and doesnt afraid of anything
[QUOTE=Egon Spengler;52774504]John Carmack?
huh never heard of him
he sounds like a pretty cool guy though[/QUOTE]
[QUOTE=Paul-Simon;52774575]he's the guy who made windows[/QUOTE]
Image of Carmack programming on a keyboard
[t]http://68.media.tumblr.com/479be69aa6d62a477ea7824f77f49c79/tumblr_inline_ncspziCnJw1qa6fgj.jpg[/t]
the man we know and love
john carmack literally invented shadows
you'd need to wear sunglasses all the time if it wasn't for that man
John Carmack had a cat
It knocked over a glass in the office
John dies not have a cat now
Sorry, you need to Log In to post a reply to this thread.
