Chiphell: AMD 3xx perf. leak

[doz]

Im just wondering when we will get away from 28nm. Im not sure they have been stuck on a process for so long???? 3 years coming up and possibly pushing 4 years.....

 

[The Mac]

I am a programmer, FYI. But it is basic parallelism concepts that fundamentally and inherently cause game loops to be notoriously difficult to substantially multithread. The operating system or api have no relevance or relationship to this fact. This is common knowledge, no debate needed indeed, just as sure as water is wet. Thank you .

Here's one readily available developer statement from the first page of Google results about this that I told you to go look at earlier rather than continuing to spread misinformation :


http://forums.riftgame.com/general-.../352460-tech-talk-rift-performance-2-2-a.html

Again it isn't poor optimization or lazy devs as you falsely claim.

i dont know what you are going on about.

i said DX11 is the threading bottleneck for modern games.

nothing in what you posted is even romotely related to my statement.

again, i suggest you google game programmer blogs and read there cheif complaint: Inability to submit asynchronous batches. Because of the way its structured, there can be only one worker thread submitting batches. Mantle/DX12/OGLnext removes that limitation.

 

[GoldenTiger]

i dont know what you are going on about.

i said DX11 is the threading bottleneck for modern games.

nothing in what you posted is even romotely related to my statement.

again, i suggest you google game programmer blogs and read there cheif complaint: Inability to submit asynchronous batches.

I responded directly to what you wrote, and even if you're backpedaling your revised claim is still outright wrong. It's clear you have no interest or intention in holding any actual discussion and are just trying to incite a reaction from me, so I'll leave you to it. Have fun!

 

[GoldenTiger]

Im just wondering when we will get away from 28nm. Im not sure they have been stuck on a process for so long???? 3 years coming up and possibly pushing 4 years.....

Check this thread out :


http://hardforum.com/showpost.php?p=1041276574&postcount=44

 

[FrameBuffer]

I am a programmer, FYI. But it is basic parallelism concepts that fundamentally and inherently cause game loops to be notoriously difficult to substantially multithread. The operating system or api have no relevance or relationship to this fact. This is common knowledge, no debate needed indeed, just as sure as water is wet. Thank you .

Here's one readily available developer statement from the first page of Google results about this that I told you to go look at earlier rather than continuing to spread misinformation :


http://forums.riftgame.com/general-.../352460-tech-talk-rift-performance-2-2-a.html

Again it isn't poor optimization or lazy devs as you falsely claim.

bwwaahahaaa.. where to start ?!!

Rift is one of the absolute WORST examples you could even attempt to use. Rift uses very slightly modified DX9 based engine (Gamebryo) that is over 10 years old. Funny enough, much of that developer's statement has still yet to materialize. Look up Gamebryo AND DX11 or multithreading .. pages and pages of promises dating back years (with regard to multithreading) and they barely make use of more than dual cores.

With regard to your supposed "programming" experience.. please feel free to share what published projects you were lead on and then maybe we can discuss making it past Basic 101.

 

[GoldenTiger]

bwwaahahaaa.. where to start ?!!

Rift is one of the absolute WORST examples you could even attempt to use. Rift uses very slightly modified DX9 based engine (Gamebryo) that is over 10 years old. Funny enough, much of that developer's statement has still yet to materialize. Look up Gamebryo AND DX11 or multithreading .. pages and pages of promises dating back years (with regard to multithreading) and they barely make use of more than dual cores.

With regard to your supposed "programming" experience.. please feel free to share what published projects you were lead on and then maybe we can discuss making it past Basic 101.

It's common knowledge in the field, and I am under nda for current ones anyway . Nor would I even care to go in the mud with you in any case. Not my job to teach you, as I said a basic Google search will show even the most neophyte person who has no idea how computers work that what I said is true.

EDIT: Also, get your facts straight. Rift used the gamebryo editor early on for world prototyping but used their own custom engine for the actual game. As I said, basic Google searches show you wrong .

 

[GoldenTiger]

hahaha

nice try.

Considering your history of completely inaccurate and just plain wrong posting, you are as much of a programmer as i am a Nuclear Physicist.

You're still wrong and can't help but resort to ludicrous personal attacks once more. Fantastic! Here's a quote confirming my statement about rifts engine straight from the developers.

http://forums.riftgame.com/general-...ssion/420-game-using-cryengine.html#post74120

Rift uses a custom engine, derived from Gamebryo. We began development with Gamebryo, which provided an awesome head-start, and we were able to get up and running quickly. Over time we customized or replaced most of the major pieces, providing our own solutions for lighting, animation, shaders, model streaming, and other components. We have talented in-house staff that develops our custom engine, so we control our own rendering destiny instead of waiting for someone else to provide features or support.

As was stated elsewhere, the Rift engine uses DX9 for best compatibility, with great visuals. It's a deferred renderering architecture, which allows for some cool effects, and makes it cheaper to render scenes with large numbers of point lights like you see in the video trailers. Night time looks especially awesome in Rift, with every fire, lamp, and spell casting a flickering glow on the world around it. Nothing is pre-baked: all of the lighting is dynamic, which of course is necessary for a game based around dynamic content.

Although I'm a Trion gear-head, my hat's off to the team's art staff, who have created some truly amazing stuff. At the end of the day, no amount of whiz-bang rendering technology will turn a dull, flat environment into a compelling one. Look at Gloamwood, or Darkening Deeps, or Silverwood. Look at the quality of the character models, the NPCs, and the animations. The art team has created some incredible content while working within the box the programmers have provided. They've developed custom shaders for everything from horse hair to tree bark. Go read through the developer intro thread again to see some of the artists who have helped created one stunning-looking game.

 

[Michaelius]

Im just wondering when we will get away from 28nm. Im not sure they have been stuck on a process for so long???? 3 years coming up and possibly pushing 4 years.....

And then 16 nm will stay here even longer

 

[LordEC911]

And then 16 nm will stay here even longer

Really depends on how quickly fabs can integrate EUV and similar technologies and not balloon the R&D cost.
At least 2, maybe 3, years is the current estimate.

 

[Vexerz]

I bet the guy is just a software/firmware tester and probably overhears the engineers talking in the break room...cut him some slack.

 

[KazeoHin]

Guys, don't resort to personal attacks: even accusing someone of being biased or calling out trolling counts as a personal attack in these forums now. I would know: I just got off a ban for calling someone a troll. If someone makes a wild, uninformed, unsupported, highly loaded and extremely convenient argument, you can't actually call them out.

On topic: multi threading applications is quite easy, it jus requires an out-of-box approach. The reason so many companies are still insisting to use single and dual-threading approaches is the same reason they still compile in 32 bit X86.

 

[Rizen]

I think you guys are arguing different things. There is more going on in a game engine than just the renderer. Yes, draw calls are a bottleneck in the graphics engines in some instances. But there is also work being done by the CPU for AI, sound, physics, loading assets, feeding the graphics cards, etc above and beyond what your GPUs are doing to display graphics. Multi-threading the whole game engine is not as trivial as people are making it out to be.

 

[GoldenTiger]

I think you guys are arguing different things. There is more going on in a game engine than just the renderer. Yes, draw calls are a bottleneck in the graphics engines in some instances. But there is also work being done by the CPU for AI, sound, physics, loading assets, feeding the graphics cards, etc above and beyond what your GPUs are doing to display graphics. Multi-threading the whole game engine is not as trivial as people are making it out to be.

Exactly, of course there is more to a game than just the DirectX renderer .

 

[GoldenTiger]

Guys, don't resort to personal attacks: even accusing someone of being biased or calling out trolling counts as a personal attack in these forums now. I would know: I just got off a ban for calling someone a troll. If someone makes a wild, uninformed, unsupported, highly loaded and extremely convenient argument, you can't actually call them out.

On topic: multi threading applications is quite easy, it jus requires an out-of-box approach. The reason so many companies are still insisting to use single and dual-threading approaches is the same reason they still compile in 32 bit X86.

It's interesting how often convenient arguments are available when you're arguing for the facts and the truth . And no, multithreading a full game engine is not anything like setting a simple compiler flag with further qa testing done like you are implying. Game software workloads are, as I've said ad nauseum, by their nature not terribly conducive to the principles of parallelism and thus are quite difficult to significantly multithread to an appreciable extent overall. This is hardly news, but rather complete common knowledge to anyone with even the slightest amount of programming under their belt.

 

[jwcalla]

I think you guys are arguing different things. There is more going on in a game engine than just the renderer. Yes, draw calls are a bottleneck in the graphics engines in some instances. But there is also work being done by the CPU for AI, sound, physics, loading assets, feeding the graphics cards, etc above and beyond what your GPUs are doing to display graphics. Multi-threading the whole game engine is not as trivial as people are making it out to be.

Very true. And all of those things have to ultimately be synchronized, of course. People think of all the things that go on in a game and think they can just throw each of those tasks on a core and let it rip, but game play itself (or a game loop) is really a highly-synchronized process, and that synchronization costs performance.

It's true that rendering a single frame is easily parallelized (hence GPUs), but there's more to game play than that. Multi-threading the rendering process (on the CPU) can benefit in areas where the GPU is underutilized, but that's about it. And we've had multi-threaded rendering (granted, limited to two threads) for years now... well at least in OGL; I'm sure D3D is similar.

 

[cageymaru]

Tera was the worst optimized MMO I've ever played. Rift was the second. Don't even try raiding in Rift on an AMD 8 core. It was like standing in molasses as you were at sub 15 fps the entire time. And all of my cores were doing absolutely nothing the entire time. Tera was only worse because I could hide my UI and go from 20 fps to 60 fps. Some Autodesk limitations reasoning was given long ago.

If you could drive a real game engine under either of those games I would play them forever.

 

[darkeen]

On topic: multi threading applications is quite easy, it jus requires an out-of-box approach. The reason so many companies are still insisting to use single and dual-threading approaches is the same reason they still compile in 32 bit X86.

Multi threading is easy when you can split one task from another. Games are particularly hard to thread as nearly everything that happens depends on what the gamer does. I mean, you can't just have a physics engine doing it's own thing having a building fall down if the player never triggers the explosives for it and if the falling down (B) depends on the triggering of explosives (A) it makes no sense to have A spawn a new thread for B as that would be slower than A->B in one thread.
If you think about the flow of a game very VERY little happens without interaction from the player. Using the example above, maybe the function call collapseBuilding() can be internally threaded (though maybe not), but you can't just arbitrarily call the function without dependence on the main game thread.
tl;dr Making threads is easy, using them is not.

 

[GoldenTiger]

Multi threading is easy when you can split one task from another. Games are particularly hard to thread as nearly everything that happens depends on what the gamer does. I mean, you can't just have a physics engine doing it's own thing having a building fall down if the player never triggers the explosives for it and if the falling down (B) depends on the triggering of explosives (A) it makes no sense to have A spawn a new thread for B as that would be slower than A->B in one thread.
If you think about the flow of a game very VERY little happens without interaction from the player. Using the example above, maybe the function call collapseBuilding() can be internally threaded (though maybe not), but you can't just arbitrarily call the function without dependence on the main game thread.
tl;dr Making threads is easy, using them is not.

As I said before :
"
Game software workloads are, as I've said ad nauseum, by their nature not terribly conducive to the principles of parallelism and thus are quite difficult to significantly multithread to an appreciable extent overall. "

 

[KazeoHin]

It's interesting how often convenient arguments are available when you're arguing for the facts and the truth . And no, multithreading a full game engine is not anything like setting a simple compiler flag with further qa testing done like you are implying. Game software workloads are, as I've said ad nauseum, by their nature not terribly conducive to the principles of parallelism and thus are quite difficult to significantly multithread to an appreciable extent overall. This is hardly news, but rather complete common knowledge to anyone with even the slightest amount of programming under their belt.

It truly depends on the aim of the engine, and regardless of any application, games or otherwise, coding for multiple cores is big-boy work. Not a lot of people want to beat down new paths when the existing old paths are nice and worn-in.

As for game engines, more and more are using multiple cores, but the truth is that the type of game determines the necessity or lack thereof of a higher parallel throughput. A fighting game, for example, has so few variables but each of them need to interact precisely with each other, it is verry difficult to take a parallel approach to this. AI is also quite difficult to multithread, as in most engines, there is a single AI that controls every NPC in the game, and most of its instructions are heavily serial. Splitting the AI into multiple controllers would allow the use of multiple threads, but the many AI masters would have to toss around a ton of variables among each other, and duplicate a lot of memory. It essentially would make it slower on the weaker systems.

Something like a simulation engine can split its various 'layers' (physics, audio, AI) on to different threads, but some threads are much more demanding than others, and the split up can only go so far as allowing one thread per 'subsystem'.

But in cases like Minecraft where a ton of simultaneous actions are taking place at once on a very well-defined grid, a server could allocate a 'thread' to each player, and that thread could simulate the world around her/him as basically an instance of the game. Engines built from the ground up for modern 4+core systems are trying to split every possible task into a self-contained subsystem and have the 'master' thread really exist just to hold variables.

It's possible, but it requires coders (who typically rely on legacy libraries and functions to speed up dev time) to build from the ground up, and it requires them to forsake slower, dual-core machines as not everything can be batched into one thread in the fly. Long story short: if they had lots of time and did not have a legacy library, it would be the norm.

 

[darkeen]

But in cases like Minecraft where a ton of simultaneous actions are taking place at once on a very well-defined grid, a server could allocate a 'thread' to each player, and that thread could simulate the world around her/him as basically an instance of the game. Engines built from the ground up for modern 4+core systems are trying to split every possible task into a self-contained subsystem and have the 'master' thread really exist just to hold variables.

The problem with that assumption is that the game world needs to stay in sync between players. If player A and player B are in different chunks of a minecraft world then yes you can assign a thread to each. But, Players tend to be in the same chunk and if player A drops a block in front of player B you don't want player B to be able to step into the space where player A dropped a block. In a single thread this is easy to deal with. In a multithreaded world this is fucking hard... Like crazy fucking hard.

On the "legacy" libraries that people are using; minecraft uses java which will auto parallelize where is can. There's not much. In C there is the pthread library which has been around for quite a long time but does about anything you could want from a thread. A master thread is more than just holding variables. It needs to manage locks between threads in order to keep the timing correct and to maintain a stable game world. This is not a trivial task and many threads can end up with the performance of a single thread if the timing is sequential.

 

[Digital Viper-X-]

Tera was the worst optimized MMO I've ever played. Rift was the second. Don't even try raiding in Rift on an AMD 8 core. It was like standing in molasses as you were at sub 15 fps the entire time. And all of my cores were doing absolutely nothing the entire time. Tera was only worse because I could hide my UI and go from 20 fps to 60 fps. Some Autodesk limitations reasoning was given long ago.

If you could drive a real game engine under either of those games I would play them forever.

have you tried Lineage 2 ? it was pretty bad... didn't even have to raid, just walk into a busy town!

 

[Digital Viper-X-]

The problem with that assumption is that the game world needs to stay in sync between players. If player A and player B are in different chunks of a minecraft world then yes you can assign a thread to each. But, Players tend to be in the same chunk and if player A drops a block in front of player B you don't want player B to be able to step into the space where player A dropped a block. In a single thread this is easy to deal with. In a multithreaded world this is fucking hard... Like crazy fucking hard.

On the "legacy" libraries that people are using; minecraft uses java which will auto parallelize where is can. There's not much. In C there is the pthread library which has been around for quite a long time but does about anything you could want from a thread. A master thread is more than just holding variables. It needs to manage locks between threads in order to keep the timing correct and to maintain a stable game world. This is not a trivial task and many threads can end up with the performance of a single thread if the timing is sequential.

I'm pretty sure that has nothing to do with multi-threading, and more to do with the netcode.

 

[darkeen]

I'm pretty sure that has nothing to do with multi-threading, and more to do with the netcode.

We're assuming a thread per player interacting with a global data structure (the game world). If player A drops a block into a place that player B is entering, how do you resolve the order of those events? How do you resolve it when two players try to drop a block into the same space?
These are threading issues and there are ways to deal with them, but they're not trivial and they don't give you linear performance scaling with threads/cores.

 

[Digital Viper-X-]

We're assuming a thread per player interacting with a global data structure (the game world). If player A drops a block into a place that player B is entering, how do you resolve the order of those events? How do you resolve it when two players try to drop a block into the same space?
These are threading issues and there are ways to deal with them, but they're not trivial and they don't give you linear performance scaling with threads/cores.

Again, they are not threading issues. You would have the same issue, if it's on 1 thread, or 40.

it's more of a netcode / logic issue than it is a threading issue, and it's a very simple one to solve. if 2 events happen at exactly the same time, which one gets priority to execute if they conflict?

A more realistic threading problem is a race condition, and that is not limited to games.

 

[darkeen]

Again, they are not threading issues. You would have the same issue, if it's on 1 thread, or 40.

it's more of a netcode / logic issue than it is a threading issue, and it's a very simple one to solve. if 2 events happen at exactly the same time, which one gets priority to execute if they conflict?

A more realistic threading problem is a race condition, and that is not limited to games.

Again. No. It's a data structure coherence issue. Yes you have the issue in a single thread, but it's trivially resolved as both players input into a single thread which is ordered.

Assume both players are playing on the same machine. You need either one of two things to resolve the block drop issue.
a) Global clock that all threads reference
b) Locks on every minecraft block space

In a) you have a thread increment a clock and the threads time stamp their input from players in order to say who dropped the block first. This ends up giving you near single threaded performance.
In b) you need to set aside a bit (at least 1 bit anyway) to "lock" each minecraft block. Thread 1 gets the lock on the space the player wants to place a block. If it gets it then it places the block and unlocks. Else the player can't drop the block. This gives good threaded performance, but it's at a cost.
1 bit per block plus the cost of locking and unlocking. See Mutex locking/unlocking here
https://gist.github.com/hellerbarde/2843375

This IS a threading issues and specifically it's a thread timing issue. It certainly isn't free to resolve.

Edit:
This thread has gone quite off topic. Please PM me if you wish to continue the discussion.

 

[Digital Viper-X-]

Again. No. It's a data structure coherence issue. Yes you have the issue in a single thread, but it's trivially resolved as both players input into a single thread which is ordered.

Assume both players are playing on the same machine. You need either one of two things to resolve the block drop issue.
a) Global clock that all threads reference
b) Locks on every minecraft block space

In a) you have a thread increment a clock and the threads time stamp their input from players in order to say who dropped the block first. This ends up giving you near single threaded performance.
In b) you need to set aside a bit (at least 1 bit anyway) to "lock" each minecraft block. Thread 1 gets the lock on the space the player wants to place a block. If it gets it then it places the block and unlocks. Else the player can't drop the block. This gives good threaded performance, but it's at a cost.
1 bit per block plus the cost of locking and unlocking. See Mutex locking/unlocking here
https://gist.github.com/hellerbarde/2843375

This IS a threading issues and specifically it's a thread timing issue. It certainly isn't free to resolve.

Edit:
This thread has gone quite off topic. Please PM me if you wish to continue the discussion.

No way, no pm for you, we can just agree to disagree and move on.