[Mesa3d-dev] Optimize Texturing

[Klaus N. <kl...@ma...>]

My last email proposing an optimized, but not-GL-conformant, Game-Mode has not found many friends, so I guess, that the existing triangle-functions have to be optimized.

While I don't have the time to do it myself, I have thought of some method that should be taken by someone (that at least is what I hope) to implement them.

Most OpenGL-games render everything with Mipmapping enabled supposing that you have some Hardware that helps, so I took a look at them.

The current Mipmapping functions in the Mesa-code use at every plotted pixel a logarithm function to determine, which mipmapping-level should be used. This cannot (at least that I see) be avoided if you use an interpolation between these levels (like GL_xxx_MIPMAP_LINEAR) do.

But in the other cases I have developed a strategy, that maybe gives a speed-up, but which requires some changes in the source-code that are quite complex:

If the texturing mode is none of the both above, then evaluate lambda (=mipmap-level) at the three vertices of the triangle. If they all are the same (rounding with 'rint', but I'm not sure of this, maybe rounding with '(int)'), then all the lambda values of the whole triangle will be identical, therefore, you can switch to that mipmap-level and use a normal GL_LINEAR resp. GL_NEAREST-algorithm to do the rest of the work (this evaluates only 3 times 'log' instead of 'number-of-pixel'-times).
If the three values where different you proceed like it is done now, until the point, where each horizontal line is drawn. There you evaluate 'lambda' at the end and at the beginning of the line (lambda(0) and lambda(n)). Since lambda is a monotonous function, if these values are equal (after rounding) you can use this value to draw the whole line (and what would be in my opinion important is that you don't use gl_write_texture_span at the end, since this is quite slow, but this also requires a lot of work and thought).

Otherwise you proceed like it is done right now.

How often to I have to evaluate the log-function with the two methods?
Suppose the triangle had n lines with m pixels each. 
		Now	New method
Best		n*m	3
Medium		n*m	2*n (+3)
Worst		n*m     n*m + 2*n (+3)


Another thing that could be implemented is a function
float fast_log_2 (float arg)
that does the following: 

  -- convert 'arg' to an 'int'
  -- if (int)arg is smaller then e.g. 64 look the value up in a static array that is being created at start time.
  -- otherwise use '(int)arg>>1' until this value is smaller than e.g. 64 in which case you can use the array above and sum to the value the number of times you used '>>1'.

This way you get an integer-log-2 function and you don't have to use 'log(arg)*(1/log(2)). I believe that this function should be faster than the normal one (but you can use it only for calculations where you don't want to interpolate over the 'lambda'-mipmapping-levels).

Maybe someone has the time and the patience to play around with my ideas, I believe that they would give a very high performance gain.

The main difficulty is in introducing the calculation of the log-functions at the three vertices, since the file s_tritemp.h had to be changed.

So again, I hope someone tries my ideas. I think it really is important, that some optimization happens. It was being pointed out on the newsgroup, that 3d-hw is so cheap nowadays, that software-rendering is not important anymore, but I think this is really not true (it is not important if you use Windows: I have a 486, an K6 and an K6-2 at home and only the later has a ATI-Mach 64 which I use with utah-glx, but 30% of the time I start an application it hangs the machine, I worked in a company using Linux on all systems and none of the systems had running 3d-acceleration, here at the university I asked the system administrator if some of the 50 machines had hw-acceleration under Linux and none had, so I think software-rendering is right now, the only way to use 3d on Linux (without XFree 4.0, which I have never seen running anyway)).
If someone has questions, I hope I can help him. Thanks for your patience reading to this point.

Bye

	Klaus