This is no different with our driver yet. We will hook into ACPI correctly soon, when we get the time to do this.
Originally Posted by butdie
Switching VTs reinitialises all of modesetting, and gives you a correct mode. Lid close events shuts down many things, and the lid open event than reenables everything like the bios thinks everything is being used, but this was of course altered by avivo or our radeonhd driver. Once we capture these events, this problem will be handled by the X server and "It Will Just Work" (famous last words).
Processing with the GPU, speculation & questions.
What are the chances of the specks enabling us to use the GPU for more general purpose processing? I frequently backup and compress whole harddrives of data, or transcode MPEG2 video captured from my PVR-150 to Xvid, (soon H.264) is it going to be possible to use the GPU for some/which appropriate tasks?
The Folding@Home people only support R500 series GPUs because "The X1K boards were the first to support 32-bit precision and branching/looping on the ATI/AMD side of the world" and they strongly recommend the R580 / X1900 series, as it has 48 pixel shaders, presumably the same will be true of any future GPGPU efforts? What about R600 chips with their Unified Shaders?
What are the chances of H264 playback assistance, or a more general video decompression framework? What about on older (R300) hardware? Presumably this wouldn't require branching/looping and may well enable thousands of older PC's to perform as HD MythTV frontends.
I realise these questions are way ahead of them selves, and there's a LOT of work to do before we get to this point, but I'm just very excited at the prospect.
Thank you to all the developers for your effort on behalf of the FOSS community
I just found www.gpgpu.org and their not mentioning this on the forums there, I guess specifications aren't going to make a big difference to the world of General-Purpose computation on Graphics Processing Units as they already have open APIs to use, though with closed compilers.
I wondered if we might get an open gpgpu framework and compiler, but I suspect it depends on how detailed the rest of the specks are and possibly how capable intels upcoming Larrabee GPUs are as to weather or not the results will be worth someones effort.
I was actually talking to an AMD representative recently, they mentioned this exact functionality in future tools they plan to release.
Originally Posted by stunted
He mentioned how they want to release tools to allow developers to better harness the GPU's computing power.
That's very exciting, I wonder weather they'll be open source or propriety.
Originally Posted by koolmanoncampus
After posting I did some more reading round the gpgpu.org forums and found this thread
which raises some very interesting questions about the reliability and error rates on GPUs. I don't think for the moment I'd use the GPU for anything like compressing harddrive images, of course a few errors in a video compression probably won't mater but when the integrity of the data is more important than the speed of compression I'll stick with my CPUs and ECC registered RAM.
I wouldn't know about the license state of such a tool. Hopefully it's along the lines of a gcc toolchain.
Originally Posted by stunted