Forum > GPU crunching

GTX 460 superclocked

<< < (21/23) > >>

Josef W. Segur:

--- Quote from: perryjay on 24 Aug 2010, 07:28:21 pm ---You are using Fred's (Efmer) 2.0 rescheduler aren't you? If you are, just look along the top, the expert tab is the last one on the right.



--- Quote --- i plead guilty as charged, i have a long history of not reading the instructions.
--- End quote ---

 I read them it's just that they might as well be in Greek most of the time. I need a lot of hand holding on these things.   ;D
--- End quote ---


--- Quote from: TouchuvGrey on 24 Aug 2010, 07:44:57 pm ---     It sounds like i need to be using that rescheduler, where do i get it and how and where do i install it ?
A lot of this is Greek to me too, but what little i can get from it is a liitle that i did not know before.
--- End quote ---

The download and instructions are  at http://www.efmer.eu/forum_tt/index.php?topic=428.0. Installation is just a matter of taking the 64 bit version of the executable out of the zip file and putting it someplace convenient. If you have BOINC installed where it chooses by default the program should have no difficulty finding what it needs to work with.

The instructions on that linked page say it will reschedule both VLAR and VHAR to CPU unless you uncheck the "Always move VHAR's to CPU" box, I definitely recommend doing so to keep VHARs on GPU. The only VLARs you might have are some older unmarked ones which have been reissued, x32f is better at doing those than stock 6.10 but probably leaving the "Always move VLAR's to CPU" checked is what you'll want.
                                                                                    Joe

Jason G:

--- Quote from: Josef W. Segur on 24 Aug 2010, 11:58:14 pm ---Agreed, anyone who read and remembered the 19th reply in the first thread you mentioned should not have gotten into difficulties. The second thread is in the section of this site closed to all except developers and alpha testers, so TouchuvGrey will not have seen that. In retrospect, your proactive approach suggested there was a very good idea and I hereby declare you not a part of the "we" who screwed up. And of course your warnings on the main project, etc. were very helpful. So much so that I for one didn't realize until quite recently that the smoldering embers were threatening to turn into a full blown fire.

Basically, the difficulty is we developers and many others here have a very technical orientation. What is obvious to us is not necessarily so for our users, and we failed to communicate effectively across that gap. Even a clear statement on the front page and in the description of the 0.36 downloads that V12 isn't Fermi compatible would not have completely prevented the developing problem, many are buying Fermi cards as an upgrade and no reinstall seems necessary in such cases. I'd be more comfortable if we had at least tried that kind of warning, though.
                                                                                      Joe

--- End quote ---

It's been a difficult situation.  I for one didn't realise the potential these cards have fully until I installed one, despite being optimistic from the white papers etc.  Only recent directX 11 performance analyses & reviews of these brand new mainstream cards hints that uptake is likely to be huge.   One thing to keep in mind through all this, while looking back, is that not all the knowledge to put the pieces together was publicly available knowledge, and we've yet to see the full changes  to the stock codebase.  That's marketing controls by nVidia, and continues to mean we have to chase our own tails to work stuff out.  It's always unclear with new hardware whether problems lie with the application build, tools & SDK or drivers, or even the hardware.  With the Cuda 3.1 documentation unreleased at the time, there was nothing to suggest the existing applications shouldn't work, except that they didn't, and the stock modifications yet to be seen, along with x32f, contain fixes in Cuda 3.0 code that were not in that documentation, and only vaguely described in Cuda 3.1

I doubt that any additional written warnings would have been effective, over Richard's advice & instructions, & the installer having been marked, as it was, [Don't use this for Fermi] soon after the problem was understood.  I had to bail up several 'honorary testers' over the past couple of months & feed them working applications to minimise fallout & clarify the situation even for myself, and there remain deadfalls for other developers still they may not know about.

Well I promised plenty of Growing Pains  :D

Frizz:

--- Quote from: Josef W. Segur on 24 Aug 2010, 11:58:14 pm ---... many are buying Fermi cards as an upgrade and no reinstall seems necessary in such cases. ...

--- End quote ---

How about some kind of GPU detection like in Folding@Home - so the client runs only supported hardware. Plus a force flag that the user has to set explicitly (e.g. in app_info.xml) to make it run anyway. Like that "-forcegpu ati_r700" people had to set until recently to make their ATI HD5xxx cards work.

Since you already print out stuff like "Device 1: GeForce GTX 460, 1023 MiB, regsPerBlock 32768" I guess you already have some sort of GPU detection code in place  ;)

To late now ... but maybe prevent the same thing from happening when Fermi2.0 comes around.

Jason G:

--- Quote from: Frizz23 on 25 Aug 2010, 04:42:09 am ---Since you already print out stuff like "Device 1: GeForce GTX 460, 1023 MiB, regsPerBlock 32768" I guess you already have some kind of GPU detection code in place  ;)

--- End quote ---
  That one runs on all the nVidia GPUs  ;) and yes, when the internal dispatch mechanisms in the app, runtime and driver use the right kernels for the right device, as nVidia intended, appropriate codepaths from multiple are chosen & executed.  Unfortunately that mechanism didn't exist prior to Cuda 3.0, so older (Pre Cuda 3.0)builds need to be deprecated. 

nVidia builds 'supposedly' now contain 'forward compatible' PTX code, so Fermi 2 'shouldn't' be a problem.  That however requires a crystal ball I don't have to verify, and wouldn't feel comfortable making a build deliberately error out on something it may have worked fine on.

Fredericx51:
Thanks Joe and Jason for your clear explanation, about CUDA-FERMI (460). Since I'll expect my 470 any
day now, it would be nice to use the right application.

And will it be possible to use a 9800GTX+ and a GTX470, driven by a QX9650, a bit above 'stock' and
low memory latency.(5-5-5-14--1T) @ ~400MHz (FSB=1340MHz; FSB:DRAM=5:6)
O.S. is WIN XP64, BOINC 6.10.58.
Or is this combi making a good test-case, in FERMI testing, already have a SETI Bêta account and have crunched a few hundred AP tasks with rev.434, also rev.422; 393; 280 , on an Q6600+HD5770+4850, host. (WIN XP x86 Pro.; BOINC 6.10.56, all using optimized app's.)

I follow the forum conversation closely, but need some guide to pick the 'right app', for a 470 GPU.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version