Review - AMD Radeon R9 290X - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Misc (https://hashcat.net/forum/forum-15.html) +--- Forum: Hardware (https://hashcat.net/forum/forum-13.html) +--- Thread: Review - AMD Radeon R9 290X (/thread-2798.html) |
Review - AMD Radeon R9 290X - epixoip - 11-10-2013 UPDATE Dec 21 2013 I take back everything negative I said about this card. Catalyst 13.12 and od6config resolve all issues I identify below. Performance increase over the HD 7970 ranges from 23%-60%, with 64-bit hashes seeing the least benefit, and DES-based hashes seeing the biggest gains. Overall the 290X is 36.7% faster than the HD 7970 on average, which is greater than the projected 35% performance increase. With every generation, AMD finds some new and exciting way to piss us off. They've really outdone themselves this time with the release of the R9 290X. I was so excited to try this new card out. It looked so promising. With a 35% increase in stream processors over the HD 7970 and 5.9 TFLOPS of raw compute power, on paper it looked like a single GPU card that was faster than the dual-GPU HD 6990. So you can imagine how stoked I was when I finally got my paws on eight of these shiny new bastards. The excitement increased as I pulled one of the boxes out, and was greeted by this badass alien robot demon cyborg guy: I really dig the new shroud design as well. Not at all professional, but it appeals to my inner child: I was too excited to build a new system just for these cards. I wanted to test them RANNOW. So I cannibalized a system that I had already built out with four HD 7990s, and stuffed it full of 290Xs. Damn, these cards look fantastic stacked on top of each other! All right, let's power up the system and check them out. Code: opencl@sagitta:~$ lspci | grep VGA Hah, awesome. The device identifies itself as an HD 8970. That will likely cause some confusion with the other Tahiti-based HD 8970 that is out there. The driver gets it right though. Code: opencl@sagitta:~$ amdconfig --lsa And here's the truncated clinfo output as well while we're at it: Code: opencl@sagitta:~$ clinfo X failed to start of course, because this system has Catalyst 13.9 on it, and 13.9 doesn't support the R9 line. Not a problem, upgrade real quick to 13.11beta6 and reboot. Great, X came up this time. Now we're ready to launch Hashcat and start having fun! Erm, wait... Something is missing... I didn't hear the fans spin up. We set the fan speed in Xsetup so that the fans spin up when X starts. But there is no fan noise at all, and these new GPUs are supposed to be insanely loud... let's investigate. Code: opencl@sagitta:~$ DISPLAY=:0.0 amdconfig --pplib-cmd "get fanspeed 0" That's awesome. Apparently we can't get/set the fan speed on this new card. Oh right, because this GPU uses the latest version of PowerTune which manages the fan speeds for you in two different modes: "Quiet," and "Uber." In "Quiet" mode, the maximum fan speed is 40%. In "Uber" mode, the maximum fan speed is 55%. No ability to manually set the fans to 100%. That couldn't possibly be problematic. Let's see how the temps are doing at idle: Code: opencl@sagitta:~$ amdconfig --adapter=all --odgt Hm, they're idling kind of high. Ambient temp in the office is about 21 C, and usually we see GPUs in here idling under 25C. I wonder what the clocks are set at? Code: opencl@sagitta:~$ amdconfig --adapter=all --odgc Well that's different... Seems the output has changed a tad. Doesn't show the peak clocks or configurable range for some reason. But it now displays the bus speed and bus lane information. Great to know that all eight are running at 16x, I guess? Not sure why I'd give two shits about that. And seriously, why isn't it showing me the peak clocks and the configurable range? I'm assuming that, like the HD 7990, these cards run at the boost clock of 1000 Mhz out of the box, instead of the rather odd base clock of 727 Mhz. Let's try to manually set the clock at some value in the middle, like 850 Mhz, and see how it does there: Code: opencl@sagitta:~/oclHashcat-1.00$ amdconfig --adapter=all --od-enable --odsc=850,1275 WTF? Oh, right, the R9 line uses Overdrive6 instead of Overdrive5. Goes hand-in-hand with the latest PowerTune. So, we have to set different clocks for different power states and performance levels? I'm not really sure what the valid values are here for these parameters. Can't seem to find anything in the help, or on Google. Fuck it, let's just start messing with it and see what happens: Code: opencl@sagitta:~$ amdconfig --adapter=all --odsc=1000,1250,0,0 So, nothing happens. No confirmation that the clocks were set like we normally would get. Not getting any errors, except for the error we get if we set the performance level greater than 2 (which makes sense.) Since amdconfig no longer shows the peak clock, I have no idea what the clocks are set to... Ok, let's shelve that for now and just check out oclHashcat already, so that we can start having fun again. atom was kind enough to push b49 out this morning, which has R9 support. This card can still redeem itself if it performs well. What the actual fuck. It's taking FOREVER to enqueue the kernels. Like 30-mississippi seconds for each kernel. Four minutes to initialize Hashcat with eight GPUs. I'm not talking about the kernel compile time. This happens even with cached kernels. This is the time it takes to actually enqueue a kernel on each device for execution. WTF. This makes benchmark mode absolutely unusable, because it takes 5 minutes to benchmark each algorithm, and since it suppresses the 'loading kernel' messages, you're left wondering if Hashcat has hung. Once you do get oclHashcat running, performance is lackluster at best. At "stock clocks," it's 4.8% slower than an HD 7970 at 925 Mhz. And I put that in quotes, because thanks to PowerTune, the clocks are all over the place. And even though I (attempted to) set the maximum clock to 1000 Mhz, the clocks aren't going over 855 Mhz. click for larger image One nice thing about this new version of PowerTune, however, is that it automatically downclocks the memory clock for ALU-bound workloads. This is something we used to do manually on the HD 5000 series, then lost the ability to do on the HD 6000 and HD 7000 series. I really like this feature. This is the only positive change I am able to identify so far, and I pray it sticks around. I still don't understand why this isn't going above 855 Mhz under 100% load on an ALU-bound algorithm. The stock boost clock is 1000 Mhz, and we manually set the clock to 1000 Mhz, yet it won't go anywhere near that. And it's not a heat issue, because the temps look really good right now. We're 30 minutes in, and the temps are all below 65C. Ok, something weird just happened. The clocks just all spiked up to 940 Mhz, then immediately dropped down to 525 Mhz. They stayed at 525 Mhz for about 10 seconds, enough for the temps to drop down to around 54C, and then went back up to 848 Mhz. How strange is that?? I can't seem to disable this PowerTune crap either. On the HD 7950, it wasn't too bad, because we could use ADL to set PowerTune to "+20%", whatever that means, and it would behave properly. Using the same method on this card yields fuckall. Same thing with using ADL to manually set the power state or performance level. This card just ignores all requests to let the user manage it. I'm really hoping some of these things are driver issues, even though I'm using the latest beta driver, but I have a feeling these issues are here to stay. Not being able to manually manage the device, the inability to get/set fan speed, disable PowerTune, or set the clocks, is an absolute deal-breaker. And seriously, what the actual fuck is up with it taking 30 full fucking seconds to queue a kernel!? I'll keep playing with this, and I'll keep an eye out to see if others discover any fixes/workarounds for these issues. But until we get this shit sorted out, I'd highly recommend you steer clear of this new R9 line. Stick to the HD 7970 for now rush out and buy one immediately! UPDATE Nov 17 2013 I've confirmed that the management issues are due to this being an Overdrive6 card, as opposed to Overdrive5. The tools we currently use to manage our GPUs still rely on Overdrive5. Using ADL SDK 6.0, I wrote a small program called od6config to manage the GPUs using Overdrive6. It works as expected, so the fan speed and clock rate issues are resolved. The only outstanding issue is the PowerTune crap and kernel load time. Using Overdrive6 I can set the power control threshold to +50 (new PowerTune accepts values from -50 to +50 vs the old version which accepted values from -20 to +20), but Hashcat performance is still erratic. And it still takes 30 seconds to enqueue a kernel. UPDATE Dec 21 2013 Catalyst 13.12 resolves all remaining issues!! RE: Review - AMD Radeon R9 290X - radix - 11-10-2013 Hopefully a new driver will fix it. Guys on windows have had success setting the fan speeds, so I dont see why linux wouldn't be able to. RE: Review - AMD Radeon R9 290X - epixoip - 11-10-2013 It would be awesome if a new driver resolved all of these problems. But, it's AMD, so who knows. It looks to me like they failed to deliver on GCN2, rushed to push out a new GCN-based card, added too many stream processors for the current cooling solution, and then lowered the clocks and implemented aggressive power management in an attempt to keep the card running at acceptable temperatures. That's what it looks like from where I'm sitting. RE: Review - AMD Radeon R9 290X - TheOsiris - 11-10-2013 Sweet rig man. Do you mind sharing the specs for this? Thanks RE: Review - AMD Radeon R9 290X - Szulik - 11-10-2013 i got 4x7970 in rig (on catalyst 13.4) and kernels also loading very long, dont know what on it depends but one gpu loading kernels for 5-30sec RE: Review - AMD Radeon R9 290X - SuB - 11-11-2013 Can you test one (or more) 290x on Windows with latest drivers? There are many reviewers reporting problems and these are related by the temperature controlled GPU frequency and in the latest beta9.2 driver has some fix. RE: Review - AMD Radeon R9 290X - tatgdi - 11-14-2013 I believe his set-up is running on Linux as Windows always had issues addressing more than 6 GPU's. The Catalyst 13.11 Beta 9.2 for Windows makes the Radeon R9 290X a little louder as it adds about 100 RPM to the "Quiet" mode; not sure how much more RPM's are added under Uber mode. The increased noise emitted from the GPU is definitely a tradeoff but will allow it to reach higher clock rates but not the 1000Mhz known for this GPU. We will need to wait for the next Linux driver update and see what updates epixoip post from there. RE: Review - AMD Radeon R9 290X - epixoip - 11-15-2013 windows works just fine with 8 GPUs, don't know what you're talking about regarding issues addressing more than 6 GPUs. i don't know if i'll have time to test the windows driver to see if it behaves better. but i do plan on spending some time with the overdrive6 API, as i have a feeling that is the key here. RE: Review - AMD Radeon R9 290X - tatgdi - 11-17-2013 (11-15-2013, 03:08 AM)epixoip Wrote: windows works just fine with 8 GPUs, don't know what you're talking about regarding issues addressing more than 6 GPUs. Unfortunately I had direct and negative experience with the following configuration with the 6XXX generation series and the 12.X drivers that existed at the time. I have since reverted to Linux and never looked back. I have the system configuration well documented and can share it with you if interested. Have you yourself ever attempted to configure x8 individual single core/asic gpu's on Windows 7 x64? If you can advise me of what generation of ATI GPU's, chassis model and driver set that you were successful with interacting with gpu's within Windows it would be nice to know incase I ever consider the Windows route again. Also see posting here: even the newer Tyan series is exhibiting the same detection/# of usable devices within Windows 7 environment. http://hashcat.net/forum/thread-2776.html RE: Review - AMD Radeon R9 290X - Atlantis - 11-17-2013 What motherboard is it? |