355334fcd9
Major refactoring.
1. Rewrite the pixmap texture uploading and downloading functions.
Add some new functions for both the prepare/finish access and
the new performance feature dynamic texture uploading, which
could download and upload the current image to/from a private
texture/fbo. In the uploading or downloading phase, we need to
handle two things:
The first is the yInverted option, If it set, then we don't need
to flip y. If not set, if it is from a dynamic texture uploading
then we don't need to flip either if the current drawing process
will flip it latter. If it is from finish_access, then we must
flip the y axis.
The second thing is the alpha channel hanlding, if the pixmap's
format is something like x8a8r8g8, x1r5g5b5 which means it doesn't
has alpha channel, but it do has those extra bits. Then we need to
wire those bits to 1.
2. Add almost all the required picture format support.
This is not as trivial as it looks like. The previous implementation
only support GL_a8,GL_a8r8g8b8,GL_x8r8g8b8. All the other format,
we have to fallback to cpu. The reason why we can't simply add those
other color format is because the exists of picture. one drawable
pixmap may has one or even more container pictures. The drawable pixmap's
depth can't map to a specified color format, for example depth 16 can
mapped to r5g6b5, x1r5g5b5, a1r5g5b5, or even b5g6r5. So we can't get
get the color format just from the depth value. But the pixmap do not
has a pict_format element. We have to make a new one in the pixmap
private data structure. Reroute the CreatePicture to glamor_create_picture
and then store the picture's format to the pixmap's private structure.
This is not an ideal solution, as there may be more than one pictures
refer to the same pixmap. Then we will have trouble. There is an example
in glamor_composite_with_shader. The source and mask often share the
same pixmap, but use different picture format. Our current solution is to
combine those two different picture formats to one which will not lose any
data. Then change the source's format to this new format and then upload
the pixmap to texture once. It works. If we fail to find a matched new
format then we fallback.
There still is a potential problem, if two pictures refer to the same
pixmap, and one of them destroy the picture, but the other still remained
to be used latter. We don't handle that situation currently. To be fixed.
3. Dynamic texture uploading.
This is a performance feature. Although we don't like the client to hold
a pixmap data to shared memory and we can't accelerate it. And even worse,
we may need to fallback all the required pixmaps to cpu memory and then
process them on CPU. This feature is to mitigate this penalty. When the
target pixmap has a valid gl fbo attached to it. But the other pixmaps are
not. Then it will be more efficient to upload the other pixmaps to GPU and
then do the blitting or rendering on GPU than fallback all the pixmaps to CPU.
To enable this feature, I experienced a significant performance improvement
in the Game "Mines" :).
4. Debug facility.
Modify the debug output mechanism. Now add a new macro:
glamor_debug_output(_level_, _format_,...) to conditional output some messages
according to the environment variable GLAMOR_DEBUG. We have the following
levels currently.
exports GLAMOR_DEBUG to 3 will enable all the above messages.
5. Changes in pixmap private data structure.
Add some for the full color format supports and relate it to the pictures which
already described. Also Add the following new elements:
gl_fbo - to indicates whether this pixmap is on gpu only.
gl_tex - to indicates whether the tex is valid and is containing the pixmap's
image originally.
As we bring the dynamic pixmap uploading feature, so a cpu memory pixmap may
also has a valid fbo or tex attached to it. So we will have to use the above
new element to check it true type.
After this commit, we can pass the rendercheck testing for all the picture formats.
And is much much fater than fallback to cpu when doing rendercheck testing.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
||
|---|---|---|
| .. | ||
| man | ||
| .gitignore | ||
| Makefile.am | ||
| README | ||
| XF86dri.c | ||
| ephyr.c | ||
| ephyr.h | ||
| ephyr_draw.c | ||
| ephyr_glamor.c | ||
| ephyrdri.c | ||
| ephyrdri.h | ||
| ephyrdriext.c | ||
| ephyrdriext.h | ||
| ephyrglxext.c | ||
| ephyrglxext.h | ||
| ephyrhostglx.c | ||
| ephyrhostglx.h | ||
| ephyrhostproxy.c | ||
| ephyrhostproxy.h | ||
| ephyrhostvideo.c | ||
| ephyrhostvideo.h | ||
| ephyrinit.c | ||
| ephyrlog.h | ||
| ephyrproxyext.c | ||
| ephyrproxyext.h | ||
| ephyrvideo.c | ||
| hostx.c | ||
| hostx.h | ||
| os.c | ||
| xf86dri.h | ||
Xephyr README
=============
What Is It ?
============
Xephyr is a a kdrive server that outputs to a window on a pre-existing
'host' X display. Think Xnest but with support for modern extensions
like composite, damage and randr.
Unlike Xnest which is an X proxy, i.e. limited to the
capabilities of the host X server, Xephyr is a real X server which
uses the host X server window as "framebuffer" via fast SHM XImages.
It also has support for 'visually' debugging what the server is
painting.
How To Use
==========
You probably want to run like;
Xephyr :1 -ac -screen 800x600 &
Then set DISPLAY=:1 and run whatever X apps you like.
Use 'xrandr' to change to orientation/size.
There is a '-parent' switch which works just like Xnests ( for use
with things like matchbox-nest - http://matchbox.handhelds.org ).
There is also a '-host-cursor' switch to set 'cursor acceleration' -
The host's cursor is reused. This is only really there to aid
debugging by avoiding server paints for the cursor. Performance
improvement is negiable.
Send a SIGUSR1 to the server ( eg kill -USR1 `pidof Xephyr` ) to
toggle the debugging mode. In this mode red rectangles are painted to
screen areas getting painted before painting the actual content. The
delay between this can be altered by setting a XEPHYR_PAUSE env var to
a value in micro seconds.
Caveats
=======
- Depth is limited to being the same as the host.
*Update* As of 8/11/2004. Xephyr can now do 8bpp & 16bpp
on 24bpp host.
- Rotated displays are currently updated via full blits. This
is slower than a normal oprientated display. Debug mode will
therefor not be of much use rotated.
- The '-host-cursor' cursor is static in its appearence.
- The build gets a warning about 'nanosleep'. I think the various '-D'
build flags are causing this. I havn't figured as yet how to work
round it. It doesn't appear to break anything however.
- Keyboard handling is basic but works.
- Mouse button 5 probably wont work.
Matthew Allum <mallum@o-hand.com> 2004