Novell 闭门造车（XGL）？
XGL server几个链接大家自己看，图快的朋友可以直接看最后的几张图：
http://osnews.com/story.php?news_id=13063
http://osnews.com/story.php?news_id=13040
http://ubuntuforums.org/showthread.php?t=75527
http://osnews.com/story.php?news_id=13061
图：
http://www.cs.umu.se/~c99drn/xgl/xgl-shot1.png
http://www.cs.umu.se/~c99drn/xgl/xgl-shot2.png
http://www.cs.umu.se/~c99drn/xgl/xgl-shot3.png
btw, I'm jcome... :lol: http://mail.gnome.org/archives/metacity-devel-list/2005-December/thread.html 那个Cube只是个四面体，顶面和底面是空的。我亲眼见过这个Cube的演示，感觉和MacOS有一拼。 opengl的程序不会因为透明和阴影而出错了，这个是一个很大的进步啊
那个cube也没有啥吸引人的，严重的边界走样，至少要8xAA才能有比较好的效果吧
apple也一直在闭门造车 opengl的程序不会因为透明和阴影而出错了，这个是一个很大的进步啊
XGL 其实是两个 X server， 第二个 X server 运行在第一个 Server 里，然后全屏， 这样第二个 X server 的 opengl 和 Xv 输出都可以被重定向， 就可以保证透明和阴影不出错了。 opengl的程序不会因为透明和阴影而出错了，这个是一个很大的进步啊
XGL 其实是两个 X server， 第二个 X server 运行在第一个 Server 里，然后全屏， 这样第二个 X server 的 opengl 和 Xv 输出都可以被重定向， 就可以保证透明和阴影不出错了。
那会不会影响速度？？ 肯定会影响速度，不过X本来也就磨磨蹭蹭的，损失百分之几的速度也感觉不太出来
反正都是真正的opengl加速，换个好点卡就行了 :twisted: 现在的显卡都很强，加速个显示界面那我想总归是足够足够了。 很夸张！不过很值得期待！ 看看 david 的新年礼物。
Hey everyone,
my latest Xgl code is now available in a tarboll from here:
http://www.freedesktop.org/~davidr/
I'd like to get this code into freedesktop CVS asap. I suggest that we
put it in a xgl module for now as I'm guessing that it'll take some time
before everything can be merged into Xorg and I don't want to spend any
time merging the code back into the kdrive tree.
CHANGES
Compared to the xserver module code in freedesktop CVS a lot have
changed. The new code contains an uncounted number of bug fixes, some
major restructuring and a few additional features.
The restructuring was necessary for Xgl's GLX support to work on
anything but the proprietary nvidia driver. Basically there's now an Xgl
binary and the window system specific code is dynamically loaded.
E.g. when running on GLX, libglx.so and libglcore.so modules for GLX
support in Xgl are first loaded using RTLD_NOW and RTLD_LOCAL flags. Xgl
then loads the libxglx.so module using RTLD_GLOBAL flag (as dri drivers
need that). Symbols in libglx and libglcore must be resolved before the
libxglx module is loaded as we don't wont symbols in these modules to be
resolved to anything in the libxglx module or any library linked to
libxglx, hence the RTLD_NOW flag. RTLD_LOCAL flag as when later loading
libxglx no symbols should be resolved to values in libglx or libglcore.
XVideo extension is supported and it's using the YUV surface support in
CVS version of glitz (requires GL_ARB_fragment_program). Only scaling
and conversion of YV12 colorspace is accelerated so far but it's not
hard to add support for additional colorspaces. Thanks to Matthias Hopf
for much of the implementation.
The XVideo ddx implementation in Xgl is very minimal, basically what
I've done is to add internal picture formats for YUV data so other than
some common initialization code the Xgl XV code basically contains a
call to SetPictureTransform and CompositePicture. Software fall-backs
are handled by fb-layer. Right now, it works but is dead slow. My idea
is that we should add some highly optimized code-paths for this and
compositing of normal pictures would also benefit form the fast scaling.
Xgl can now accelerate compositing of gradient pictures.
The libxglx module (Xglx before) is more functional now. It includes XKB
and RANDR support. It even includes some Xorg server wrapper code so
that when running Xgl without an X server present it can launch an Xorg
server and run Xgl fullscreen on it.
COMPOSITING MANAGER AND DRI DRIVERS
With the right options passed to Xgl you can run xcompmgr fully
accelerated, however you'll need ati's or nvidia's proprietary driver
for that.
You should be using an OpenGL compositing manager as it can run fully
accelerated even on dri drivers. I've been working on an OpenGL
compositing manager named compiz but I'm not ready to release the code
for it yet. I'm aiming for a release at XDevConf in February.
The DRI drivers needs some tweaks for a GL compositing manager to
perform well on them. What's missing is fast CopyPixel from back buffer
to front buffer. The attached patch was all I did to get the r200 driver
working. There's probably a bunch of checks missing for that patch to be
complete but you get the idea, just adding a fast CopyPixel path for
this specific case to a DRI driver and it should be working quite well
with Xgl and a well written GL compositing manager.
GETTING IT INTO XORG
glx and glcore in Xgl's X server tree contains a lot of code that is
necessary for GLX support in Xgl. We might need to rework a few of these
things to get it all into the Xorg tree.
fb code in Xgl's X server tree contains a few bug fixes for negative
stride to work correctly, some gradient fixes and fbCompositeGeneral
improvements which I've sent patches for to the cairo list a few months
back. fb also contains code for fetching pixels from YUV pictures (used
for XVideo software fall-back).
Xgl also needs the glyph privates I've had in kdrive tree for some time.
Eric Anholt has already sent a patch for this to the Xorg list.
Everyone is welcome to help out with getting the code into Xorg.
TEXTURE FROM PIXMAP
The GLX_MESA_render_texture implementation in Xgl can be used by a GLX
client for binding a pixmap to a texture object but it will soon be
replaced by an implementation of GLX_EXT_texture_from_pixmap, which is
pretty much the same thing. Until then GLX_MESA_render_texture will be
supported and I've attached the two patches needed for support in mesa's
indirect rendering code.
Happy new year,
:twisted:
XGL 其实是两个 X server， 第二个 X server 运行在第一个 Server 里，然后全屏， 这样第二个 X server 的 opengl 和 Xv 输出都可以被重定向， 就可以保证透明和阴影不出错了。
编译到kaa.c时提示没有fontstruct.h,而fontsproto明明是安装的 现图来了；）
http://magiclinux.org/people/sunmoon1997/snapshots/Xgl-1.png sudo apt-get install xserver-xgl
mike@ubuntu:~$ Xglx
Fatal server error:
Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.
如果硬件上去了..好几个server都不是问题的吧...那能显示n维空间了 :mrgreen:
页:
[1]
2