Archives Discussions

[Methylene]

Why is this a question? It should be a priority...

Personally, I would die to have a couple of 4870X2's to play with...  Why is this not a priority?

Think about the fundamental nature of science... It pushes boundaries whenever they are set...  Right now the boundary is in the TFLOPS and that might seem ridiculous, but the difference between 2.5-10 TFLOPS and 1.25 - 5 TFLOPS is quite extreme in terms of application.  And moreover, because of the nature of your hardware's double precision support, it would provide substantially more power availability for those of us who would just love to see every tiny little thing in our work.

My own personal interests are in large scale simulations.  Rendering of procedural planets, and physics intensive mesh modification.  Such a simulator could be extended to suit the needs of many scientific communities.  Whether double precision is necessary depends on the application.  However the need for as much power as I can stuff in is there.

Especially in a sitation where say, NASA or any astronomy organization wants to put some data into a machine and produce a full scale precise simulation of the conditions and terrain on the planet.  One would need to run many parallel calculations in order to create noise algorithms capable of simulating specific terrain based on the known scientific data.  The processing power required would be enormous, so it would need every bit it could get.

If the cards are wired together in such a way that they are designed to function as one massive array... Why in the world would one want to start dividing that array?

Why can't every crossfire device expose its functionality using a single command queue?

What I would like to see is the ability to designate that a crossfire chain will be used as one CAL device.  A setup that I would find very enticing would be to have 3 4870X2s in crossfire as one singular CAL device, and running along side it a 4870X2 used as a rendering device.

Don't sell us short here...  Besides wouldn't the company have more to gain if I were to buy 4870X2's and not just 4870's?

If the idea is massively parallel processing... Well then why sell out the most massive.

[esanya]

Hi!

Will/is the RV730 (46xx card) chip supported?

Thanks,

Regards,

Sandor

[shormanm]

I also would love to get an answer to the question in the original post.

If the card is recognized as one device then: Does CAL recognize all of the 1600 stream units or does it recognized only 800? Does it use the whole 2GB or just 1GB?

Is using two 4870x2 cards possible or not?

I do not want to make such an investment and be disappointed.

[Methylene]

To recap....  udeepta@amd said,

"To be able to use two GPUs with the Stream SDK, we need to disable crossfire. But the 4870X2 is a specially wired card, which is why Catalyst does not allow disabling of crossfire. If there are two 4870X2s in a system, Catalyst should show the Crossfire option for those two cards."

I don't quite understand what this means.  It seems like as the 4870X2 is 2 R770s wired together with a special kind of crossfire bridge... That you cannot use them because they cannot be taken out of crossfire...

But the way it is said, it seems like it should be detect 1 RV770 as a singular CAL device.  So I'm not too sure what is meant..

I stand by my point though...  You should be able to set chains, have as many cards as you want as one transparent device.  Maybe 1 4870X2 would be used for a terrain generating server, and another for a physics server.  I'd like to also make the point that there are MANY reasons why this SDK is useful to people in the gaming industry.  Maybe not in the mainstream yet, but for those of us trying to set the standards for tomorrow it is a vital component.  Well of course unless I just became an nvidia customer.

But I want to stand by AMD and in order to do so, I think we need to stop selling out here.  I understand how competitive the industry is, I understand how important confidentiality is inside it.  Yet, you're saying your biggest sources of capital are workstations, and windows users.

With the OSS you're hoping to further appease the workstation customers, but by appealing to the open source community, you've attracted the attention of every last linux hobbyist out there.

There are tons of people out there, who did not do our homework enough I guess.  We figured with the OSS and all AMD would be the best choice, and I still have faith in you guys, but the difference between the open community and the closed community, is mainly that the closed community doesn't want anything to do with how their computer works, they just want it to work.  The open community wants to know how it's working, that it's working well, and how they can feedback on how it isn't working, or how it should work, so as to improve their experience.

I've been posting on these forums a lot, and I've found them to be very very devoid of AMD presence.  I see 1 - 3 posts a week tops from AMD, and more often or not they are just simple reminders of what you do and don't support, and ways to conform to your supported setup.

It's just not gonna work...  Why not access the vast stores of brainpower that would love to help drive the leading edge.  The OSS is a good start, but let the closed community be naive of the open community's developments... Let them gain the fruits of our labor together to make everything work better.  Lets abstract away the differences between these systems... That's what the community is best at anyway!

We like choices, we like control.  We want to help too!  The radeonhd driver will be a great start, one good question is, will they be able to create their own support for CAL based on the documentation you are releasing?

Furthermore, I know that Brook can be run on a directx or opengl backend, thus enabling it to work on many gpu platforms, however, does Brook+ or will it even have the ability to do so?  It would be nice to be able to easily implement my work done on any setup, as that is the main barrier for my research to become a part of the mainstream for gaming.

To get back to the main point though, it would be very preferrable to be able to designate the gpus I want to be used as a singular CAL device.  As far as it seems, this goes against the fundamental implementation of CAL in general, however I really think that is a mistake.

If the system were to allow a transparent interface with multiple cards, and insure the correct data is loaded to the card which will be making the calculation on it, it would allow for very large increases in power, say having 2 4870X2s on 2 PCIe 16x slots

Before jumping to state that it isn't supported, or that it is the dreams of a customer in a customer base AMD apparently doesn't care about...  Consider that it might just be the right way to do things?  That one should be able to use as many cards as one wants as one array of processors.  That's the whole damn point I would think.

[udeepta]

Methylene, thanks for your input -- I will pass on your comments to the appropriate teams.

[ryta1203]

Originally posted by: Methylene

To recap.... udeepta@amd said,




"To be able to use two GPUs with the Stream SDK, we need to disable crossfire. But the 4870X2 is a specially wired card, which is why Catalyst does not allow disabling of crossfire. If there are two 4870X2s in a system, Catalyst should show the Crossfire option for those two cards."




I don't quite understand what this means. It seems like as the 4870X2 is 2 R770s wired together with a special kind of crossfire bridge... That you cannot use them because they cannot be taken out of crossfire...




But the way it is said, it seems like it should be detect 1 RV770 as a singular CAL device. So I'm not too sure what is meant..





I stand by my point though... You should be able to set chains, have as many cards as you want as one transparent device. Maybe 1 4870X2 would be used for a terrain generating server, and another for a physics server. I'd like to also make the point that there are MANY reasons why this SDK is useful to people in the gaming industry. Maybe not in the mainstream yet, but for those of us trying to set the standards for tomorrow it is a vital component. Well of course unless I just became an nvidia customer.




But I want to stand by AMD and in order to do so, I think we need to stop selling out here. I understand how competitive the industry is, I understand how important confidentiality is inside it. Yet, you're saying your biggest sources of capital are workstations, and windows users.




With the OSS you're hoping to further appease the workstation customers, but by appealing to the open source community, you've attracted the attention of every last linux hobbyist out there.




There are tons of people out there, who did not do our homework enough I guess. We figured with the OSS and all AMD would be the best choice, and I still have faith in you guys, but the difference between the open community and the closed community, is mainly that the closed community doesn't want anything to do with how their computer works, they just want it to work. The open community wants to know how it's working, that it's working well, and how they can feedback on how it isn't working, or how it should work, so as to improve their experience.




I've been posting on these forums a lot, and I've found them to be very very devoid of AMD presence. I see 1 - 3 posts a week tops from AMD, and more often or not they are just simple reminders of what you do and don't support, and ways to conform to your supported setup.




It's just not gonna work... Why not access the vast stores of brainpower that would love to help drive the leading edge. The OSS is a good start, but let the closed community be naive of the open community's developments... Let them gain the fruits of our labor together to make everything work better. Lets abstract away the differences between these systems... That's what the community is best at anyway!




We like choices, we like control. We want to help too! The radeonhd driver will be a great start, one good question is, will they be able to create their own support for CAL based on the documentation you are releasing?




Furthermore, I know that Brook can be run on a directx or opengl backend, thus enabling it to work on many gpu platforms, however, does Brook+ or will it even have the ability to do so? It would be nice to be able to easily implement my work done on any setup, as that is the main barrier for my research to become a part of the mainstream for gaming.




To get back to the main point though, it would be very preferrable to be able to designate the gpus I want to be used as a singular CAL device. As far as it seems, this goes against the fundamental implementation of CAL in general, however I really think that is a mistake.




If the system were to allow a transparent interface with multiple cards, and insure the correct data is loaded to the card which will be making the calculation on it, it would allow for very large increases in power, say having 2 4870X2s on 2 PCIe 16x slots




Before jumping to state that it isn't supported, or that it is the dreams of a customer in a customer base AMD apparently doesn't care about... Consider that it might just be the right way to do things? That one should be able to use as many cards as one wants as one array of processors. That's the whole damn point I would think.

You make some REALLY GOOD points here Methylene, particularly about the lack of support from AMD in regards to this SDK.

Other than the serious limitations that this SDK has, the big one that CAN be resolved remains unresolved: the documentation. It's very, very, very, very, very, very bad. AMD doesn't seem interested in correcting this and I'm not sure why.

In short, it just appears to me that for AMD this SDK is some kind of "side" project that may or may not work out for them (so far, it looks like it's not going to work out when comparing it to other GPGPU options, aka CUDA/Rapidmind).

[shormanm]

I am still waiting for a response. Is using two 4870x2 cards possible?

[MicahVillmow]

Esanya,
The HD46XX series chip is not currently supported but support will be added in a future release.

[MicahVillmow]

Methylene,
I was given the suggestion that you should uninstall all CAL/Catalyst components and do a clean reinstall. This fixed the issue with another developer, so it might be worth a try.