cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Methylene
Journeyman III

GPUwiki.com

A new wiki for GPGPU / Shader Pipeline Programming and more!

I just launched this website and finished ironing out the last of the setup.  Please don't expect much from it right now, the major purpose of its existance right now is to try and get people to start chronicling their experiences in a descriptive manner so as to help others.

I'm asking that not only those with experience in using the Stream SDK contribute, but with experience with GPUs in general.  I'm hoping to conglomerate the knowledge of all the GPU programmers out there, and provide the resource I've seen so many requests for.

Once again, due to my limited knowledge on the subject, and my even more limited time, this site has barely been setup.

This is more like my donation back to the community for its help in the past!

I'd very much like to see some contributions from the AMD team.  However, please anyone feel free to contribute, I do not have too much time anymore myself for these things.

Tags (2)
0 Likes
20 Replies
ryta1203
Journeyman III

GPUwiki.com

I think it's important for you to at least have an External Link to these two sites that are already up:

http://en.wikipedia.org/wiki/GPGPU

http://www.gpgpu.org/w/index.php/Main_Page
0 Likes
Methylene
Journeyman III

GPUwiki.com

noted and I'll add both, but remember, it's a wiki, if you feel it's important, add it!

0 Likes
Methylene
Journeyman III

GPUwiki.com

I'd also like to emphasize that due to my inexperience with assembly language, I really need some help especially with AMD IL articles and tutorials.  Also admittedly I've barely touched CAL, although I believe it is well within my comprehension if I were to read over the documentation, but I'd much rather those with more experience contribute.

Even my Brook+ knowledge is somewhat rudimentary!

I've seen and heard of a lot of success with the SDK so far, and I look forward to seeing all of your contributions!

0 Likes
ryta1203
Journeyman III

GPUwiki.com

Originally posted by: Methylene



I've seen and heard of a lot of success with the SDK so far, and I look forward to seeing all of your contributions!



I'm interested to hear these stories. Most of what I have heard is that people who have tried working with this SDK have quit and have temporarily put it on the back burner for now due to several issues: documentation, brook+ lacking fundamental coding aspects, etc...

0 Likes
Methylene
Journeyman III

GPUwiki.com

http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=103149&enterthread=y

Ryta, you seem to hold a grudge against a fledgling program... Lets bear in mind that the SDK is indeed newer than CUDA.

Also, I have been in contact with SDK team members about the bugs I have encountered and there was thorough testing done to insure that the issues will indeed be fixed by the next release.

It would seem to me that the NVIDIA side has a lot more followers, so needless to say it will be for now more successful.  However if everyone that ever tried the BETA SDK found it didn't work in some way shape or form and then abandoned ship and ran to NVIDIA who would test and help bring the bugs to the attention of the staff?

I've found the team to be very interested in the community's input, although sometimes, but not all too often, unable to provide the answers I was looking for.

I'd just like to emphasize the point that a good project can not ever become a good project without a good community.  If you like AMD, and you want them to pull ahead, then it's our responsibility as the consumers to give them input on the problems and help by suggesting solutions that would work for us.

I remember making a comment a while back about the support of 4870x2 devices.  They are now supported with the new driver, and expose 2 CAL devices.  That's progress isn't it?

But who am I to stop you from trolling these forums and making harsh commentary on every glitch along the way.  I'm just an individual that sees my own responsibility in developing a product that I can be satisfied with.  Rather than just expecting a lower-budget company to have the almost inexhaustible test crew that NVIDIA must have to be able to constantly provide products and fix the bugs for their consumer base of people who could give a damn about reporting the bugs they experience and just always sit around with their fingers crossed that it will be fixed for next time.

I just don't think AMD has the financial capability or manpower to find and fix every bug on their own.  That's why things like the Stream SDK are probably exposed to the public early before their official release so as to attract a testing community.

I'm just a little sick and tired of the irresponsible attitude I find in my peers these days.  If you believe something should be a certain way, then you should politely attempt to work with the people required to make it that way.

I have been constantly explaining my experiences and suggesting ways to improve things to AMD, and I have been greeted with compassion on the matter.  It makes it hard to have a grave attitude (as I first did when I came on these forums) when there are people in the company working so damn hard to fix things.

I also see a lot of unreasonable requests and expectations from other areas of the community.  For instance there is a lot of flaming going on about how AMD has not managed to release the last documentation required for the RadeonHD crew to implement 3D acceleration in their driver.  I'd just like to emphasize that NVIDIA has not yet open-sourced one bit of their driver.  So whether it takes a year or a thousand years they're still miles ahead of the competition in terms of an open sourced driver.

I have in the past year become a total open-source convert.  To the point where I feel guilty whenever I consider starting a project that I will not be releasing back to the community, and usually find a way to make some if not all of the project available (IE: modularizing a part that would not necessarily need to be proprietary).  As far as my noise stuff goes that is what I plan on doing (when I get the time to start working on it again!).

At any rate, I just wish I could see more people around that think before they bare grudges, that consider the company's position in a capitalistic society, in a competitive industry where a single secret that gets out the door can mean the end of that company's future.

So buck up and get in the game, you seem to be fairly interested in having AMDs solutions work for you, so how about you shoot an email over to streamcomputing@amd.com and let them know what didn't work, how it went wrong, and what you'd like to see in the future.

EDIT:  I'd also like to see all these instances where people said things weren't working for them and that they'd have to abandon the project... Because AFAIK there aren't many more than yourself.

I read a post you started earlier where jean-claud responded that he didn't see much of a performance increase... His kernel used a float data type...  With all these complaints about the documentation I'm beginning to wonder if the complaintants have even read the documentation.  As the first thing the Brook+ section really gets into is about how the float4 is the most optimum way to use the hardware as it is optimized for 2D texture data (4 floating point numbers).

I wouldn't expect much of an improvement when 1 float is being processed at a time.  This causes 3 processors to idle (as mentioned guess where, the documentation).

As far as real world experience goes.  I worked with libnoise before writing my own kernels based on their code.  Libnoise is pretty quick because it uses a random index into a table of floating point values, thus reducing the number of FLOPs required to acquire the result.  However, I am finding my equations to run very fast, and there is an OBVIOUS increase based on the parallel operation.

For instance, it takes me the **same** amount of time to calculate 1 million noise values as it does to calculate 2 million, because of the fact that obviously 1 million or 2 million both can be done in 1 "pass" (my kernel apparently has a couple passes or so but it does not need to be split into 2 seperate chunks of data because there is room on the card).

The proof is in the pudding.  I've not used CUDA, but I am laying the ground work for another developer to add a CUDA optimized backend to my some-day-to-be open-sourced GPU noise library.  However my main goal will be to make the library available to all regardless of OS or hardware, and OpenCL will be the way to go for me in that light.

Just remember AFAIK CUDA is NOT beta software.  So how can you expect BETA software to work without bugs or hitches as well as NONBETA software would?  And to return to my original point, how can you expect it ever to get there if you spit in the developers faces all the time saying their project sucks and will never be able to compare to the competition?

0 Likes
yakktr
Journeyman III

GPUwiki.com

Methylene

I really appreciate what you are doing  and totally agree with what you have said above. I have no knowledge of Brook, I started with CAL despite the advised way is to learn Brook first. I have only studied the CAL example given in documentation and played on it with different kernels so far.

I gave it a break for various reasons but I will return to work on it in 2 weeks (hopefully) . A strategy I may suggest for beginners like me is to use GSA (GPU Shader Analyser). When you convert BROOK code to IL, even a simple function like an addition results a loooooong kernel code. But when you use GLSL it just gives plain IL code which can be easily followed. I write some simple kernels with loops etc using this method. Next I am planning to work on ode solving possibly with Runge-Kutta method. I would be more than happy to share with community and see others work

Cheers

0 Likes
ryta1203
Journeyman III

GPUwiki.com

Methlyene,

I have no personal investment in the SDK and certainly have no personal grudge against the SDK. I'm not sure why you would ever suggest such a thing. I merely stated facts: that I have left it (and others I know, who don't frequent this board) due to problems, lack of support, lack of documentation, lack of features, etc. There is nothing personal about this.

I simply honestly don't believe that AMD has full support behind Brook+. None of the posters from AMD here seem to know much about Brook+ (Micah is the only one who really posts here anymore and he is self-admittedly a CAL guy). AMD is looking to support OpenCL (from what I have read) so I doubt that Brook+ will be around too much longer. More evidence of this comes from the fact that AMD has outsourced the Brook+ development. I don't wish to code in IL (essentially assembly) due to it's long development times compared to it's performance gains with other GPGPU solutions (aka CUDA).

These are facts, not some personal grudge of which you accuse me. Don't drama it up, it's just an SDK and facts.
0 Likes
ahu
Journeyman III

GPUwiki.com

Originally posted by: Methylene
I remember making a comment a while back about the support of 4870x2 devices.  They are now supported with the new driver, and expose 2 CAL devices.  That's progress isn't it?


Which driver / OS? With the 8.11 driver I see no progress here.

Under Vista, only one CAL device is seen (though there are supposedly register hacks to disable the internal Crossfire, thus enabling two devices).

Under XP and Linux, exposing two devices has been possible before but there have been several issues.

0 Likes
ryta1203
Journeyman III

GPUwiki.com

1. I'm surprised you were even able to get 8.11 working. Most are experiences some kind of atikmdag.sys BSOD error with 8.11. I'm currently using 8.10 because of this major bug.

2. This link: http://www.supercomputingonlin.../article.php?sid=16532 posted by Micah in another thread indicates what I have been saying, that AMD is moving away from Brook+ and toward OpenCL. How much longer will Brook+ be supported? I don't know, but this is probably the major reason why they are not interested in making Brook+ any better and instead are focusing more on CAL.

EDIT: The real question becomes: will you be able to achieve the same performance levels in OpenCL across multiple SDKs (CUDA, Firestream, Cell, Larrabee, etc..)? And how long after the spec is released will implementations be released? I didn't attend SC08 unfortunately.
0 Likes