[joh]

My goal is ultimately to learn more about GPU architecture and graphics driver development. I'd like to try implementing a 2D kernel space and user space driver, as I've been advised that that is a much easier project when familiarizing oneself with driver development. (I have no driver or kernel dev experience and little linux experience. I've been a OS X developer my whole life however, so I am familiar with the unix environment).

My problem is two-fold:

(1) I'm struggling to find a hobbyist-oriented linux box on the market that uses a well-documented graphics card, or for that matter finding any kind of documented GPU. I'm looking for something with a similar price point as the BeagleBoard (which uses the closed-source PowerVR SGX). If something like that doesn't exist, I believe my only other alternative may be to work with the much more complicated Sandy Bridge integrated chip, as I have one in my laptop and it seems to be well (but tersely) documented at intellinuxgraphics.org.

(2) Given either direction I go with in point 1, I'm still vague on how to actually communicate with a graphics card. After some digging in the intel linux drivers, it seems that it all boils down to essentially libdrm (which I believe to be the kernel space API vendors must implement for each card...?) calling ioctl on a file in /dev corresponding to the graphics card. Is that correct?

Thank you to anyone who can shed some light on my questions and help me along!

[Dominik D]

Don't want this to sound like an ad but why don't you just join Imagination Technologies? We're hiring for driver dev positions in all locations (UK, Poland, India,...).

As for the original question - if what you care about is "how do I write a driver?", you could take the "no hardware" approach and work on a driver, that doesn't really talk to any specific HW. It should be pretty easy with 2D graphics: at the end of your data path in KMD don't hand data over to HW via DMA; instead produce a usable dump that can be fed into something. For 2D raw data dump + commands for the ImageMagick or GraphicsMagick should be enough for starters.

[joh]

Haha, perhaps someday, but as it be I am still working through my schooling. I have certainly considered the possibility however!

I've considered that route and that is my backup plan. I think you're right in that it would still provide a lot of valuable driver development experience. It would perhaps also be good practice for designing graphic driver interfaces so if in the future I do find what I'm looking for (a simple and well documented graphics card), I could write a backend for my KMD that would interop with the hardware. If you don't mind me asking you Dominik, assuming you work at Imagination Technologies (which I think is a fair assumption to make :P), what was your first exposure writing drivers and first exposure writing drivers specifically for a graphics stack?

I just may take the route you're suggesting, but my original question still stands about the availability of any such graphics hardware and I hope others still chime in .

[Dominik D]

I haven't been working on drivers prior to joining Imagination at all. I used to work on Volume ShadowCopy Service, user mode infrastructure component that's part of Windows. This however gave me all of the important skills when developing under windows: understanding of the platform and its APIs, familiarity with tools (build infrastructure, WinDbg, scripting), and so on. I also used to do some lame stuff on the demoscene* which gave me the necessary background in graphics programming.

The reality is that in the production environment you won't write code from scratch 99% of the time. I didn't have to figure out how UMD talks to KMD via DXGK, got here after people way smarter than me wrangled that. And since understanding well written code is much easier than writing one, the whole ordeal of context management and data passing was easier to grasp going through the existing codebase rather than trying to figure it out from the documentation and sample code.

On that note - have you considered looking at the VirtualBox code? This could be a good starting point and a great working environment at the same time. That said it's worth mentioning that working with existing code can make it hard for you to work on a competing product, so keep that in mind. Not a lawyer however, could be it's absolutely OK and NDA/GPL spoil are just some artifacts of my paranoid imagination. ;]


*no, demoscene is not lame - my stuff was :P

[joh]

That's encouraging to hear that companies are willing to hire without prior (professional) experience in the subfield. Thanks for sharing your background .

I do understand that I will never be asked to write much of the foundation code I would have to write for a hobby driver, but I think that's half the fun and a good educational opportunity.

I think I will stay away from VirtualBox purely because of the GPL license. I share your fear of potential GPL lawsuits down the road :P.

[Arwin]

Would the Raspberry be suitable for this kind of thing?

[Dominik D]

Originally Posted by joh

That's encouraging to hear that companies are willing to hire without prior (professional) experience in the subfield.

It's such a niche that it's pretty much given you don't have prior experience in this very field. Besides - a lot of what you end up doing has to do with internal architecture of the hardware which you pretty much can't learn not working for the given company so even if you transfer from, say, AMD to NVIDIA, you're starting from scratch with a new codebase, different architecture, tools, etc. You'll get up to speed faster but it's not like you know everything.

[3dcgi]

Dominik explained it well. It would be a rare school that taught driver development. Coding skills are essential and graphics knowledge very helpful. If you learn driver development on your own and like it enough to continue professionally you'll surely stand out amongst your peers.

[ERP]

Originally Posted by Arwin

Would the Raspberry be suitable for this kind of thing?

There isn't any low level documentation on the GPU.
Same is true of the TI OMAP processors used in the Beaglebone etc, I really don't understand the secrecy.

It's irritating for me because my particular application is extremely timing critical and would be much better without the OS overhead.

I really don't see how exposing the control registers and Buffer formats would in anyway compromise the IP of the GPU manufacturers.

[joh]

Originally Posted by Dominik D

It's such a niche that it's pretty much given you don't have prior experience in this very field. Besides - a lot of what you end up doing has to do with internal architecture of the hardware which you pretty much can't learn not working for the given company so even if you transfer from, say, AMD to NVIDIA, you're starting from scratch with a new codebase, different architecture, tools, etc. You'll get up to speed faster but it's not like you know everything.

I was starting to get that impression. Though there are definitely downfalls to this aspect (longer adjustment period when switching jobs, less sharing within the industry, etc), the fact that with each judge one is guaranteed to learn a lot is an exciting prospect.

Originally Posted by 3dcgi

Dominik explained it well. It would be a rare school that taught driver development. Coding skills are essential and graphics knowledge very helpful. If you learn driver development on your own and like it enough to continue professionally you'll surely stand out amongst your peers.

That will just be an added bonus .


Would Linux on the PS3 be a good platform? I remember a couple of years ago when I was looking into PS3 development, there wasn't any hardware accelerated graphics yet, but maybe this has changed?

[Davros]

Originally Posted by ERP

I really don't see how exposing the control registers and Buffer formats would in anyway compromise the IP of the GPU manufacturers.

If they did that would it become like early cpu programming (maybe soundcard programming would be a better example)
put value X in register Y issue interrupt Z ?

[imaxx]

Originally Posted by joh

the fact that with each judge one is guaranteed to learn a lot is an exciting prospect.

IF you want to be serious about driver development and dont want to make like many guys that should do something else than playing at r0...

1. buy subverting the windows kernel book, and learn to write your own rootkit under winxp (leave away vista+ for now).

2. download the old ddk for winxp (or the new one and use the old one for xp), leaving away the MS framework... just write something easy to start on (DONT even think to support a tenth of what MS tells you should do support, life is short...).

3. set up a proper debug environment: take a VM and install XP, and set up winDBG for remote debugging OR use Syser debugger OR (ahem...) SoftICE (supposing you alreay have a license you forgot from old times ofc). You dont have nice R3 debuggers there.

4. Learn x86 assembler and IA32 details (no need to read in full the Volume 2 of intel, any way... unless you want to go really deep).

5. In the book listed at (1) you'll discover many important things that change in Kernel mode, and much information about the way windows works internally (IDT, paging, SSDT, miniport and so on).

Let me suggest you to start doing something easy yet funny: make a simple driver that exports a standard interface and start adding (gradually) commands to it.

Ah, just remember that when you play with processor's structures (IDT), you'll have to understand how to change them on ALL processors/cores.

...all in all... have fun!
r0 coding (and debugging) can be VERY funny
...recently i aided a colleague writing his own r0 driver -he had alot of troubles with it, giving me a lot of fun discussing with him about possible problems and solutions

ah, as an additional note... buy the IDA Pro reversing book's of Chris Eagle. I cant imagine r0 coding without reversing the kernel

ps: a trick and a valuable suggestion to pin into the side of your monitor ...always, always remember to validate the memory area you go to read or write... memory tends to disappear randomly