AMD Radeon R9 Fury X Reviews

[Rys]

@Jawed said:

The shader I posted is ALU bound on Tahiti (so should be on Fiji), now that I play with it in CodeXL (had to rewrite as HLSL ). Regardless, it seems we agree that it's possible to test the effect of defeated delta colour compression without relying upon a texture. I'm not sure what else is required to ensure that the test becomes a pure fillrate versus bandwidth test. What per-architecture foibles are lying in wait?

Also, what pixel formats should be tested: 32-bit RGBA is the default presumably. What about 16-bits per channel? etc.

 

[Rys]

@Rys said:

Yeah, more formats are a good idea. The B3D test that TR used is RGBA8888, but I also I sent an updated version of the bandwidth tests to Scott with a bunch of different surface formats. Not sure if he'll look at them any time soon. I really should just buy a Fury X and play with it myself, might do that if I can find one in stock.

As for generating the data in the shader versus using a texture, I don't think it'll show up anything too interesting, but I'll add a shader only version to the suite. Can't hurt! Thanks for the suggestion.

 

[Rys]

@3dilettante said:

One thing that might be interesting to check would be the comparison between the shader-only and texture methods.
In an ideal world, the bandwidth of the texture input and the compressed/uncompressed pixel output would just come out of the same overall bucket, but that kind of back and forth is itself a challenge that caching and compression can influence.

 

[Rys]

@AlexV said:

So, does anybody around here have Fiji && Maxwell, while also being up for doing some voluntary labour? We can roll our own little thing here in this thread until the big boys come out with results

 

[Rys]

@A1xLLcqAgt0qc2RyMz0y said:

Yes.

Great I always look forward to AnandTech's reviews because of the extensive details in them.

 

[Rys]

@Tridam said:

Yeah, more formats are a good idea. The B3D test that TR used is RGBA8888, but I also I sent an updated version of the bandwidth tests to Scott with a bunch of different surface formats. Not sure if he'll look at them any time soon. I really should just buy a Fury X and play with it myself, might do that if I can find one in stock.

As for generating the data in the shader versus using a texture, I don't think it'll show up anything too interesting, but I'll add a shader only version to the suite. Can't hurt! Thanks for the suggestion.

So, does anybody around here have Fiji && Maxwell, while also being up for doing some voluntary labour? We can roll our own little thing here in this thread until the big boys come out with results

Temperature around my desk is not really asking for me to power up those beasts but well if you have something in mind to try that won't take too long I can sweat a little more

 

[Rys]

@AlexV said:

Temperature around my desk is not really asking for me to power up those beasts but well if you have something in mind to try that won't take too long I can sweat a little more

Thank you Damien! Let me put something together and make sure that at least at a first approximation makes sense (albeit my hardware endowment is...err...Spartan). As far as I recall you are comfortable with building stuff from source (in VS), yes?

 

[Rys]

@Rys said:

Can't your copy of VS generate binaries?

 

[Rys]

@3dilettante said:

Courtesy of:

http://stackoverflow.com/questions/5149544/can-i-generate-a-random-number-inside-a-pixel-shader

and:

https://www.shadertoy.com/new

I wrote a randomcolour pixel shader:


Why can't we use something like that to test fillrate and compression?

Saving that as a PNG for a 1920x1080 image produces a file that's 5954769 bytes. That's 2.87 bytes per pixel, which includes PNG file format overhead (a few thousand bytes as far as I can tell). So, there is some compressibility in this image. Enough to defeat GPU delta colour compression?

Along those lines, playing with the math a bit can produce the same color for successively larger regions of pixels, which might reveal some of the granularities used by the compressors.
A generated checkerboard pattern could iterate over varying rectangular dimensions, and then maybe rotate it to mix up the grid a little.

Maybe create a taupe or sea foam base texture, since driver writers now know that it's either random or a pure black texture. Not that I'm paranoid.

The texture-based path could be used to feed whatever patterns suit the tester's fancy, which I suspect the GPU designers would be doing in some form as well.

 

[Rys]

@Tridam said:

Thank you Damien! Let me put something together and make sure that at least at a first approximation makes sense (albeit my hardware endowment is...err...Spartan). As far as I recall you are comfortable with building stuff from source (in VS), yes?

Yes I am. However since my SSD died in Taiwan last month, I didn't have much time to set up those kind of things on the new install (yeah my kind of old laptop is my main working system hehe) So binaries would be much faster to deal with

 

[Rys]

@Rys said:

Maybe create a taupe or sea foam base texture, since driver writers now know that it's either random or a pure black texture. Not that I'm paranoid.

Not that there's any real point optimising for a contrived case of single colour rendering in driver software. If that wasn't as fast as possible already I'd be rather surprised (within the bounds of it not really being feasible to do whole program analysis at runtime).

 

[Rys]

@3dilettante said:

Not that there's any real point optimising for a contrived case of single colour rendering in driver software. If that wasn't as fast as possible already I'd be rather surprised (within the bounds of it not really being feasible to do whole program analysis at runtime).

I am forced to admit to having some paranoia.

Actually knowing some contextual information about inputs could be useful in a future compression scheme, if for example it allowed the heuristics to reduce their cache residency for the compressor's tables or adopt a more optimistic prediction scheme. I yield to your point that this scenario is so simple that it shouldn't need the help.

 

[Rys]

@gamervivek said:

Seems to be more relevant the further down you go, unless 960 is sporting a newer compression method.

http://techreport.com/review/27702/nvidia-geforce-gtx-960-graphics-card-reviewed/4

Meanwhile Gregster of ocuk fame finds his Fury X review in a place he doesn't like.

http://forums.overclockers.co.uk/showpost.php?p=28258333&postcount=2391

 

[Rys]

@trinibwoy said:

Meanwhile Gregster of ocuk fame finds his Fury X review in a place he doesn't like.

http://forums.overclockers.co.uk/showpost.php?p=28258333&postcount=2391

Something is way off there. The last run he did looks like there's no AF on the Titan (e.g. on the white line parallel to the curb).

 

[Rys]

@fellix said:

The ground texture on Titan X is definitely lower detail -- missing AF or biased LOD?

 

[Rys]

@CarstenS said:

Texture skipping due to low available memory?

 

[Rys]

@Rys said:

On a Titan X?

 

[Rys]

@A1xLLcqAgt0qc2RyMz0y said:

Note that Tom is using a Lian Li PC-T80X which is open case design so their experience may not be reflective of the majority of users who use standard cases.

As it turns out open or closed test cases have the annoying whining.

http://www.pcper.com/reviews/Graphics-Cards/Retail-AMD-Fury-X-Sound-Testing-Pump-Whine-Investigation

It also appears that AMD may have sent Golden Samples (less noisy ones) to reviewers.

 

[Rys]

@ToTTenTranz said:

How's the status on Anandtech's review?

Ryan's last tweet about the subject was 2 days ago, but the twitter feed from everyone at anandtech has been awfully quiet..

 

[Rys]

@pharma said:

There is a way to determine whether you have the bad batch ... bad has multi-color cooler label. We need Fury X noise tests sans color label on cooler.

http://www.guru3d.com/news-story/amd-fixes-r9-fury-x-whining-noises.html