User: Password:
|
|
Subscribe / Log in / New account

Nothing has been moved

Nothing has been moved

Posted Nov 1, 2012 6:29 UTC (Thu) by dlang (subscriber, #313)
In reply to: Nothing has been moved by Arker
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.

Personally, I suspect that most of the problems are in the latter category.

The closed driver is having to interact in a multi-threaded environment with other processes manipulating memory, with allocating memory in the same space as the rest of the kernel, and with all the locking that the rest of the kernel expects (and in some cases requires). And the closed driver is trying to do this without being modified from kernel version to kernel version, even though the rules for the kernel are changing (the locking rules in particular, although memory management changes somewhat as well).

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.

In this case, they talked about how part of the difference was the closed drivers supporting a newer version of opengl, with the high level interface this would not vary from driver to driver (unless specific drivers required different versions of the firmware), so I would expect that things would be a lot closer to feature parity between the two modes.

In any case, even with the ATI mode of doing things, if there is bugginess in the firmware, it can cause problems for the overall system


(Log in to post comments)

Nothing has been moved

Posted Nov 1, 2012 23:04 UTC (Thu) by Arker (guest, #14205) [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.

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.

Nothing has been moved

Posted Nov 1, 2012 23:47 UTC (Thu) by dlang (subscriber, #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 (subscriber, #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)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds