If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Newer AMD Radeon GPUs Have Had A Tough Time With Linux 3.15

05-13-2014, 12:00 PM

Phoronix: Newer AMD Radeon GPUs Have Had A Tough Time With Linux 3.15

Besides AMD's R9 290 "Hawaii" open-source support being broken and still not working right even after the hardware has been available to consumers for a half-year, with the Linux 3.15 kernel there's also problems right now for those with newer AMD Radeon GPUs...

I see hangs with kernel 3.15 and SI under memory pressure, e.g. if
>>>>> I boot
>>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high
>>>>> settings.
>>>>> I haven't had a chance to bisect it yet, but it might be a similar
>>>>> problem.

Nah, yes for me too... i tried that Marek's memory pressured patches even before rc1 and that seems like does not work bug free so i tried that nearly month ago and got a hang . I tried FORCED game actually to test that new feature, game allocate more then 512MB on beauty settings and i limited it to that to see what will happens and got a hang . Great thing i can force amount of ram used as vram on AM1, so i can continue playing without a hang .

As for Xonotic i dont see much of the slowness maybe let say around -2% here in 3.15 vs 3.14 And i think i dont see anything from those PTE patches . all that seems like more pointed for dedicated / powerfull cards .

Comment

Comment

My R7 260X doesn't even boot (Linux 3.13/3.14, Ubuntu 14.04 LTS) into the system, no matter if dpm is on or not. It only works with nomodeset (software rendering) and installing Catalyst afterwards. I have a feeling this will be fixed with the new firmware that had been pushed few weeks ago, but I haven't had the chance to try yet

Comment

... And this is one thing that'll be more likely be caught if AMD shares drm between catalyst and radeon.

Given that even a proprietary driver runs over the Linux kernel and neutralizes any "protected" audio and video paths, I'm surprised Hollywood does not require carefully removing all DRM code or code that could be used to reverse-engineer DRM from AMD and Nvidia closed drivers capable of running with the "untrusted" Linux kernel.

No computer can be simultaniously trusted by two parties who are in an adversarial relationship. It can be trusted by one or by none. Since users and kernel hackers control the Linux kernel, that means Hollywood does not control it and it can be (and SHOULD be) used as an attack vector against their DRM. Think: if the Nvidia blob is essentially the same code in Windows and Linux, an attack against Blu-Ray or streaming DRM written on a Linux box using Wine to trick the upstream provider could then be ported to Windows to allow all end consumers to copy their proprietary 5 channel sound without just cutting open the speaker cabinets to add resistors and mic jacks-and all their "encrypted" video footage.

Would I use a kernel written by the police to decrypt and mount my encrypted drives full of raw protest video? No fucking way!