>
> A simple "plugin" mechanism is provided to allow integration with
> external kernel modules (*cough* PVR), but also to keep the code more
> modular as support is added for various other accelerator blocks that
> exist in various different OMAP variants. (2D accel, video encode/
> decode, etc.)
On Mon, Sep 12, 2011 at 8:21 PM, Rob Clark wrote:
> From: Rob Clark
>
> In the process of adding GEM support for omapdrm driver, I noticed that
> I was adding code for creating/freeing mmap offsets which was virtually
> identical to what was already duplicated in i915 and gma500 drivers.
> And th
>
> I disagree. This depends on the functionality the hardware has, the desired
> userspace and the manpower one has to do it. And of course if you just want fb
> having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have
> just
> an fb driver for devices that can't do more anyway.
>
> Is it? Well, okay, I don't want to use any acceleration that can crash my
> machine, where can I select it, preferably as compile time option? I didn't
> find
> such a thing for Intel or Radeon. Don't say, I should rely on userspace here
> or
> use fbdev for this.
Just tell the X driver to n
ngle but huge driver for the GPU. As is normally the
>> >> case with GPU drivers, we can expect long discussions
>> >> before it will get considered for mainline
>> >> 4 patches
>> >> 98 files changed, 278321 insertions(+), 0
>
> The concerns about host memory access via the GPU driver are valid but
> unnecessary. The GPU MMU directly intervenes on memory access and can
> only modify memory space allocated to the GPU resource - getting data
> into this memory requires some extreme manual intervention if not done
> by th
On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey wrote:
> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann wrote:
>> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>>
>>> >> My point which people keep missing is that graphics stacks are a
On Wed, Dec 22, 2010 at 11:54 AM, Piotr Gluszenia Slawinski
wrote:
>> you have two pieces of code, a userspace 3D *driver* (not
>> application), and a kernel driver talking to the hw, if the userspace
>> 3D driver cannot exist without the kernel driver, it could very well
>> be considered a deriva
>
> I'm not advocating that closed source drivers be included in the
> kernel, but IMHO,
> having an open kernel-space driver would also help the reverse engineering
> process at the same time as allowing common users as well as developers to
> use and test any 3D applications -don't forget that 3D
On Fri, Feb 18, 2011 at 2:14 AM, James Simmons wrote:
>
>> I'm still in the learning-as-I-go phase here, so definitely not ready
>> to propose a solution, but it does seem to me like there is room for
>> some sort of kms-helper library here to handle more of the boilerplate
>> xf86-video-* stuff..
10 matches
Mail list logo
