erockerLol, show me results. :rolleyes: Update or not, I'll still take the less expensive, yet more powerful, yet less power consuming chip over BD.

Trying Skyrim now, will let you know.


So far though, I'm not impressed at all :laugh:

Super XPYou can all thank me for spreading this wonderful rumour which I knew was true, but many did not believe me including the Knight Rider Moderator

Anyhow expect a 12% to 20% CPU usage increase via Skyrim, though not sure about performance yet until I get my H100 back from the shop.

:roll: no offence dude but any tard that thinks a completely new architecture of cpu shouldnt need optimisations wasnt reading the right stuff for the last few years, its obviouse like the fact that the 7xxx gpus and kepler will require optimisation in os and many other scenarios and trinity Apus again will require optimisations.

theoneandonlymrk:roll: no offence dude but any tard that thinks a completely new architecture of cpu shouldnt need optimisations wasnt reading the right stuff for the last few years, its obviouse like the fact that the 7xxx gpus and kepler will require optimisation in os and many other scenarios and trinity Apus again will require optimisations.

For me, it's still not an excuse at all, not at all, at all...

GPUs need optimisations both on games patches and drivers because you have 20 different GPUs per brand and you have 100's of games. It's 1 CPU and 1 OS. You have to have it sorted out before launch, no f* excuses.

5+ years in development, 2-3 delays. You'd think that they should have worked with MS for the "next" OS don't you? I do. Win 7 has been in development for a far shorted period than BD. If Win 7 did not have a proper scheduler who's mistake is that? Hell considering the delays Vista had to use the fixed scheduler, not Win 7, let alone 8.

EDIT: If yu think I'm kind of angry. Of course I am. It didn't take too long to release this fix after launch, so it does not seem like it was to difficult which makes all of the above 100 times worse. Now let's see if it does improve anything. I hope so. Does not look like it does improve much from what I read on this thread.

I saw a .228 sec better timing in Wprime than without the hotfix.

Bloody! Brilliant!
Didn't know what else to test that was quick :p

Try the benchmark built into WinRAR. However, you must run it three times, one right after each other, letting each test run for about 10 seconds or so(just after the result appears).

With WinRAR, I found the results don't change much, if at all, after the third test run.

BenetanegiaFor me, it's still not an excuse at all, not at all, at all...

are you jokeing or some thing i dont disagree with what your saying and why your mad but its the exact same excuse as Every other game dev uses on game day 1 and recently theirs been some ridiculouse Optimisations done ala adding dx11 etc , im just saying that yeh its shit they half finish stuff, then sell it but everyones doing that even intel x79 dosnt look half as good as it once did they made the cuts early on tho ,, it happens:slap:

Does anyone know exactly what has been changed in the scheduler? Because if it is core affinity to improve Level 1 and Level 2 caching, then we might see EQUAL GAINS on an Intel CPU. Assuming of course, MS hasn't just gifted the improved scheduler to AMD hardware only. :pimp:

Completely BonkersDoes anyone know exactly what has been changed in the scheduler? Because if it is core affinity to improve Level 1 and Level 2 caching, then we might see EQUAL GAINS on an Intel CPU. Assuming of course, MS hasn't just gifted the improved scheduler to AMD hardware only

so you think microsoft havent yet sussed hyperthreading?? its been a while, be nice if your right, but i cant see it:p

theoneandonlymrkare you jokeing or some thing i dont disagree with what your saying and why your mad but its the exact same excuse as Every other game dev uses on game day 1 and recently theirs been some ridiculouse Optimisations done ala adding dx11 etc , im just saying that yeh its shit they half finish stuff, then sell it but everyones doing that even intel x79 dosnt look half as good as it once did they made the cuts early on tho ,, it happens:slap:

No I'm not joking. CPU and GPU is not the same thing at all. On GPUs it's completely excusable, first of all because the life cycle is 1 year, and because the best you can do is work with a bunch of game developers to try and optimize beforehand, for 20 different GPU models, for 2-3 different architectures that are made obsolete every 12 months. You also have to thread for hundreds or thousands of threads, and you have to thread and optimize for a fairly hetereogeneous computig model. Pixel shaders are not equal to vertex sahders which are not equal to texture units which are not equal to raster units, you get it.

20 GPU models, 100's games, 1000's threads, 1-2 years max to work with game developers, realistically 3 months.

vs

1 CPU, couple of OS, 8 threads, 5+ years development time for both the CPU and the OS... NO EXCUSES.

This update doesn't matter to me or the other people who have waited for BD to come out but decided to go another route because of the lackluster performance. Even if its a MIRACLE 10% extra performance give or take, I'm still happy with my Sandy Bridge purchase.

Completely BonkersDoes anyone know exactly what has been changed in the scheduler? Because if it is core affinity to improve Level 1 and Level 2 caching, then we might see EQUAL GAINS on an Intel CPU. Assuming of course, MS hasn't just gifted the improved scheduler to AMD hardware only. :pimp:

All that this patch does is just make Windows try use a 'core' from idle BD modules first, rather than 'core' of BM module doing hard work already.

Intel's HyperThreading get same treatment by Windows kernel out of the box.

theoneandonlymrkso you think microsoft havent yet sussed hyperthreading?? its been a while, be nice if your right, but i cant see it:p

Not sure what you mean, but the way I read it seems you think AMDs module system works like intels hyper threading.

Hyper threading is ( VERY simplified explanation) HW based thread scheduling, it still only executes 1 thread at a time per core.

Say for example you had a single core with hyper-threading what would be happening is hyper-threading schedules the threads in such a way that it bounces between the two of them, like putting the threads in a nice orderly que.

Where as AMDS approach it can actually execute both threads at once.


This is why everyone got their pants wet at it as it was supposed to be 25-30% increase in transistors for 80% of the performance or so.

But well basically they didn't achieve it, vs the original phenom II x 4 they done pretty well

But compared to the thurban they done really badly by simply adding two extra cores they would of hit the same 1.2 billion transistors you'll find in bulldozer.

Basically if bulldozer was never delayed it would of done quite well and been a very impressive chip.

How ever I've NO idea why they didn't adjust the design, must of already committed to much to the design.

PolRogerI seem to be getting the ~same/similar score for Cinebench 11.5 (multi cpu) after updating to the hotfix.

Orange is after updating the hot fix... Blue is before:
i695.photobucket.com/albums/vv315/PolRoger/AMD%20FX/Cinebench11546GHzW7hotfixforBD.png

The new one says it's running on 4 cores?

Well I can confirme improvements with this fix on FX6100@4000 in the x264 HD BENCHMARK 4.0 and luxmark 1.0

For x264 HD BENCHMARK 4.0

before fix

Results for x264.exe r1913
==========================

Pass 1
------
encoded 1442 frames, 114.26 fps, 3913.30 kb/s
encoded 1442 frames, 114.40 fps, 3913.30 kb/s
encoded 1442 frames, 113.70 fps, 3913.30 kb/s
encoded 1442 frames, 112.87 fps, 3913.30 kb/s

Pass 2
------
encoded 1442 frames, 28.00 fps, 3959.17 kb/s
encoded 1442 frames, 27.92 fps, 3958.75 kb/s
encoded 1442 frames, 28.02 fps, 3959.86 kb/s
encoded 1442 frames, 27.93 fps, 3960.67 kb/s


After fix

Results for x264.exe r1913
==========================

Pass 1
------
encoded 1442 frames, 119.43 fps, 3913.30 kb/s
encoded 1442 frames, 119.27 fps, 3913.30 kb/s
encoded 1442 frames, 118.96 fps, 3913.30 kb/s
encoded 1442 frames, 121.78 fps, 3913.30 kb/s

Pass 2
------
encoded 1442 frames, 31.42 fps, 3958.43 kb/s
encoded 1442 frames, 31.49 fps, 3958.93 kb/s
encoded 1442 frames, 31.53 fps, 3959.72 kb/s
encoded 1442 frames, 31.56 fps, 3959.45 kb/s

-------------------------------------------------

Luxmark 1.0 64bit Native CPU

Before


After



Luxmark 1.0 64bit OpenCL CPU

Before


After




Somehow it is working 5%-10% faster
Ö

robalAll that this patch does is just make Windows try use a 'core' from idle BD modules first, rather than 'core' of BM module doing hard work already.

Intel's HyperThreading get same treatment by Windows kernel out of the box.

precisely. This is why it is utterly pointless that people out there compare 8 thread before and after performance when they should be comparing minimum-of-2-and-up-to-4 thread performance to see whether there is any difference or not.

Oh and I find it curious that nobody mentioned the fact that M$ (and possibly AMD) now consider their Bulldozer module thingy a variant of SMT ("HyperThreading in Intel lingo) whereas they were OHNOOMFGDUDEtotally8corzZ before. Had they toned down their marketing bullshit prior to launch, the dissapointment would have been a lot smaller (it doesn't perform that bad for a 4C HT chip which needs its first generation quirks ironed out).

Right since I was doing a re-install to get the hotfix to work I thought I would go one further and test without the service pack as well as with and with SP1 and hot fix:

Test rig: (all stock)
FX-8120
Asus M5A990 Evo
12 gig DDR3@ 1600MHz
3850 crossfire
OCZ vertex plus latest FW (3.55)
1010w OCZ gameXtreme
Windows 7 Ultimate Retail x64

Results:
PC mark vantage:
No service pack: 11501
With SP1: 11462
With SP1 And hotfix: 11250

Cinebench R11.5:
No service pack: 5.11
With SP1: 5.7
With SP1 and hotfix: 5.11

NovaBench:
No service pack: 1021
With SP1: 941
With SP1 and hotfix: 967

Winrar:
No service pack: 2571
With SP1: 3881
With SP1 and hotfix: 2730



Back to no service pack for me I think. Screen shots were taken for proof if ya wanna see them.

would like to see some game benchmarks please

erockerLol, show me results. :rolleyes: Update or not, I'll still take the less expensive, yet more powerful, yet less power consuming chip over BD.

Hopefully this patch will at least help those who are suffering from random, unwarranted BSOD's.

BSOD, I havent had one unless I really try and push her way up.

theoneandonlymrk:roll: no offence dude but any tard that thinks a completely new architecture of cpu shouldnt need optimisations wasnt reading the right stuff for the last few years, its obviouse like the fact that the 7xxx gpus and kepler will require optimisation in os and many other scenarios and trinity Apus again will require optimisations.

Yes I fully agree, new designs need optimisations 100%, I've been preaching all along that Bulldozer requires them Big Time, and hopefully in time AMD will get it right for Piledriver. So your point is? And no offence taken because you must have gotten me confused. I never said new designs need NO opts.

reverzewould like to see some game benchmarks please

No point unless its a threaded game, I dont have any. You might get some folks to test BF3 but Im telling you +/- 1% would be my bet

Come to think of it my bets have been crap of late.

Super XPhopefully in time AMD will get it right for Piledriver.

Not going to hold my breath.

JustaTinkererNo point unless its a threaded game, I dont have any. You might get some folks to test BF3 but Im telling you +/- 1% would be my bet

Come to think of it my bets have been crap of late.

Considering most games these days use at-least 2 cores in theory you should see an improvement in a lot of games.

pantherx12Considering most games these days use at-least 2 cores in theory you should see an improvement in a lot of games.

After looking at my results my point stands, though in theory you should.

EDIT: I paid for both winrar and PC mark just to know, I am a heartbeat off buying batman :ac to test.

Super XPBSOD, I havent had one unless I really try and push her way up.

I don't know if there's really many people getting BSODs, but I definitely think erocker knows what he's talking about.

Anyway I'm just commenting to say how useless a comment like that really is and because I've seen you making similar comments plenty of times, here and on Fudzilla a couple of times iirc (or someone with the same nick anyway, but I dobt it).

Just because you have no problems does not mean problems don't exist.

I've never been robbed, or attacked so crime surely does not exist?
I don't have cancer or AIDS, hence they don't exist? They are not a problem that needs to be fixed?

So tell me, should I go and post that I don't have AIDS in every related thread on the entire internet, so as to make clear... what?

robalAll that this patch does is just make Windows try use a 'core' from idle BD modules first, rather than 'core' of BM module doing hard work already.

Intel's HyperThreading get same treatment by Windows kernel out of the box.

I'm not sure that's right. I though this scheduler patch worked on "keeping affinity" rather than just randomly dishing out across cores.

MicrosoftThis article introduces an update that optimizes the performance of AMD Bulldozer CPUs that are used by Windows 7-based or Windows Server 2008 R2-based computers. Currently, the performance of AMD Bulldozer CPUs is slower than expected. This behavior occurs because the threading logic in Windows 7 and in Windows Server 2008 R2 is not optimized to use the Simultaneous Multithreading (SMT) scheduling feature. This feature was introduced in the Bulldozer family of AMD CPUs.

It's still slower then Phenom 2 and still way way way Behind Sandy Bridge even with hot fix, It does not make BD any less of an uber failure.

Completely BonkersI'm not sure that's right. I though this scheduler patch worked on "keeping affinity" rather than just randomly dishing out across cores.

I think this is where they're going with the scheduler. Now, that terrible sub-optimal case doesn't always happen, but it can happen. This patch will try and severely reduce the occurrence of such scheduling, and hopefully schedule as few modules as possible to engage turbo core.