** The Official Nvidia GeForce 'Pascal' Thread - for general gossip and discussions **

[CAT-THE-FIFTH]

Next month is next week.

True - hopefully they will spice it up a bit!!

 

[andybird123]

Re-read what i wrote, it follows the same lines as the dev that you cannot overuse async and reasons why. Hence, Are you able to comprehend the English language?

All you saw was my DM mention and jumped on it like a child. DM gets too much flack from a certain crowd on here when he comes up with many valid points.

your train of thought doesn't necessarily stack up though - oxide have said that they aren't using very much async, not that you can't use too much

io interactive said they tried to use more of it but found that different AMD GPU's will accept differing amounts before it causes a penalty - hence you CAN try to use too much, which is the opposite of what you and DM have been trying to say

 

[Mauller]

your train of thought doesn't necessarily stack up though - oxide have said that they aren't using very much async, not that you can't use too much

io interactive said they tried to use more of it but found that different AMD GPU's will accept differing amounts before it causes a penalty - hence you CAN try to use too much, which is the opposite of what you and DM have been trying to say

Of course you can try to use excessive amounts and it be a detriment. when i say you 'cannot use too much async', i mean that large amounts is detrimental. That is what me and DM are saying, i guess the wording is a bit ambiguous for some. Which is why i further talked about having to balance Async between the work you are doing and slipping it in when you can. which should imply that you are unable to use too much.

Should have said 'You are unable to use excessive amounts of Async'

 

[Telecaster]

and slipping it in when you can.

Ooh err, I think we all try and slip it in when we can, not sure what that has to do with GPUs though

 

[Mauller]

Ooh err, I think we all try and slip it in when we can, not sure what that has to do with GPUs though

OCUK, AfterDark.

 

[Evian]

Hurry up my 780 needs upgraded!

 

[drunkenmaster]

you said you cant use too much async, like you cant use too much hyper threading... cue developer saying its not like threading for cpu, you have to carefully tune it per gpu and that using it too much causes a penalty... and you come back with the usual big long post trying to claim you never said that thing you said

I never even mentioned tesselation

FIrstly that is the post, you directly quoted no-one at all.

Second..

cue developer saying its not like threading for cpu

This was not in the article you quoted at all, you merely added this all by yourself.


You made this up.. I asked you to quote where I said I supposedly claimed I didn't say this..... you couldn't because I didn't withdraw the claim. Instead you claimed you directly quoted me(you didn't, another lie) and I never said that at all. After claiming that... you then had your cronies +1 all your posts agreeing with this thing you simply made up. Again I ask you to point out where I took this claim back.

You replied to my post which was part of a conversation with bru trying to liken overuse of async to overuse of tessellation. Async is on or off, it's not 'an amount'. Tessellation is on at varying levels or off, you can over use it. You can kill performance using 64x tessellation where anything over 8x provides zero visual difference. That is the 'type' of overuse that bru, who I was responding to, was talking about. Async is a means to implement effects, it is not an effect itself. Saying you can overuse async is akin to saying you can overuse a cpu core or overuse shaders, or a memory bus. You may not want to admit the obvious difference or the context within which the term was being used... in fact you won't, but that doesn't matter.

As for a developer, developers dumb **** down for the audiences they are talking to and they talk **** all the time. You can use async for 2x ssoa, or you could use it for 128x ssoa.... that is overusing AN EFFECT, not overusing async itself, you could do this effect via a graphical effect and not within async compute and it would still be an overused effect. You can't just use async to provide infinite graphical quality through infinite number of effects at infinitely high settings... zomg, really?

Go back, read the first post in this conversation you quoted, read the post i replied to and then pretend the context is what you're now claiming it to be.

 

[FrenchTart]

Thread re-opened.

I've deleted a ton of posts here and I expect the arguments to stop NOW.

If the thread has to be cleaned up again it will be closed and suspensions issued.

 

[JediFragger]

What happened to the 'strike' system FT? Maybe that could be implemented to calm the nutters down??

 

[Ayahuasca]

Agree Jedi, mentioned it before but they don't seem to use it any more.

 

[FrenchTart]

It's still in place and strikes are still being issued. I can't say more than that for the moment

 

[Mauller]

Async is on or off, it's not 'an amount'.

Async is a means to implement effects, it is not an effect itself. Saying you can overuse async is akin to saying you can overuse a cpu core or overuse shaders, or a memory bus.

You may not want to admit the obvious difference or the context within which the term was being used... in fact you won't, but that doesn't matter.

I think you are not explaining in the right way DM.

Async is a way to perform work in parallel and concurrently. What can have a detrimental effect when using async is if too much work is queued up in parallel. Especially if something requires more processing power than you are giving it for the time you want it to be executed in.

So you can have a detrimental effect if too many threads need executing in the minimal time possible, considering you are overscheduling resources.

Hence this is where the developers are simplifying it and saying that too much Async is detrimental to performance. Since it makes it easier for people to understand compared to threading and resource scheduling etc.

I understand where you are coming from, Asynchronous computation is just a method for running code in parallel, it is either used or not. It is the amount of work that you run in parallel that can be a detriment to performance, not asynchronous compute itself. Well as long as your hardware can perform asynchronous compute without excessive context switching penalties.

 

[andybird123]

Async is on or off, it's not 'an amount'.

Not according to the devs at Io interactive or oxide.
Sorry but i will take their word over yours.

This is where you and mauller are getting way off base, its pretty difficult and highly unusual to "over thread" an application running on a CPU, usually devs have the opposite problem and load too much work on to a single thread, so comparing it to hyperthreading is disingenuous

Io are saying that creating extra compute threads on the GPU gives you a performance advantage up to a certain point, but creating too many gives a performance disadvantage, and that how many you create is different for each GPU type... sound familiar? Because it sounds a lot like those grapbs showing the different queue depths between maxwell and AMD gpu's

Oxide dont argue against what Io have said because all theyve said is that they actually arent creating many extra threads, but due to the nature of what they are doing they are getting decent improvements from it anyway

So no, its not just on or off, it requires tuning on a per gpu type basis to get the best performance from it

 

[One Vision]

Thread re-opened.

I've deleted a ton of posts here and I expect the arguments to stop NOW.

If the thread has to be cleaned up again it will be closed and suspensions issued.

Im new here but id like to ask "Why do you delete posts, why not just leave them as they are for people to read?" I would have been interested in seeing what was said tbh.

 

[easyrider]

Im new here but id like to ask "Why do you delete posts, why not just leave them as they are for people to read?" I would have been interested in seeing what was said tbh.

A few here post nothing that adds to anything.

Reading them is futile.

A bit like looking at the sun

Literally no point in it.

 

[CAT-THE-FIFTH]

A few here post nothing that adds to anything.

Reading them is futile.

A bit like looking at the sun

Literally no point in it.

Page 3 of The Sun used to be OK sometimes!

 

[psychas]

sold 980ti for 466 quid and have 500 quid spare hopefully can get something good for it , and at least 50 to 70 % performance would be nice .

 

[Rammix]

I will eat my hat if the pascal Ti or Titan comes out this year... I would love to be wrong however.

 

[easyrider]

sold 980ti for 466 quid and have 500 quid spare hopefully can get something good for it , and at least 50 to 70 % performance would be nice .

What will you be using for the next 6 months ?

 

[Mauller]

Not according to the devs at Io interactive or oxide.
Sorry but i will take their word over yours.

This is where you and mauller are getting way off base, its pretty difficult and highly unusual to "over thread" an application running on a CPU, usually devs have the opposite problem and load too much work on to a single thread, so comparing it to hyperthreading is disingenuous

Io are saying that creating extra compute threads on the GPU gives you a performance advantage up to a certain point, but creating too many gives a performance disadvantage, and that how many you create is different for each GPU type... sound familiar? Because it sounds a lot like those grapbs showing the different queue depths between maxwell and AMD gpu's

Oxide dont argue against what Io have said because all theyve said is that they actually arent creating many extra threads, but due to the nature of what they are doing they are getting decent improvements from it anyway

So no, its not just on or off, it requires tuning on a per gpu type basis to get the best performance from it

They are over simplifying the underlying principles by squishing it all under the moniker of Async compute. You either Run something asynchronous or you don't, it just means that you run something out of order and concurrently instead of synchronous and consecutive to the main flow of the progam.

There are no levels to being Asynchronous, just the amount of work you perform in parallel. whether it is many threads or just a few they are still just Asynchronous, there is no level to them or amount to being asynchronous.

The comparison to hyperthreading revolves around using Bubbles in the pipeline where no work is being computed in some part of the hardware, you aim to slip work into these bubbles which is what hyperthreading and Asynch compute aim to do.

This is going down to the very grit of how superscalar processors perform work, since although it is a single core, they process multiple instructions down multiple pipelines. Usually a single thread will be broken up into multiple parts and fed down these pipelines to improve IPC, but there can be bubbles where no work is being performed, which is where hyperthreading steps in to help fill these bubbles.

This is the comparison with Async, since you are filling bubbles in the pipeline with extra work.

Also that Threading and queue depths comparison was using a very light workload per thread, so the comparison is not as direct. It just shows how many threads the processors can handle concurrently.

The real grit of the async compute is the amount of work do per extra thread you add within those bubbles, which is why they say they are not using many extra threads but still getting a boost.

It starts becoming a detriment when you try to queue up too many heavy threads and exceed the processing power left over by the bubbles, you then start impeding the process which should have been running in that time as you are taking up resources it requires. Which then leads to a detriment in performance as that original process has had to take longer to finish.

So if you are trying to execute compute threads in parallel without managing resources, you end up with an overall detriment.