Modified SETI MB CUDA + opt AP package for full GPU utilization

[Devaster]

Raistmer, put your mod version of cuda sources to the our svn please ....

[Jason G]

Suggestion, if you want to do that, add it to the SaHv6 Repsoitory as a new folder next to Opt and Stock:

by checking out:
svn://sinbadsvn.dyndns.org/SaH_v6b/
then creating & adding a new folder like 'Stock_Cuda', or some such, with the contents.

Probably wise to commit unmodified stock first, and then the small updates you have so the changes are logged for posterity.

Jason

[Raistmer]

Did you put version I recived by E-mail before Berkeley's SVN was available in sinbad's rep already or there is no CUDA MB at all ?

[Jason G]

Me? Nope, No Cuda code development here. I have no interest in the stock nvidia cuda code since it crashes my machine, feel free to install the sources in that stock sinbad repository though for mimo's access (& easy logged progress  etc...)., That is a separate machine primarily dedicated for that purpose.

Maybe I will look and see if I can see anything obvious in the code if you put it there.  Sorry, this machine I work on is fairly 'mission critical' for other work at the moment, so only relatively trusted builds (Like ours) can cut the mustard.  It runs MatLab, Ansys, Inventor and Altium Designer which are all demanding and use DirectX, so "fubarred" device drivers are not an option until certain projects are completed, so I simply haven't risked playing.

Jason

[Raistmer]

Ok, don't think it's sources that crashed you PC, hope it's only binaries built from that sources
Sources pretty harmless
Will put what I have into CUDA branch.

[Jason G]

LoL, Indeed, but the temptation with sources on the machine is to (try to) fix them, run them, then experience the nightmare. As mentioned before, I resist and leave that barrel of fun to you guys (for now   )

[Raistmer]

Oops, and what is it ?
svn://sinbadsvn.dyndns.org/SaH_v6b/Cuda_app/seti_boinc
is it CUDA app indeed ?

With separate BOINC...
Maybe it's that sources I recived from Eric initially ?

[Jason G]

I have no idea!  ... Checking logs 

[Edit: Ahh!, Yes I put 6.05 there ... Please update this one  ]

[Raistmer]

I have no idea!  ... Checking logs 

LoL
"
Revision: 58
Author: jason
Date: 15:19:28, 13 декабря 2008 г.
Message:
Initial Berkeley Cuda app sources v6.05
----
"

[Raistmer]

Ok, I have modded rev 380 in some folder on HDD - wanna share it with this CUDA rep. Please, suggest how to change repositories most effective way w/o recreating another folder (wanna have CUDA Berkeley/sinbads together)

[Jason G]

Okay:

  - Checkout old cuda_app folder (fresh checkout)
  - go into folder, select all non-hidden, and rightclick-->TortoiseSVN-->Delete  (Not windows delete) ... They will disappear, but properly interacting with SVN.
  - Copy the replacement  files in using RightClick+Drag, On Release select "Copy & Add Files to This SVN WC" (or similar it says anyway)
  - Commit with nice friendly log describing exactly all the bugs and how to fix them, and all your girlfriends phone numbers.

Easy enough?

[Raistmer]

Hehe
But it will be 2 separate folder with sources on my own HDD that way?

[Jason G]

Not necessarily when done, we don't need to keep separate trees for that as they are sequential updates to the same project.  As you'd be effectively replacing the repository files with yours, no need to have 2 local copies when done either. You keep the repository version active for working on and archive/delete any other you're not working on.  The only need is for this in the repository.

Stockv6 cuda_app folder log would look like this:
  - First Revision = Berkeley 6.05 unmodified. (Obsolete but there for preservation)
  - Second revisiion = Berkeley 6.06 unmodified (Also obsoleted by your mods, but there if needed)
  - Third revision = Your 6.06

[Of course the revision numbers will be higher that 1,2 & 3, because of mixed in with Stockv6 non-cuda repository.]

So only one progressive Repository is needed but can fall back to any point later if you decide to, and could even create a branches subfolder if you later need two separate builds for some reason, but I can't see any need to do that,  unless you find your mods seriously went in the wrong direction, but even then that is better handled by reverting individual files.  Branching (which would make two separate lines to keep locallly) should only be needed if there are some reasons the builds need to develop in different directions then later hopefully find a way merge.  An example of this is the AK_v8 split off of SSE build because it broke SSE2+ speed.  Hopefully one day these become reintegrated.


 

[Raistmer]

I mean I want to save possibility to update from Berkeley's repository and commit to sinbad's one - is it possible from single workcopy on HDD or not?

[Jason G]

There is one way to make it a bit easier that I'll go into further down, though, the easiest way I've found to accomplish this, like when AstroPulse needed to be updated to version 5 code from 4.35, is to drop the Berkeley files over an already committed working copy.  All changes then show in "Check for Modifications" which you can then do the Ping-Pong merge game on a per file basis, to decide which changes are relevant to your build.

The other way would be to use the SVN 'Externals' feature.  Look up 'external repositories' in the TortoiseSVN help.  Basically it should allow you to grab different subfolders (say one named 'Berkeley') which would sync to Berkeley whenever you do an update, then you can use regular merge tools like 'Two-Tree-merge' to grab the changes you want.

Up to you which approach to use. Just avoid committing until you have it arranged the way you want, but commit before you try merging new code in from Berkeley and you should be alright.  Either way it is still some juggling, though both are effective.  My only aversion to Method #2 is that updates of the repository rely on two servers being operational at the same time.