How to write a driver for a GPU?

S

Serg012

New Member
Joined
Jun 24, 2021
Messages
4
Reaction score
0
Credits
76
Hi, I'd like to try to write a driver for an old GPU, but unfortunatelly I don't even know how to start.
The GPU is VIA Chrome VX900 and last propreitary driver is for Ubuntu 12.10. I've tested it, and it runs fine, it is able to play 1080p video with no noticeable tearing (I think it was H264 encoded), but Ubuntu 12.10 is quite old now (certificate problems etc). There is also an open-source driver, however it currently doesn't support HW acceleration, at least not for video, and moving window or scrolling feels slow as well.

So, I thought, why not to try to write a driver for current kernel that could support smooth desktop animations (like moving window, scrolling, transparency, fade-in/out) and HW accelerated video decoding. I realize it won't be easy and will take some time, however I'd like to try.

On Openchrome project webpage there are two PDFs with GPU's register description, so I hope that could help in future with actual HW acceleration. However to start with I am thinking of something simple, like make single color background on monitor, or some solid-colored boxes, idk.

But how do I start?
I think, first of all I should understand Linux graphics stack, or how to name it. The thing, that user application calls in order to create graphics output.
From a perspective of GPU driver, I probably have to receive and process requests from an upper level API, right? But what is the upper level API for me?

I've heard about DRI, DDX, OpenGL, Mesa, Xserver, X11. However I am not sure how they are connected/tied, I mean, where do they reside in a graphics stack. Which of them I should concern if I am interested in 2D acceleration only? How do they communicate with GPU driver?

I checked the openchrome git repository, but I can't follow the code, since I don't know where is any entry point from which it will start execute, like a main() or something.

I thought there will be some structure with methods to be implemented, idk, like "create_object", "set_object_coords", "rotate_object", and driver will just take care of allocating memory for the object in the right memory region, and pass commands to corresponding registers in GPU. And then you just pass the structure with assigned functions that implements required methods to another function like "register_gpu_driver()", but I couldn't find anything like that there.

As you can see, I have no clue how graphics output generation actually works, but I want to find out. So, could you please give me some advice how to start? Thanks in advance
 


In the Debian Repository

xserver-xorg-video-openchrome

X.Org X server -- OpenChrome display driver

This package provides the 'openchrome' driver for the VIA Technologies
UniChrome and Chrome9 IGPs chipsets. The following chips should be
supported: CLE266, KM400(A), KN400(A), P4M800, K8M800, K8N800, PM800,
PN800, PM880, CN333, CN400, P4M800 Pro, VN800, CN700, CX700, VX700,
P4M890, VN890, CN800, K8M890, K8N890, P4M900, VN896, CN896, VX800, VX820,
VX855, VX875, VX900.

This package is built from the FreeDesktop.org xf86-video-openchrome driver.
Click to expand...
 
Thank you for quick reply.

Yes, I am aware of this driver, thats the "open-source" driver I mentioned, but unfortunately, it currently doesn't provide HW acceleration. It allows me to set higher resolution, and thats all. 720p video is like 1 frame per 4 seconds. I think that is probably because some API is not implemented in this driver yet. Maybe XvMC or VAAPI or VDPAU. But how does one implement such API?

I've just found some article about VDPAU on freedesktop.org, so I will read it later.
However I can't find any documentation for VAAPI or XvMC.
Moreover, VAAPI seems to be just Intel thing, is that correct?

That would solve the video playback acceleration, but what about desktop animations - like window moving, resizing, scrolling - which API is used to render desktop/window objects? Does window manager use OpenGL for that?
 
@Serg012 :-

Boy, oh boy. You're kinda jumping in at the deep end, aren't you?

Do bear in mind that both AMD and Nvidia have many, many years of experience when it comes to writing these things. From what I understand, writing the open-source, 'in-kernel' versions of these drivers is one of the most thankless tasks on the entire kernel team.....the whole thing has to be reverse-engineered from the originals, legal issues mean that only certain portions are available to 'look at' anyway, and although Team Green have released some of their code under an open-source licence recently, they're by no means sharing all of it.

(Team Red are a bit more forthcoming with code, but even they don't give all their secrets away...)

I wish you all the luck in the world, but you may have set yourself an impossible task, y'know? Unless you're already a proficient, experienced coder/programmer, that is....

(shrug)


Mike. ;)
 
I was about to search for something like the link @osprey has provided, so kudos.

Capturing OS/Hardware communication on a machine running Ubuntu 12.10 with the driver that you want to reverse-engineer can be a first step, but the scope of your task is massive and multi-disciplinary if you want the driver to embed video codecs.

But it's an exciting endeavour. I would read this book https://lwn.net/Kernel/LDD3/, specifically the PCI drivers chapter, then in parallel:
  • get into sending contributions to the kernel to warm up and know how the rules of engagement are,
  • read and study an existing driver that would cover similar problems, to size the beast.
Contributing with smaller patches into existing dirvers can also help you make connections with people that may be able to join your cause.
 
PS -- each and every single person that is currently writing drivers was once in the very same place you're now, so don't give up if you think the task may to be too big.

There's value on doing it despite how old the card is, succeeding or even progressing in the way can open you job opportunities, and establishing small, weekly achievable targets will get you closer to your goal quicker than you think.
 
Serg012 said:
That would solve the video playback acceleration, but what about desktop animations - like window moving, resizing, scrolling - which API is used to render desktop/window objects? Does window manager use OpenGL for that?
Click to expand...
Those operations are done by the window compositor, for either X11 or Wayland. According to their respective designs, you'll need to check what system calls they do to the kernel to perform graphics operations.

Chances are they use a lower level graphics library from various possibilties (openGL, mesa, framebuffer, svga,...), however.
 
Thanks, I will definitely check the LDD3 book.

Regarding reverse engineering, I hope it won't be necessary, since there are few PDFs with GPU registers definitions (Here: https://www.freedesktop.org/wiki/Openchrome/Development/), actually that is the situation from first bullet point.

I could fork openchrome source code, however, it is already too complex for me, and I am not yet able to navigate through that code.

As you say - start with small goals - I think I should first understand how Linux chooses driver to load and what is entry point, to get at least some output like "Yaay I've been loaded" into some log file.
Until now I've been writing code that has only one entry point and that is main(). However, I think driver is not a program, more like some shared library, isn't it? If that is the case, then there has to be some standard methods (symbol names) other applications would call when they want something from gpu, right? However in openchrome code I see only functions with VIA prefix in name (definitely not a standard symbol), or a static functions (private), so that is why I can't see any entry point, where I could start writing my code and know how to get it executed.
 
MikeWalsh said:
Boy, oh boy. You're kinda jumping in at the deep end, aren't you?
Click to expand...
This is very insightful. The skills you require can take a long time to learn. Even with good general skills, a very optimistic estimate would be one year or more. Probably more++.

I wrote device drivers long ago, but those days are long gone and much has changed. (They were for networks and custom systems.) I know nothing about graphics drivers, but it is hard to imagine writing any device driver where useful technical information is withheld by the manufacturer. It was hard enough when you had direct, immediate access to the hardware designers. That makes a HUGE difference.

A device driver is not an ordinary single entry / single exit application. Device drivers handle hardware interrupts at the kernel level. You will learn hundreds of new ways to cause kernel panics. (I assume that graphics drivers run in kernel space but not certain.)

The tools you will need vary in quality. Hopefully that has improved, but even today, I would not be surprised if device driver writers are still fighting with inaccurate documentation, buggy software and tools, and more. I remember a debugger where the code would take one branch and the debugger would show the opposite in the software listing as you stepped. Yeah, stuff like that.

You will learn about multi-threaded code for sure. You will invent all kinds of new and creative debugging techniques to try and figure out "What the @#$@$#@ is going on in there???" You may see bugs with errant pointers that overwrite random areas of memory like land mines ... until FINALLY some code can't handle it and you get a kernel panic. Of course whatever overwrote memory is long gone from the trace buffer. You may run your code over and over and hope for timing luck to capture multiple related events in one trace.

I encourage you to try this 100%. You will learn so much in many disciplines. When things begin to come together and work, it is an indescribable feeling. Having written that, Bob is right. You are jumping in at the deep end. You never want to expect failure up front, but take the positive attitude that you will walk out with much more than you walked in. It will be as much an education as it is a project.

But ... the water's fine! Take a leap!
 
Many years ago, I wrote a driver for a plotter - and that was with professional help AND the plotter company offering what support they could.

This? This is delightfully insane. I wish you the best of luck and my comment is partially so that I get to watch this space.
 
Serg012 said:
However, I think driver is not a program, more like some shared library, isn't it? If that is the case, then there has to be some standard methods (symbol names) other applications would call when they want something from gpu, right?
Click to expand...
It's close to a shared library, but as a kernel module it runs in kernel mode. This means that you will have to deal with more interfaces than that:
  • The Kernel will call you to initialise the hardware, and you will have to inform the kernel with a lot of data and characteristics (interruption lines, usage of the bus, amount of graphics memory,...) -- that's a standard interface you'll have to implement
  • You will have to access main resources like regular RAM and other parts of the computer, and this will be done using specific kernel calls. -- that's a standard interface you'll have to call
  • The kernel will call you at any moment just for you to help it control the lifecycle of the device (e.g.: cleanup before shutdown,...) -- that's another interface that you'll have to implement (or a part of the first in the list)
  • And then, you will provide those symbol names for the kernel to expose to other libraries and programs --that's the one you're seeing in your post.
What those symbol names are? No idea. Better inspect the code free/opensource version you mentioned in the post #2 by @arochester to identify those interfaces, or even better, carve out that driver to leave an empty scaffolding and start your implementation from such scaffolding.
 
Also: as part of the journey is interacting with the kernel code, which is where many drivers are, following the instructions of this video (by one of the authors of the LDD and lead maintainers of the kernel) will help you set up your dev environment in terms of tools, email client configuration, code conventions, etc.:


In that video you'll also find references and tutorials to create your first kernel module, as in writing the "HEY I AM LOADED!" log, if I remember correctly.
 
sphen said:
A device driver is not an ordinary single entry / single exit application. Device drivers handle hardware interrupts at the kernel level. You will learn hundreds of new ways to cause kernel panics. (I assume that graphics drivers run in kernel space but not certain.)

The tools you will need vary in quality. Hopefully that has improved, but even today, I would not be surprised if device driver writers are still fighting with inaccurate documentation, buggy software and tools, and more. I remember a debugger where the code would take one branch and the debugger would show the opposite in the software listing as you stepped. Yeah, stuff like that.

You will learn about multi-threaded code for sure. You will invent all kinds of new and creative debugging techniques to try and figure out "What the @#$@$#@ is going on in there???" You may see bugs with errant pointers that overwrite random areas of memory like land mines ... until FINALLY some code can't handle it and you get a kernel panic. Of course whatever overwrote memory is long gone from the trace buffer. You may run your code over and over and hope for timing luck to capture multiple related events in one trace.

I encourage you to try this 100%. You will learn so much in many disciplines. When things begin to come together and work, it is an indescribable feeling. Having written that, Bob is right. You are jumping in at the deep end. You never want to expect failure up front, but take the positive attitude that you will walk out with much more than you walked in. It will be as much an education as it is a project.
Click to expand...
I couldn't have put it better myself.

As I said, I wish the OP all the luck in the world, but they will find a path strewn with many & varied obstacles. If the enthusiasm stays strong, and there is determination to match, then it's not insurmountable.....but it WILL be a steep learning curve, make no mistake about that.

Many disciplines come together to create something like this, and it may involve learning several of those from scratch simply to progress further. I must agree with @sphen ; whatever the endeavour - even learning to script in Bash - it's an indescribable feeling when you finally solve issues & your creation begins to do that which you want it to do.

I think most of us will wish you luck with this. Who knows.....you may develop an entirely new career from all of this!


Mike. ;)
 
You must log in or register to reply here.

Members online

Total: 716 (members: 4, guests: 712)

Latest posts

Top