blob: 7c938a6f9e1912532baa9b3d221c717d18d49488 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
### GLcore Extension
#### What is the GLcore extension?
The GLcore module takes care of rendering for indirect or non-local clients.
Currently, Mesa is used as a software renderer. In the future, indirect rendering will also be hardware accelerated.
#### Where does the GLcore extension reside?
The GLcore extension module usually resides at _/usr/X``11R6/lib/modules/extensions/libGLcore.a_.
The GLcore extension source code resides at [[xc/programs/Xserver/GL/mesa/src/|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/GL/mesa/src/]] .
#### If I run a GLX enabled OpenGL program on a remote system with the display set back to my machine, will the X server itself render the GLX requests through DRI?
The X server will render the requests but not through the DRI. The rendering will be software only. There are two possible solutions to this; either the X server can spawn a DRI client to handle the GLX protocol stream, or the X server can be a DRI client itself. Either method would effectively provide accelerated indirect rendering.
#### What's the real difference between local clients and remote clients?
There is no difference as far as the client is concerned. The only difference is speed.
The difference between direct and indirect rendering is that the former can't take place over the network. The DRI currently concentrates on the direct rendering case.
The application still gets a fully functional OpenGL implementation which is all that's required by the specification. The fact is that the implementation is entirely in software, but that's completely legal. In fact, all implementations fall back to software when they can't handle the request in hardware. It's just that in this case, the implementation can't handle anything in hardware.
Most people don't run GLX applications remotely, and/because most applications run very poorly when run remotely. It's not really the applications fault, OpenGL pushes around a lot of data.
Therefore there hasn't been a lot of interest in hardware accelerated remote rendering and there's plenty to do local rendering. It is on the TO``DO list but at a low priority.
One solution is actually fairly straight forward. When the X server gets a remote client, it forks off a small application that just reads GLX packets and then remakes the same OpenGL calls. This new application is then just a standard direct rendering client and the problem reduces to one already solved.
#### How would I go about adding support for hardware accelerated indirect rendering?
"The goal would be to modify the interface between libglx.a (the part that handles the high-level GLX protocol stuff) and libGLcore.a (the part that does the drawing) to be the same as the interface between libGL and the client-side DRI driver. Then a "client-side" DRI driver would be loaded instead of libGLcore.a."
* -- [[IanRomanick|IanRomanick]]
#### Is there a difference between using indirect DRI rendering (e.g., with LIBGL_ALWAYS_INDIRECT) and just linking against the Mesa library?
Yes. DRI _libGL_ used in in indirect mode sends GLX protocol messages to the X server which are executed by the GLcore renderer. Stand-alone Mesa's non-GLX. It effectively translates OpenGL calls into Xlib calls.
The GLcore renderer is based on Mesa. The GLcore renderer can not take advantage of hardware acceleration.
|
