During the MM BoF at ELC, it seemed to me that one of the things that scared most ARM vendors away from GEM in the first place is that was perceived to be too closely married to the rest of DRM (especially KMS).
I know that some might argue that isn't necessarily true and we can go back and forth on that point, but I think it is still valuable to ask this question:
How feasible is it to break out the GEM portion of DRM (essentially drm_gem.c) and put it into its own subsystem or library component for use by a DRM or a non DRM component. What parts would a non DRM component be missing to use GEM effectively (authentication comes to mind)?
Jordan
On Thu, 21 Apr 2011 11:48:36 -0600 Jordan Crouse jcrouse@codeaurora.org wrote:
During the MM BoF at ELC, it seemed to me that one of the things that scared most ARM vendors away from GEM in the first place is that was perceived to be too closely married to the rest of DRM (especially KMS).
I know that some might argue that isn't necessarily true and we can go back and forth on that point, but I think it is still valuable to ask this question:
How feasible is it to break out the GEM portion of DRM (essentially drm_gem.c) and put it into its own subsystem or library component for use by a DRM or a non DRM component. What parts would a non DRM component be missing to use GEM effectively (authentication comes to mind)?
The non-driver portion of GEM is pretty small, it should be relatively easy to move it around.
On related topic, one issue that comes up in the ARM SoC world is that the display controller (mode setting stuff) might come from the SoC vendor, and the 3d/2d/etc IP from various others. For example, SGX (or mali) is used in a few places, each with different display controllers.
And, at least in our case, the driver for display controller may be present, but sgx kernel module may not. To make things look "normal" to userspace, I've taken the approach of writing a DRM driver that handles the KMS stuff, and has a plug-in API[1] that other drivers, such as sgx, can register their own ioctl's and that sort of thing.. there are a few rough edges to sort out to make more than a single plugin practical, but perhaps with an approach like this the vendor could implement a platform specific DRM driver to handle the mode setting and display bits, while ARM, IMG, etc (IP vendor) could each use a standard plugin interface to write their own drivers to work with the vendor provided display driver.
BR, -R
[1] https://github.com/robclark/kernel-omap4/commit/4ddca26866350c4442aa2b8c5ccd... (although that is just quick/dirty to make it so I could work on the mode-setting parts)
On Thu, Apr 21, 2011 at 12:48 PM, Jordan Crouse jcrouse@codeaurora.org wrote:
During the MM BoF at ELC, it seemed to me that one of the things that scared most ARM vendors away from GEM in the first place is that was perceived to be too closely married to the rest of DRM (especially KMS).
I know that some might argue that isn't necessarily true and we can go back and forth on that point, but I think it is still valuable to ask this question:
How feasible is it to break out the GEM portion of DRM (essentially drm_gem.c) and put it into its own subsystem or library component for use by a DRM or a non DRM component. What parts would a non DRM component be missing to use GEM effectively (authentication comes to mind)?
Jordan
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
And, at least in our case, the driver for display controller may be
present, but sgx kernel module may not. To make things look "normal" to userspace, I've taken the approach of writing a DRM driver that handles the KMS stuff, and has a plug-in API[1] that other drivers, such as sgx, can register their own ioctl's and that sort of thing.. there are a few rough edges to sort out to make more than a single plugin practical, but perhaps with an approach like this the vendor could implement a platform specific DRM driver to handle the mode setting and display bits, while ARM, IMG, etc (IP vendor) could each use a standard plugin interface to write their own drivers to work with the vendor provided display driver.
I remember Dave Airlie proposed something that sounded similar for the upstream DRM, with options for display, graphics and compute, so maybe this is something that could fit upstream fairly easily ?
On Thu, Apr 21, 2011 at 1:14 PM, Bridgman, John John.Bridgman@amd.com wrote:
And, at least in our case, the driver for display controller may be
present, but sgx kernel module may not. To make things look "normal" to userspace, I've taken the approach of writing a DRM driver that handles the KMS stuff, and has a plug-in API[1] that other drivers, such as sgx, can register their own ioctl's and that sort of thing.. there are a few rough edges to sort out to make more than a single plugin practical, but perhaps with an approach like this the vendor could implement a platform specific DRM driver to handle the mode setting and display bits, while ARM, IMG, etc (IP vendor) could each use a standard plugin interface to write their own drivers to work with the vendor provided display driver.
I remember Dave Airlie proposed something that sounded similar for the upstream DRM, with options for display, graphics and compute, so maybe this is something that could fit upstream fairly easily ?
something like this sounds like what we want.. does someone have a link to the proposal handy? I've no desire to re-invent the wheel unnecessarily
BR, -R
I remember Dave Airlie proposed something that sounded similar for the upstream DRM, with options for display, graphics and compute, so maybe this is something that could fit upstream fairly easily ?
something like this sounds like what we want.. does someone have a
link to the proposal handy? I've no desire to re-invent the wheel unnecessarily
I wasn't able to find it, hoping Dave remembers. I think it was from late 2007 or early 2008 but not sure.
It even had diagrams so it deserves to be remembered ;)
On Fri, Apr 22, 2011 at 6:29 AM, Bridgman, John John.Bridgman@amd.com wrote:
I remember Dave Airlie proposed something that sounded similar for the upstream DRM, with options for display, graphics and compute, so maybe this is something that could fit upstream fairly easily ?
something like this sounds like what we want.. does someone have a
link to the proposal handy? I've no desire to re-invent the wheel unnecessarily
I wasn't able to find it, hoping Dave remembers. I think it was from late 2007 or early 2008 but not sure.
It even had diagrams so it deserves to be remembered ;)
My plan was to split the interface across a few device nodes,
Though not so much the functionality, there would a control device node for root only configuration of render nodes, then render nodes would have a subset of the modesetting caps + accel functionality, or just accel functionality for compute.
So its not exactly the same area as this.
I had though about this as well but just as far as saying maybe some sort of loadable accel bit with its own ioctl set might work.
Dave.
On Fri, Apr 22, 2011 at 6:29 AM, Bridgman, John John.Bridgman@amd.com wrote:
I remember Dave Airlie proposed something that sounded similar for the upstream DRM, with options for display, graphics and compute, so maybe this is something that could fit upstream fairly easily ?
something like this sounds like what we want.. does someone have a
link to the proposal handy? I've no desire to re-invent the wheel unnecessarily
I wasn't able to find it, hoping Dave remembers. I think it was from late 2007 or early 2008 but not sure.
It even had diagrams so it deserves to be remembered ;)
My plan was to split the interface across a few device nodes,
Though not so much the functionality, there would a control device node for root only configuration of render nodes, then render nodes would have a subset of the modesetting caps + accel functionality, or just accel functionality for compute.
So its not exactly the same area as this.
At this risk of contributing to design creep, I love this idea. It sounds like it would suit itself well to a design with multiple GPU cores.
Perhaps this is something that can be re-introduced as part of a parallel discussion.
Jordan
On Thursday 21 April 2011 19:48:36 Jordan Crouse wrote:
During the MM BoF at ELC, it seemed to me that one of the things that scared most ARM vendors away from GEM in the first place is that was perceived to be too closely married to the rest of DRM (especially KMS).
Interestingly, my impression at the BoF was that people didn't like GEM and DRM but still wanted to have KMS with their own drivers ;-)
Arnd
On Fri, Apr 22, 2011 at 5:21 AM, Arnd Bergmann arnd@arndb.de wrote:
On Thursday 21 April 2011 19:48:36 Jordan Crouse wrote:
During the MM BoF at ELC, it seemed to me that one of the things that scared most ARM vendors away from GEM in the first place is that was perceived to be too closely married to the rest of DRM (especially KMS).
Interestingly, my impression at the BoF was that people didn't like GEM and DRM but still wanted to have KMS with their own drivers ;-)
The question is why don't these people like DRM? these people are willing to pile binary blobs with fucked up HAL layers in them, or GPL code with wasteful abstractions, and they claim the DRM is too heavyweight?
It wouldn't take more than a day or two's work to make most of the legacy DRM core optional, and split it out into separate modules maybe.
Like the whole legacy buffer management/VM interactions could be split out and drivers that need it could load it.
Dave.
On Thu, Apr 21, 2011 at 5:21 PM, Dave Airlie airlied@gmail.com wrote:
On Fri, Apr 22, 2011 at 5:21 AM, Arnd Bergmann arnd@arndb.de wrote:
On Thursday 21 April 2011 19:48:36 Jordan Crouse wrote:
During the MM BoF at ELC, it seemed to me that one of the things that scared most ARM vendors away from GEM in the first place is that was perceived to be too closely married to the rest of DRM (especially KMS).
Interestingly, my impression at the BoF was that people didn't like GEM and DRM but still wanted to have KMS with their own drivers ;-)
The question is why don't these people like DRM? these people are willing to pile binary blobs with fucked up HAL layers in them, or GPL code with wasteful abstractions, and they claim the DRM is too heavyweight?
I would hazard a guess that it is more an issue of documentation and lack of familiarity with DRM that scares some off..
BR, -R
It wouldn't take more than a day or two's work to make most of the legacy DRM core optional, and split it out into separate modules maybe.
Like the whole legacy buffer management/VM interactions could be split out and drivers that need it could load it.
Dave.
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
On Thu, Apr 21, 2011 at 06:30:17PM -0500, Clark, Rob wrote:
Interestingly, my impression at the BoF was that people didn't like GEM and DRM but still wanted to have KMS with their own drivers ;-)
The question is why don't these people like DRM? these people are willing to pile binary blobs with fucked up HAL layers in them, or GPL code with wasteful abstractions, and they claim the DRM is too heavyweight?
I would hazard a guess that it is more an issue of documentation and lack of familiarity with DRM that scares some off..
It's certainly a reason that two vendors have independently described to me. Once we decide in what direction we want to take this, we should budget time for producing developer documentation so they have one less complaint to offer.
linaro-mm-sig@lists.linaro.org
-
Arnd Bergmann -
Bridgman, John -
Christian Robottom Reis -
Clark, Rob -
Dave Airlie -
jcrouse＠codeaurora.org -
Jesse Barnes -
Jordan Crouse