"Ask ATI" dev thread

[wfeltmate]

I would suggest waiting for OpenCL. CUDA is fairly similar, but it will be (for the most part) proprietary to nVidia parts, whereas OpenCL looks to be what will be the industry standard and much more versatile.

[leidola]

Hi!

> I would suggest waiting for OpenCL.
Ultimately I'll switch to OpenCL, but the question is when it will be usable. I guess it will still take half a year (which is too long to wait), but I hope ATi is quicker. That's why I pose this question ;-)

[Michael]

It looks like AMD is getting ready to finally answer these questions... This thread will be locked shortly, so if you have any last minute, relevant questions, ask them now, The answers should be out in April.

[Vighy]

It looks like AMD is getting ready to finally answer these questions... This thread will be locked shortly, so if you have any last minute, relevant questions, ask them now, The answers should be out in April.

ok, so, 2 questions:

one on the fglrx side: (i'm sure an answer has already be given, but i forgot it)
- Is fglrx going to implement KMS? if not, why not?

two on the documentation release plan:
- how is Power Management documentation going? how is the plan to provide it to the public?
- are you thinking about re releasing the r200 docs?

thanks

[Vighy]

Dear ATi guys, why did you put a fetch restriction on amd stream sdk!?!?!?
I don't absolutely want to register to you website, just to be able to update my amd-stream-sdk ebuilds!
It's nice to see you ported some new tools to linux, but putting a fetch restriction just keeps interested people away!

that's not the right way to go!!!

Michael, what about writing an article about this horrible decision?? thanks in advance.

[leidola]

Hi!

I read in this forum:

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

and now I've a few more questions:

1. What cards will support OpenCL?

2. What will happen to brook+/cal?

3. How will OpenCL be implemented / will it be based uppon LLVM?

Thanks a lot,
leidla

[bridgman]

I think that's just a consequence of moving from ATI to AMD web site tools, but I can ask about it.

Is there an actual fetch restriction (ie even when you register you can't get the tools for some other reason) or is it just that you don't want to register ?

[Vighy]

I think that's just a consequence of moving from ATI to AMD web site tools, but I can ask about it.

Is there an actual fetch restriction (ie even when you register you can't get the tools for some other reason) or is it just that you don't want to register ?

I don't want to register because, an ebuild cannot login in a web from. (and if it can, it should not! )

I made a gentoo ebuild for amd stream sdk 1.3 beta, but now it's not usable any more since it requires a login to download the sources.

the funny thing is that the .tar.gzip files changed name from amdstream to atistream and not the contrary

[bridgman]

OK, thanks; I'll pass that on.

[Mr_Ed]

Sounds like the blur is being done in software, which would be very slow. If it's a GL 2.0 function being used in blur that would make sense; the open drivers should pick up GL 2.0 support once Gallium3D is up and running (Gallium3D was integrated into mesa master recently, which is *great* news).

For the other apps it also sounds like they are taking SW fallbacks; there's a way to disable that but I don't remember the details.

I need to talk to the Google folks; Google is such a big advocate of open source but it seems like they only test their apps on binary drivers, not open source

I'm not sure what the latest problem with Google Earth is; will ask around.



Is that a flash video or something ? I would expect video playback to be faster on the open drivers than on fglrx these days; this should be fixable today.

Just for the record: setting the kernel parameter "nomodeset" has solved a number of issues for me:

Google-Earth doesn't work with the open source driver. => solved!

When DPMS mode is enabled and the screen goes to sleep it will not wake up from it anymore. => opengl screensaver issue with kms enabled => solved!

Pretty much everything else I do with this driver is al least 50% slower then with the fglrx driver. => solved!

-----

But the compiz alpha blur thing still isn't working as aspected,

But without the *blur* effects it is much more useable now. Xvideo plays fine now (also windowed) and everything is a lot more "snappier".

Also, I read on the fedoraproject wiki that the radeon open source driver will support kms and dri2 in the upcoming Fedora 11 release for the older r100, r200 and r300 cards.

So, it seems there still is some future for my *old* hardware here.

Regards,

Eddie.