Implementing the accelerated DRI/DRM driver for a pure 2D graphics card?

Implementing the accelerated DRI/DRM driver for a pure 2D graphics card?

[Tom Li]

Hello everyone.

I'm currently working on a DRM/KMS driver for the Silicon Motion SM712
graphics card. Avoid the flicking between the VT-switching on my
computer is what I want.
This antiquated card doesn't support 3D and OpenGL stuff, but provide
simple 2D acceleration by a drawing processor. Currently, the DDX
driver xf86-video-siliconmotion directly accessing the hardware to
write the registers for modesetting and 2D acceleration.

But in the world of KMS/DRI, Xorg/DDX can't just control the cards and
write the registers anymore. It is not a problem for modesetting
because there's standard KMS way, but it prevent the DDX driver to
access the 2D drawing processor. It is the problem, the card will
become even more slower if it lost the only acceleration.

Implement the complete DRI/DRM framework seems the right way to do it.
But it seems the DRI/DRM are mainly designed for modern cards, 2D is
just the subset of 3D / OpenGL, so it always got implemented
automatically if we just implemented 3D. Many documents are talking
about how to deal with the vertices / textures to implement 2D/3D, but
I just have something like fillrect.

So I just stuck at here. Is there a standard way to just let
userspace/DDX to access the 2D drawing processor by the exported
interface or DRI/DRM layer?

Thanks,

Tom Li

Re: Implementing the accelerated DRI/DRM driver for a pure 2D graphics card?

[Ilia Mirkin]

On Mon, Aug 11, 2014 at 9:42 AM, Tom Li <biergaizi2009@gmail.com> wrote:
> Hello everyone.
>
> I'm currently working on a DRM/KMS driver for the Silicon Motion SM712
> graphics card. Avoid the flicking between the VT-switching on my
> computer is what I want.
> This antiquated card doesn't support 3D and OpenGL stuff, but provide
> simple 2D acceleration by a drawing processor. Currently, the DDX
> driver xf86-video-siliconmotion directly accessing the hardware to
> write the registers for modesetting and 2D acceleration.
>
> But in the world of KMS/DRI, Xorg/DDX can't just control the cards and
> write the registers anymore. It is not a problem for modesetting
> because there's standard KMS way, but it prevent the DDX driver to
> access the 2D drawing processor. It is the problem, the card will
> become even more slower if it lost the only acceleration.
>
> Implement the complete DRI/DRM framework seems the right way to do it.
> But it seems the DRI/DRM are mainly designed for modern cards, 2D is
> just the subset of 3D / OpenGL, so it always got implemented
> automatically if we just implemented 3D. Many documents are talking
> about how to deal with the vertices / textures to implement 2D/3D, but
> I just have something like fillrect.
>
> So I just stuck at here. Is there a standard way to just let
> userspace/DDX to access the 2D drawing processor by the exported
> interface or DRI/DRM layer?

There's nothing specific to 3D in the DRM api's exposed by the kernel
drivers. They all just provide a method for submitting commands to the
card via ioctl's, manage buffers, etc. Each driver has its libdrm_foo
userspace API that hides the ioctl nastiness and provides a cleaner C
API. Many modern (and even older) hardware works by having a command
ring that the hardware processes, and userspace just provides lists of
those commands, as well as buffer management. Then the DDX and Mesa
and anything else that wants direct access uses the
libdrm_foo-provided APIs to submit commands to the card.

Hope this helps,

  -ilia

Re: Implementing the accelerated DRI/DRM driver for a pure 2D graphics card?

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 625 bytes --]

Tom Li <biergaizi2009@gmail.com> writes:

> So I just stuck at here. Is there a standard way to just let
> userspace/DDX to access the 2D drawing processor by the exported
> interface or DRI/DRM layer?

The Intel UXA driver uses the 2D engine for simple X acceleration
through the kernel DRI/GEM interfaces. The portion of that interface
designed to support accelerated graphics operations is entirely
GPU-specific, so you would design that based on how your card works, and
the resulting 2D driver would be chipset specific as well, using the
custom kernel interfaces you create.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 810 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel