Patrice Mandin
Hardware
- NV15 10de:0151 (AGP,VGA,64MB)
- NV30GL 10de:0309 (AGP,DVI,128MB)
Motivations
- Reverse engineering quite powerful hardware.
- Coding to the bare metal, like it used to be some years ago, having fun doing it :).
- Provide completely free drivers for still working hardware, useful when building old boxes for donations.
- Make a m68k platform with PCI bus being able to drive a Nvidia card, don't know if I will have enough time to do this one :).
TODO
- DONE: Fix renouveau to dump fragments/vertex programs again.
- DONE: May need to add renouveau.xml support in renouveau, to know which command is an offset in VRAM to dump a program.
- HALF DONE: Parse shaders in renouveau-parse, using renouveau.xml (where shader instruction formats will be stored).
- HALF DONE: Migrate more stuff from objects.c/nv_objects.h to renouveau.xml
- HALF DONE: Fix nv30 demo for nv30gl (nothing rendered)
- Document non obvious TCL parameters (for spot light or point parameters for example)
- Document usage of each object (for texture uploads for example)
Links
Freedesktop page: http://people.freedesktop.org/~pmandin/
Home page: http://pmandin.atari.org/
20080830
- After trying to get my new nv30_demo working, I finally found a small thing missing from nv30 gallium. The fragment program engine needs to have its texture units enabled, if you want it to generate proper texturing. Here is the result with xmoto. The texture is swizzled, because it is how the gpu reads it from vram if you don't tell him.
20080823
I setup a git repo with self made nv30_demo to play a bit with nv30 tcl engine myself.
- git clone git://anongit.freedesktop.org/~pmandin/nv30_demo
20080712
Finished converting state emission to use state objects. Now the hard part starts: find why resizing glxgears triggers LIMIT_ZETA fifo error (I suppose any application that use depth buffer could trigger it on resize), and why texturing is broken.
20080711
Converted most of state emission stuff for nv30, still have VBO to do. I was careful to not break anything, specially the stuff related to shaders, that I don't know that much. After that is done, I'll can have a look to fix texturing.
20080709
After some days playing with renouveau again, and adding new tests to cover more features of nv30 texture units, I am ready to go back to nv30 gallium coding.
20080625
Finally I found some free time to continue adapting the nv40 gallium backend to nv30. In the mean time, glxgears has correct lighting, I suppose I did not do anything to fix it, so maybe it was a gallium related bug. An example of things to fix is blending: 
On the left, current nv30 gallium backend, on the right, software renderer (which is correct). The hardest part for me is the shader stuff, that I don't know that much.
20080603
I have a new machine, built around a Pentium D 820 Marcheu sent me. I will do nouveau related stuff in 64bits now, nice. I just finished setting up Xorg for dual head with Nouveau and Randr12. Also, the NV30 seems much more stable here than in my old box. For people interested, the mother board is an ASRock 4CoreDual-SATA2. It has both AGP 8X and PCI-Express connectors, along with 4 PCI ones. Nice to plug many different cards.
20080518
- Just a little TODO list, currently busy with other stuff:
- DDX/DRM: Need to find why I still got X crashing with some PGRAPH ERROR. Missing stuff in context switch? Something else?
- Gallium: Need to finish rewrite of state emission, like nv40 backend does.
- Gallium: Find and fix texturing support.
20080317
- \o/ Today, it's my day (Saint Patrick, same day for Patrice :-)). Just adding a command related to the VIEWPORT_TX_ORIGIN fixed the offset in rendering.
20080310
- This night, while I was sleeping, Darktama fixed nv30 initialization. So we now have some triangle displayed. Nice. Now I must learn vertex program stuff to know it works. The triangle below should be centered in the window.
20080308
Retried nv30_demo from git://anongit.freedesktop.org/~jkolb/nv30_demo and I don't get any triangles, like the gallium backend. Must check missing init against nv30 exa in DDX.
20080301
Started having a look at gallium backend for NV30 a week ago. No rendering. Need to understand the code path.
20080107
I did my first mmio trace dump for nv30, trying various stuff for mode setting: http://people.freedesktop.org/~pmandin/10de0309-mmio.bz2
20071221
I got an idea with the work I have to do to fix EXA on nv30. In fact, I think the texturing stage has its own viewport setup. 
It's when looking at the renouveau.xml file, related to NV34TCL, and comparing with dumps, made me wondering why viewport values (x,y, width, height, and scale) where present at least twice in different registers. When trying to fix EXA for nv30, in fact, what was missing, is setting correctly the viewport for texturing stage. It is so much visible for example with register 0x2b8 (that I called the VIEWPORT_TX_ORIGIN), because without it, you see Gnome splashscreen, but the texture is offseted. And the same behaviour is visible with the text rendering. So I think we could rename one of the VIEWPORT_SCALE to VIEWPORT_TX_SCALE, and I think the 0xa00-0xa04 registers are the VIEWPORT_TX_SIZE. Maybe we even have some VIEWPORT_TX_CLIPPING (or SCISSOR, as you want).
20071215
- Strange nv30tcl command 0x2b8 has viewport x,y values. It was needed for nv30exa to work on nv30gl.
20071112
Upgraded development system to Debian/testing, to get Xorg xserver 1.3. All pre-1.2 server stuff removed from DDX, huge cleanup in sources. X starts now, so the "disable randr1.2" stuff was broking it for nv30. Now EXA needs to be fixed (no font rendered).
20071107
X does not start, something is broken in nv30 init (reports say it works for other nv3x gpus).
20071106
NV30GL finally plugged, up and running. Now I can try to find why some tests fail in renouveau, like the one for texture formats.
Attempt: 20071104
Having recently updated everything, I tried again some OpenGL games.
- Quake 3 Arena demo now lockups when playing the video, because it needs texturing to work to display the video.
- Frets on fire works, but lack texturing.
Attempt: 20070906
- The first triangle using Mesa DRI driver \o/.
- And glxgears later in the evening *\o/*.
Attempt: 20070904
- With p0g's help, I was able to find what was wrong in my nv10 tcl init in nv10_demo (available on sf.net cvs repo). So now, we can draw triangles using the tcl engine.
- More work needed in DRI to properly initialize tcl engine given current state of the OpenGL context, fixed modelview*projection matrix this day.
Attempt: 20070825
- More work done in nv10 context switch. Now X crashes only when bad parameters sent to gpu.
- Made a new glxgears screenshot on my fd.o page, disabled clear operations so we can see something :).
Attempt: 20070728
X locks up (seems cpu usage go to 100%, from what the fan speed I hear
after a program using an extra fifo has been used, and some blit operation done (like moving a window, opaque mode).
Attempt: 20070704
- I got an old mmio-like dump properly parsed. Looking at how the Nvidia driver deal with PGRAPH interrupts, it was clear what it was doing with those PGRAPH errors we get. If a fifo command is currently being processed, we must wait till it's finished before switching contexts. I made a small dirty patch for the nouveau irq handler, and now glxgears "works".
Attempt: 20070630
- After some hard lockups again due to Darktama's latest drm changes, that were fixed promptly, we still get PGRAPH errors when running glxgears. Most likely the PGRAPH object is not setup properly.
Attempt: 20070510
Finally, matc found the source of these lockups. FIFO size was wrong (still 32 bits, whereas NV17 and higher use 64 bits). Now X crashes when trying to click somewhere while glxgears is 'running'.
Attempt: 20070420
- No change, still hard lockup when FIRE_RING is done. Will try to log kernel messages to a serial console.
Attempt: 20070402
- No change, still hard lockup when FIRE_RING is done. I now wonder if my system setup is broken in anyway.
Attempt: 20070301
- No change, still hard lockup when FIRE_RING is done to tell gpu to process commands, reset button to rescue.
Attempt: 20070201
- X lockups were caused by missing xorg libglx.so and libGLcore.so, overwritten by NVIDIA proprietary driver. Now I am back to situation from 20070112.
Attempt: 20070127
- No more hard lockup of system. Only X lockups, waiting endlessly for something.
Attempt: 20070112
- glxinfo seems OK.
glxgears: hard lockup, no magic SysKeys, I have to reset.
Attempt: 20061222
- Once again, I got messed by different version of stuff in different places. Self-build mesa loads DRI module from /usr/X11R6/lib/modules/dri (default), whereas my system uses /usr/lib/dri. So copied nouveau_dri.so in both places :).
- Disabled AIGLX, now everything seems OK.
- glxinfo tells me nouveau+latest mesa is loaded.
glxgears opens its window, and wait for something. Click somewhere with mouse and X server crashes. Fifo dumped. I guess it needs proper context switching now. Using this patch is not enough for it.
Attempt: 20061216-2
- Updated to latest nouveau dri, remove old dri module and libGL.so lying somewhere on my system.
- AIGLX continue to pester about missing visuals, disabling it makes glxinfo and glxgears use software rendering.
- glxgears now crashes Xorg.log.
Attempt: 20061216
- Oops, I was using old Mesa version, it's better now, no more dispatch errors (though AIGLX till pester about missing visuals, maybe I should remove /usr/lib/libGL.so to be sure).
- glxgears still crashes though (I see it opening the window).
Attempt: 20061213
- More dispatch errors, from glxinfo and glxgears.
- AIGLX does not like not having visuals.
Attempt: 20061122
- glxgears and glxinfo both exit with same errorsn about some missing visuals and functions dispatch.