Recent Features
| |||||||||||||
Nothing has been movedNothing has been movedPosted Nov 1, 2012 23:04 UTC (Thu) by Arker (guest, #14205)In reply to: Nothing has been moved by dlang Parent article: Airlie: raspberry pi drivers are NOT useful
the question is if the stability issues are due to the driver, or due to the driver's interaction with the rest of the kernel. A distinction without a difference. The driver has no purpose and no function other than inside the kernel. If stuff running on the GPU limits itself to reading and writing buffers that are explicitly allocated for it, almost all of the problems mentioned go away, and the remaining 'shim' driver can evolve along with the rest of the kernel. But as long as the stuff running on the GPU is an opaque blob we cannot audit or replace there is absolutely no way we can ever have any confidence that it is limited like that.
(Log in to post comments)
Nothing has been moved Posted Nov 1, 2012 23:47 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
>> the question is if the stability issues are due to the driver, or due to the driver's interaction with the rest of the kernel.
> A distinction without a difference. The driver has no purpose and no function other than inside the kernel.
Actually, in this case it is a very important distinction.
let's put it another way.
Are the bugs in the graphics logic, or in the interaction with the rest of the kernel.
If the bugs are in the graphics logic, then they would remain if they were separated the way the Pi broadcom driver is.
If the bugs are in the interaction with the rest of the kernel, then an API like the Pi has would allow us the best of both worlds, good graphics performance, and clean interaction with the kernel
The driver vendors keep wanting to have a stable API for their interaction with the kernel, and the kernel devs (for good reason) refuse to freeze the kernel internal APIs. But if the API to the device is defined and frozen by the firmware interface, everybody wins (except those people who want to make the graphics hardware do different things)
Yes, the graphics hardware could start scribbling to any part of memory that it wants, but technically, so could any bus-mastering controller card, and there have been very few cases where bus-mastering network or drive interface cards have caused problems from this.
Nothing has been moved Posted Nov 2, 2012 3:32 UTC (Fri) by Arker (guest, #14205) [Link] But if the API to the device is defined and frozen by the firmware interface, everybody wins No, I dont agree. There is no win there for me at all (other than simply not buying it.) The current situation with my ATI card is far preferable. You may call it a win if you get what you want out of it, but you do not get to define it as a win for me. What I want is a system where there is nothing running that I did not put there, nothing that I cannot edit, no code that I cannot audit - that is the whole point to free software. The hardware I pay for should respond to my commands, not anyone elses. Your 'solution' gives me exactly zero of what I want, it's not a compromise, it's a total loss.
Nothing has been moved Posted Nov 2, 2012 7:25 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> No, I dont agree. There is no win there for me at all
you conveniently left off the caveat that covered you
>> (except those people who want to make the graphics hardware do different things)
|
|||||||||||||