mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2025-12-29 16:40:13 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
24a4ea003f
This patch add a brand new nv04-nv40 2D engine module. It should correctly implement all operations involving swizzled, and 3D-swizzled surfaces. This code is independent from the Gallium framework and can thus be reused in the DDX and classic Mesa drivers (it's only likely to be useful in the latter, though). Currently, surface_copy and surface_fill are broken for 3D textures, for swizzled source textures and possibly for some misaligned cases The code is based around the new nv04_region structure, which encapsulates the information from pipe_surface needed for the 2D engine and CPU copies. The use of nv04_region makes the code independent of the Gallium framework and allows to transform the nv04_region without clobbering the nv04_region. The existing M2MF, blitter, and SWIZZLED_SURFACE paths have been improved and a new CPU path has been added. There is also support to tell the caller to use the 3D engine. The main feature of the copy/fill setup algorithm is linearization/contiguous-linearization of swizzled surfaces. The idea of linearization is that some swizzled surfaces are laid out like linear ones (1xN, 2xN, Nx1) and can thus be used as such (e.g. useful for copying single pixels). Also, some rectangles (e.g. the whole surface) are contiguous in memory. If both the source and destination rectangles are swizzled but contiguous, then they can be regarded as both linear: this is the idea of "contiguous linearization". This, for instance, allows to use the 2D engine to duplicate the content of a swizzled surface to another swizzled surface, by pretending they are actually linear. After linearization, the result may not be 64-byte aligned. Another transformation is done to enlarge the linear surface so that it becomes 64-byte aligned. This is also used to 64-byte align swizzled texture mipmaps. The inner loop of the CPU path is as optimized as possible without using SSE/SSE2. Future improvements could include SSE/SSE2 support, and possibly a faster coordinate swizzling algorithm (which is however not used in the inner loop). It may be a good idea to autogenerate swizzling code at least for all possible POT 2D texture dimensions (less than 256), maybe for all 3D ones too (less than 4096). Also, it woud be a very good idea to make a copy with the GPU first if the source surface is in uncached memory. |
||
|---|---|---|
| bin | ||
| configs | ||
| docs | ||
| doxygen | ||
| include | ||
| scons | ||
| src | ||
| windows | ||
| .emacs-dirvars | ||
| .gitattributes | ||
| .gitignore | ||
| acinclude.m4 | ||
| autogen.sh | ||
| common.py | ||
| configure.ac | ||
| Makefile | ||
| SConstruct | ||
WindML Driver for Mesa 4.0
Requirements
------------
Tornado 2 + WindML, Cumulative Patchs are recommended.
I suppose you have a valid WindML installation. Double buffer hardware
gives better performance than double buffer software so if you can
compile your WindML driver with this option, just do it. I/O
redirection is adviced in target server.
Tested on
---------
During the development, my main target was a CoolMonster:
- Video card: CT69000
- CPU: PENTIUM 266MHz
and my host a Windows NT + Tornado 2.
Installation
------------
1. Mesa sources must be in root directory (C:\)
2. Add the following line to your torVars.bat:
set MESA_BASE=C:\Mesa
OR copy the new torVars.bat in your bin path:
c:/Mesa/src/ugl/tornado/torVars.sample ->
/mnt/nt/Tornado/host/x86-win32/bin/torVars (for example)
3. In a command prompt:
$ torVars
$ cd c:\Mesa
$ make -f Makefile.ugl CPU=PENTIUM
Take a long while...
5. Include all the files from ugldemos folder to build some downloadable
application modules
4. Download UGL/Mesa object files on target
For example via the WindShell:
ld < c:\Tornado\target\lib\objMesaGL.o
ld < c:\Tornado\target\lib\objMesaUGL.o
ld < c:\Tornado\target\lib\objMesaGLU.o
ld < c:\Tornado\target\lib\objGLUTshapes.o
ld < c:\Tornado\target\lib\objMesaOS.o
You can put the previous lines in a file and use:
< filename
6. Download the application modules.
7. In WindShell, run:
-> uglalldemos
During the show some messages will appear, it provides some useful
information on key management.
Coding
------
Sample Usage:
In addition to the usual ugl calls to initialize UGL, (may be find an
input driver), you must do the following to use the UGL/Mesa interface:
1. Call uglMesaCreateContext() to create a UGL/Mesa rendering context,
given the display format.
2. Call uglMesaMakeCurrent() to bind the UGL/Mesa buffers to an
UGL/Mesa Context and to make the context the current one.
3. Make gl* calls to render your graphics.
4. Use uglMesaSwapBuffers() when double buffering to swap front/back buffers.
5. Before the UGL is destroyed, call MesaDestroyContext().
6. Before exiting, call if required uglEventQDestroy and then
uglDeinitialize();
Limitations
-----------
I found the following limitations in my driver :
- Color Indexed management is only in 8 bits
- It's possible to mix UGL/OpenGL application with a software
double buffer
Modifications
------------
New files in Mesa:
- Makefile.ugl
- rules.windmlmesa
- docs/README.UGL
- include/GL/uglmesa.h
- si-glu/Makefile.ugl
- src/Makefile.ugl
- src/ugl/torGLUTShapesInit.c
- src/ugl/torMesaUGLInit.c
- src/ugl/ugl_api.c
- src/ugl/ugl_dd.c
- src/ugl/ugl_glutshapes.c
- src/ugl/ugl_line.c
- src/ugl/ugl_span.c
- src/ugl/ugl_tri.c
- src/ugl/uglmesaP.h
- ugldemos/*
Modified files in Tornado 2.0:
- c:\Tornado\host\x86-win32\bin\torVars.bat
rem Command line build environments
set WIND_HOST_TYPE=x86-win32
set WIND_BASE=C:\Tornado
set MESA_BASE=C:\Mesa
set PATH=%WIND_BASE%\host\%WIND_HOST_TYPE%\bin;%PATH%
- c:\Tornado\target\config\comps\VxWorks\01uglmesa.cdf
- c:\Tornado\target\h\GL\*
Todo
----
- GCC 2.96, ASM compilation
Thanks to:
----------
Precision Insight team for their great job around Mesa, XFree, and DRI.
Wind River Systems to take me as an intern.
Stephane Raimbault
<stephane.raimbault@windriver.com>
<stephane.raimbault@deesse.univ-lemans.fr>
July 24, 2001