The drivers are, but not the firmware running on the GPU (i think it's called Video BIOS). I'm not sure if a completely free GPU exists. But this is not something that RISCV is concerned with.
There are actually RISC-V extensions designed for numerical computation, though I don't recall if you could actually do a shader core or something like that based on RISC-V.
At any rate, I hadn't heard about anyone trying to make a completely open GPU. That would be cool though.
"On-GPU firmware is not that interesting or concerning, you can consider it part of the hardware. "
It depends on how it can communicate with the external world. If it only eats numbers and draws pixels, then no problems, but if its driver nature (ie, running at higher privileges than anything including root/administrator) allows it to create a covert channel with other hardware (say a network chip) and send vital information to the outside world, then it becomes a huge potential vulnerability.
In open source systems, CPU/GPU/system chipsets firmware and closed device drivers are the places where malware can hide unnoticed for ages, and incidentally the one where it can do the most damage due to the aforementioned privileges, therefore those should be the first parts of a system in which we should demand for total openness.
A simple program with no access to files (therefore considered safe) reading the CPU load and populating a remote graph with numbers can become an effective spying tool if paired with another seemingly innocuous program which has no network access (considered safe as well) but reads files and busy loads one CPU core with values resulting from some encoding of the data it reads. They're 100% safe by themselves, but once paired (say because they're written by the same entity, or different entities obeying to the same government/s) they can exfiltrate information pretty easily. Back on the firmware topic, we can't know if there any seemingly unrelated device drivers talking each other unbeknownst of the system administrator, but should they do, that would be the most dangerous backdooring toolkit ever conceived. Until they stay closed, there's no way to know if they do other things.
> On-GPU firmware is not that interesting or concerning
So people don't like it if kernel drivers are closed source, but if all the functionality is moved to firmware and the open kernel driver just pokes the closed firmware that does all the work it's fine? What? How does that logic work?
Why is it neither interesting nor concerning? From a security perspective it would seem to be both-- hostile firmware could at the least read secrets from your screen, and I'd be shocked if it couldn't convince the corresponding kernel driver to misbehave in interesting ways. Not knowing what is actually in the blob, you have to assume it is at least potentially that malicious.
Correct me if I'm wrong (and I really hope I am), but it doesn't appear to be possible to use "pro" features like OpenCL with the open source AMD drivers, at least not with my 2400G APU. The last two times I tried, I had to install some blob that failed part-way through the installation and rendered my system unbootable.
