HOWTO implement an OpenGL extension for Mesa

[bridgman]

9. Figure out how the hardware works. If necessary, modify the test to add runs with different parameters, until you get a complete picture

This one is the hard part

[Agdr]

I don't really understand why you're saying this, given that between ATI/AMD and community developers they have nearly caught up on 8 years of new product introduction (r3xx came out in 2002) in a bit over 3 years.

Sorry, I think I made a poor choice of words. I meant to say you are currently behind, not that you are not accelerating and going to fix that.

In particular, there is the basic Evergreen support, and then I believe there are several undocumented areas like DirectX 11 tessellation and hull/domain shader dispatch, hardware MMU, demand paging and multiple context support (if any exists), compute shader dispatch, whatever other new features Evergreen has not already documented in the ISA docs, and perhaps holes in the less advanced stuff too.

Also, documentation and initial support for the next architecture refresh ("Southern Islands"?), and the next new architecture, so that people interested in open source can start sending money to you sooner.

[marek]

I don't think it's worth writing an excessive amount of documentation by 10 developers just to get maybe 2 new hobbyist contributors.

This is how to get started and quickly get to know Mesa well:
- Know OpenGL and shaders.
- If you know OpenGL and shaders, you will get to know the Gallium3D interface pretty quickly (look at gallium docs and headers).
- Learn what's between the Mesa core (src/mesa/main), which *is* OpenGL, and Gallium3D (src/gallium/include/pipe). You will find out it's the mesa state tracker (src/mesa/state_tracker). Learn how it works by reading code.
- Look at code of a few gallium drivers, see how they are structured.
- Look at some commits to see how new extensions are added.
- Look at some commits to see how to change the Gallium3D interface to add a new feature, and what else needs to be done to make that feature supported in the entire stack.
- Understand that you are NOT expected to know everything.

This is how I started:
- Read Gallium headers, make sure you understand it.
- Read the driver you are interested in.
- Look for things that can be improved or fixed in the driver and send patches, without knowing anything else about Mesa, kernel DRM, DDX etc. (you'll learn that stuff as time goes by anyway)

And finally, the discuss-to-the-death approach doesn't work well if you also want to have some time for coding.

[nikai]

This is how to get started and quickly get to know Mesa well:
- Know OpenGL and shaders.
- If you know OpenGL and shaders, you will get to know the Gallium3D interface pretty quickly (look at gallium docs and headers).
- Learn what's between the Mesa core (src/mesa/main), which *is* OpenGL, and Gallium3D (src/gallium/include/pipe). You will find out it's the mesa state tracker (src/mesa/state_tracker). Learn how it works by reading code.
- Look at code of a few gallium drivers, see how they are structured.
- Look at some commits to see how new extensions are added.
- Look at some commits to see how to change the Gallium3D interface to add a new feature, and what else needs to be done to make that feature supported in the entire stack.
- Understand that you are NOT expected to know everything.

Thanks! Looks like a plan.

I'd like to add that GPU command stream analysis is not only useful for reverse engineering, but also for tracking down open driver bugs by looking for commits changing the command stream, to compare the command streams generated by two drivers to figure out, and to develop immature hardware without locking up the hardware every time.

In general, the tools used are:
- mmiotrace, which logs all writes and reads from PCI registers: used to log the register read/writes by the kernel driver and X driver. Included in the mainstream kernel
- valgrind-mmt, which logs all writes and reads from PCI registers generated by an userspace application.
- renouveau, which dumps the command stream of the nVidia Linux OpenGL driver
- revenge which dumps the command stream of the ATI Linux OpenGL driver
- patches to libdrm that dump the command stream of the open drivers
- renouveau-parse (and perhaps rules-ng-ng tools) to convert hexadecimal data into readable register offset/value pairs for known registers for nVidia cards
- radeondb (and maybe others?) to convert hexadecimal data into readable register offset/value pairs for known registers for nVidia cards

Great, thanks! I recently contemplated dumping copies of IB buffers that lock up the GPU to debugfs as binary blobs.

I'm primarily interested in enabling native applications to run with open drivers.

[netkas]

btw. those can be fixed easily, cuz seems to be static values, depending on card family, just need to find exact value and add them

EE r600_screen.c/r600_get_param:110 - r600: unknown param 43 - PIPE_CAP_MAX_FS_INSTRUCTIONS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 44 - PIPE_CAP_MAX_FS_ALU_INSTRUCTIONS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 45 - PIPE_CAP_MAX_FS_TEX_INSTRUCTIONS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 46 - PIPE_CAP_MAX_FS_TEX_INDIRECTIONS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 48 - PIPE_CAP_MAX_FS_INPUTS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 50 - PIPE_CAP_MAX_FS_TEMPS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 51 - PIPE_CAP_MAX_FS_ADDRS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 49 - PIPE_CAP_MAX_FS_CONSTS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 53 - PIPE_CAP_MAX_VS_INSTRUCTIONS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 54 - PIPE_CAP_MAX_VS_ALU_INSTRUCTIONS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 55 - PIPE_CAP_MAX_VS_TEX_INSTRUCTIONS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 56 - PIPE_CAP_MAX_VS_TEX_INDIRECTIONS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 58 - PIPE_CAP_MAX_VS_INPUTS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 60 - PIPE_CAP_MAX_VS_TEMPS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 61 - PIPE_CAP_MAX_VS_ADDRS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 59 - PIPE_CAP_MAX_VS_CONSTS
EE r600_screen.c/r600_get_param:110 - r600: unknown param 63 - PIPE_CAP_GEOMETRY_SHADER4
EE r600_screen.c/r600_get_param:110 - r600: unknown param 64 - PIPE_CAP_DEPTH_CLAMP

[netkas]

btw. those can be fixed easily, cuz seems to be static values, depending on card family, just need to find exact value and add them

EE r600_screen.c/r600_get_param:110 - r600: unknown param 43 - PIPE_CAP_MAX_FS_INSTRUCTIONS
......
EE r600_screen.c/r600_get_param:110 - r600: unknown param 64 - PIPE_CAP_DEPTH_CLAMP

a patch for most of these issues, based on data from r600c and a bit on data from r300g

http://mirror.netkas.org/patch_r600g.diff

--- mesa/src/gallium/drivers/r600/r600_screen.c	2010-08-06 18:26:20.000000000 +0400
+++ mesa/src/gallium/drivers/r600/r600_screen.c	2010-08-08 23:13:29.000000000 +0400
@@ -52,6 +52,9 @@
 
 static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param)
 {
+struct r600_screen *screen = r600_screen(pscreen);
+enum radeon_family family = radeon_get_family(screen->rw);
+
 	switch (param) {
 	case PIPE_CAP_MAX_TEXTURE_IMAGE_UNITS:
 	case PIPE_CAP_MAX_COMBINED_SAMPLERS:
@@ -106,6 +109,40 @@
 	case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
 	case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
 		return 0;
+	case PIPE_CAP_MAX_FS_INSTRUCTIONS:
+	case PIPE_CAP_MAX_FS_ALU_INSTRUCTIONS:
+		return 8192;
+	case PIPE_CAP_MAX_FS_TEX_INSTRUCTIONS:
+		if (family >= CHIP_R600 && family < CHIP_RV770)
+		    return 8;
+		else
+		    return 16;
+	case PIPE_CAP_MAX_FS_TEX_INDIRECTIONS:
+		return 8; /* ??? */
+	case PIPE_CAP_MAX_FS_INPUTS:
+		return 32;
+	case PIPE_CAP_MAX_FS_TEMPS:
+		return 128;
+	case PIPE_CAP_MAX_FS_ADDRS:
+		return 0;
+	case PIPE_CAP_MAX_FS_CONSTS:
+		return 0;
+	case PIPE_CAP_MAX_VS_INSTRUCTIONS:
+	case PIPE_CAP_MAX_VS_ALU_INSTRUCTIONS:
+		return 8192;
+	case PIPE_CAP_MAX_VS_TEX_INSTRUCTIONS:
+	case PIPE_CAP_MAX_VS_TEX_INDIRECTIONS:
+		return 0;
+	case PIPE_CAP_MAX_VS_INPUTS:
+		return 160;
+	case PIPE_CAP_MAX_VS_TEMPS:
+		return 128;
+	case PIPE_CAP_MAX_VS_ADDRS:
+		return 1;
+	case PIPE_CAP_MAX_VS_CONSTS:
+		return 256;
+	case PIPE_CAP_GEOMETRY_SHADER4:
+		return 0;
 	default:
 		R600_ERR("r600: unknown param %d\n", param);
 		return 0;

[whizse]

There's also not much point in spending much effort on the classic drivers, and focus on Gallium3D instead, or am I wrong?

[marek]

a patch for most of these issues, based on data from r600c and a bit on data from r300g

http://mirror.netkas.org/patch_r600g.diff

A lot of those numbers are little off, I need to extract the real numbers from docs, or someone else might do.

[marek]

There's also not much point in spending much effort on the classic drivers, and focus on Gallium3D instead, or am I wrong?

That's what VMWare/TG, Nouveau, and Radeon people think. However Intel doesn't seem to be moving to Gallium anytime soon.

[netkas]

A lot of those numbers are little off, I need to extract the real numbers from docs, or someone else might do.

well, i tried to look at docs, r600isa.pdf, 3d programming pdf and registers pdf, and didnt find anything usefull