Originally posted by marek
View Post
OTOH, had there been a tutorial for the driver programming with clear statement of prerequisites, there'd have been no confusion on my side.
Originally posted by marek
View Post
1. You run the test OS in a VM, which somehow is able to access the graphics hardware directly (not OpenGL pass-through, but actually accessing the registers and the memory), while still being bounded to its own sandbox, so any corruption or crashes wouldn't affect the host.
2. A tool provides you with a unified way of interacting with the whole graphics stack inside the VM, from DRM to the target 3D program. Ideally, the tool would allow you to debug all the way through the process boundaries, so e.g. you can step into the 3D app and, tracing through its call stack, end up in the kernel space.
Now *that's* the kind of toolset I'd love to use! Maybe that is too much comfort for a driver developer, but for me, debugging is the natural way of dealing with new code. Whenever I start learning a new framework, after going through the basic manual, my favorite way of spending the first X weeks with it is stepping through its guts, repeatedly. Being able to do that with as little hassle as possible is even more important when the framework is under-documented.
P.S. (Jun 2009, #radeonhd)
Jun 17 08:14:34 <nfrs> how do you debug the x.org driver?
Jun 17 08:14:49 <airlied> oh also it helps if you have 2 Pcs
Jun 17 08:14:56 <nfrs> nope, I don't
Jun 17 08:15:35 <yangman> it's doable with 1. just a lot of hassel, and a lot of faith that hard restarts won't corrupt your data
Jun 17 08:21:01 <yangman> I'm turning my laptop into a dev machine so I can work on KMS. I'd rather hack on r7xx, but I need the desktop too much right now to be doing silly things on it
Jun 17 08:27:04 <nfrs> how do you run Xorg inside gdb?
Jun 17 08:27:19 <nfrs> I mean, technically. set-up? commands?
Jun 17 08:28:44 <yangman> I sprinkle generous amount of ErrorF()
Jun 17 08:28:58 <airlied> yeah I'm with yangman I normally ErrorF debug
Jun 17 08:30:33 <yangman> for r6xx Xv, the shader part was debugged by basically rendering data
Jun 17 08:31:10 <nfrs> rendering on screen?
Jun 17 08:31:28 <yangman> yup. the code was already there. I was altering it
Jun 17 08:14:49 <airlied> oh also it helps if you have 2 Pcs
Jun 17 08:14:56 <nfrs> nope, I don't
Jun 17 08:15:35 <yangman> it's doable with 1. just a lot of hassel, and a lot of faith that hard restarts won't corrupt your data
Jun 17 08:21:01 <yangman> I'm turning my laptop into a dev machine so I can work on KMS. I'd rather hack on r7xx, but I need the desktop too much right now to be doing silly things on it
Jun 17 08:27:04 <nfrs> how do you run Xorg inside gdb?
Jun 17 08:27:19 <nfrs> I mean, technically. set-up? commands?
Jun 17 08:28:44 <yangman> I sprinkle generous amount of ErrorF()
Jun 17 08:28:58 <airlied> yeah I'm with yangman I normally ErrorF debug
Jun 17 08:30:33 <yangman> for r6xx Xv, the shader part was debugged by basically rendering data
Jun 17 08:31:10 <nfrs> rendering on screen?
Jun 17 08:31:28 <yangman> yup. the code was already there. I was altering it
Comment