Originally posted by bridgman
View Post
Announcement
Collapse
No announcement yet.
Radeon's ROCm OpenCL Runtime Finally Open-Sourced
Collapse
X
-
Originally posted by smitty3268 View Post
The thing is, dungeon doesn't care about it. He uses the proprietary drivers anyway. This whole thing was just him trying to start a flamewar for whatever reason. I guess no good news can go without someone trying to shit all over it.
1. someone posted a link...
2. so, i read it...
3. spotted something in my POV incorrect...
4. sort of false advertising so i reported it
https://www.phoronix.com/forums/foru...424#post951424
And then someone else comment on that, without knowing maybe or reading anything from GNU/FSF sites at all to at least learn a bit what is their stance on this...
With that in mine head Free/Libre is nowhere Yes, but more like Free/Libre No(blb fw req)Last edited by dungeon; 15 May 2017, 05:42 AM.
Comment
-
If the hardware exposes an API (register level), then whatever is required to enable that API is part of the hardware, especially because it's the 21st Century and a lot of hardware is actually a fairly general-purpose CPU/DSP running firmware and exposing a function to the rest of the system. On AMD's GPUs many of the hardware blocks are 64-bit F32 CPUs (although I don't know much further than this).
If money is saved by loading this firmware (or collection of firmwares) onto these GPU functional units at boot time, then great. It also means they can get updated should a bug be exposed.
Without the firmware, you simply have a set on non-functional CPUs/DSPs that aren't doing anything, which in turn means the dedicated GPU resources don't get data, and nothing happens. Hence the firmware is clearly part of the hardware, and not the driver.
I would hazard a guess that on the Scorpio games console, these on-GPU CPUs have had their firmware tweaked to optimise for DX12 offloading.
I guess AMD could synthesise each of these CPU/DSP-enabled features as dedicated silicon, but it's not worth it (at least to date).
- Likes 1
Comment
-
Originally posted by nanonyme View PostDoes this microcode contain card-specific quirks? If so, who's going to be adding those for cards no longer sold or under warranty? Or is the general idea that it's easier to put the quirks inside the driver?Test signature
Comment
-
Could we silence these people by saying it's a initialization sequence that must be written to the card and not microcode? So clearly it's not something that has source code, but just a byte string that the card needs to function.
I find it annoying that people whine about microcode, especially when they somehow think it's better, if that doesn't need to be copied to the card by driver code as if that is any different. I'm quite happy that we have the open source drivers even if I need some small blob that runs on the card. It's not like the card sends my display content or VRAM content to some 3rd party when I upload this code there. (How do I know? Well, I don't, but either there would need to be some (well hidden) radio on the card or it would need to send it through PCI-E in which case the motherboard would need to be compromised as well and in that case there are better sources of information than VRAM so GPU blobs are the least of my concerns.)
- Likes 1
Comment
-
-
Echoing my Request For Comments and my question from previous posts, which were probably not seen by the active participants in this forum since the conversation was moving faster than it took for my posts to be approved:
1) Can ROCm OpenCL be made to work with older cards, even back to the Southern Islands family?
2) Is support for OpenCL v2.0+ in the works? 1.2 runtime is... less than ideal nowadays.
- Likes 2
Comment
-
-
Originally posted by dungeon View PostInstead of "Yes" on "Driver status" and under "Free/Libre" it should say "No(firmware required)"
The answer was given to you by someone else right after your post, there was no need to wait 7 pages:
Originally posted by Spazturtle View Post1) Firmware isn't part of the driver.
Originally posted by Serafean View Post1) Driver is useless without firmware, so it effectively is.
Originally posted by Spazturtle View Post1) Firmware isn't part of the driver.Originally posted by dungeon View PostIf it is not, why you use it? Why not remove it?
Originally posted by dungeon View PostStating something as friendly to Free/Libre, but everybody knows their stance on blob matters is already is total disrespect
Originally posted by Spazturtle View Post2) Would you rather the firmware was on a read-only chip on the GPU?Originally posted by Serafean View Post2) yes. At that point it becomes hardware.
That comment I'm writing right now is 100% useless, others answered very well, and others answered very well to other flaws.
Originally posted by Serafean View Post2) yes. At that point it becomes hardware.Originally posted by wizard69 View PostPersonally id rather see blob free myself, however your arguements make no sense to me.
Well, so many people answered, there was no need for me to answer. All this wall of text I'm writing up is just about telling things other told.
I just add a last random answer to some random statement by some random guy:
Originally posted by starshipeleven View PostUnknown, but according to Stallman or other Free/Libre proponents it's like that. Suff in ROMs is ok, stuff loaded at runtime is not. Even if it is the same.
So, for the end:
Originally posted by dungeon View PostColumn shoud say there "No (blob firmware required)" instead of "Yes" Even just that would be much more Free/Libre friendly, than stating something incorrectly
It's possible to modify the matrix this way:
Code:driver status: free firmware status: non free
Code:driver status: free (notice: non-free firmware needed
Last edited by illwieckz; 16 May 2017, 12:33 PM.
- Likes 1
Comment
Comment