mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-10 19:00:13 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
fd266ec62c
Winsys context build a list of register block a register block is a set of consecutive register that will be emited together in the same pm4 packet (the various r600_block* are there to provide basic grouping that try to take advantage of states that are linked together) Some consecutive register are emited each in a different block, for instance the various cb[0-7]_base. At winsys context creation, the list of block is created & an index into the list of block. So to find into which block a register is in you simply use the register offset and lookup the block index. Block are grouped together into group which are the various pkt3 group of config, context, resource, Pipe state build a list of register each state want to modify, beside register value it also give a register mask so only subpart of a register can be updated by a given pipe state (the oring is in the winsys) There is no prebuild register list or define for each pipe state. Once pipe state are built they are bound to the winsys context. Each of this functions will go through the list of register and will find into which block each reg falls and will update the value of the block with proper masking (vs/ps resource/constant are specialized variant with somewhat limited capabilities). Each block modified by r600_context_pipe_state_set* is marked as dirty and we update a count of dwords needed to emit all dirty state so far. r600_context_pipe_state_set* should be call only when pipe context change some of the state (thus when pipe bind state or set state) Then to draw primitive you make a call to r600_context_draw void r600_context_draw(struct r600_context *ctx, struct r600_draw *draw) It will check if there is enough dwords in current cs buffer and if not will flush. Once there is enough room it will copy packet from dirty block and then add the draw packet3 to initiate the draw. The flush will send the current cs, reset the count of dwords to 0 and remark all states that are enabled as dirty and recompute the number of dwords needed to send the current context. Signed-off-by: Jerome Glisse <jglisse@redhat.com> |
||
|---|---|---|
| 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