headers
David Reveman | 2 Jan 2006 11:17
Picon
Favicon

Latest Xgl code

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Hellwig | 2 Jan 2006 17:28
Picon

Re: Latest Xgl code

On Mon, Jan 02, 2006 at 11:17:39AM +0100, David Reveman wrote:
> 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.

This sounds rather horrible.  Dave and Eric have done some nice work in
the public, so you as the person who refused to work in the public
should merged into that, after approval of the other developers.

> 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.

This sounds like a horrible layering violation.  Why do you need to add
such a horrible hack instead of writing a simple shell script?
Permalink | Reply | 0 comments |
headers
Martin Roos | 2 Jan 2006 18:13
Picon

mini mesa ?

Hello,
  I want to ask if there's any sort of minimalistic mesa implementation out there ? I'm 
currently stuck on a sis chipset laptop that has no dri support (the doomed 760 chipset). 
Therefor i can't have hardware acceleration and opengl is awfully slow. I've looked at 
some suggestions how to speed things up, but if i run someone else's compiled code that 
has lots of features turned on i have no chance to apply some of the most important ones.

  Is there some kind of crippled mesa fork out there that does very basic opengl rendering 
in software ? Or is there any kind of preload library that overloads the hardcore 
visuality effect calls that transparently disables the deeper wonders of opengl like dual 
lights etc. ?

  I'm willing to give back a lot of beauty just to get some things running over here :)

I've seen TiniGL that was programmed by a french programmer, but it's implementation is 
rather incomplete and doesn't even pass the very basic gl/glx calls. It can run glxgears 
but with weird results.

  If there are no implementations out there yet, do you have any suggestions ? I guess 
both, a lightweight mesa and a preloading "autodisabler" are quite possible but am not 
sure which one should be selected for implementation.

  Some autodisablements and cutbacks should be enough to run things, i see the opengl 
running much faster under windows with sis's native drivers.

Martin

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Reveman | 2 Jan 2006 18:40
Picon
Favicon

Re: Latest Xgl code

On Mon, 2006-01-02 at 17:28 +0100, Christoph Hellwig wrote:
> On Mon, Jan 02, 2006 at 11:17:39AM +0100, David Reveman wrote:
> > 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.
> 
> This sounds rather horrible.  Dave and Eric have done some nice work in
> the public, so you as the person who refused to work in the public
> should merged into that, after approval of the other developers.

As far as I can tell it seams that they've pretty much only done work on
the egl specific code which I haven't worked on so that's going to be
really easy to merge. Other than simple updates for tracking the changes
I've made to glitz most of the code that have gone into CVS recently is
just code from one of my old snapshots that I put in public_html on
freedesktop.org a long time ago.

If there's something else than the egl specific code in the CVS tree
that's working better than my latest code, then I'm all for doing the
work to get that merged but my understanding is that this isn't the
case. Correct me if I'm wrong.

> 
> > 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.
> 
> This sounds like a horrible layering violation.  Why do you need to add
> such a horrible hack instead of writing a simple shell script?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Airlie | 2 Jan 2006 23:50
Picon
Gravatar

Re: Latest Xgl code

On 1/3/06, David Reveman <davidr <at> novell.com> wrote:
> On Mon, 2006-01-02 at 17:28 +0100, Christoph Hellwig wrote:
> > On Mon, Jan 02, 2006 at 11:17:39AM +0100, David Reveman wrote:
> > > 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.
> >
> > This sounds rather horrible.  Dave and Eric have done some nice work in
> > the public, so you as the person who refused to work in the public
> > should merged into that, after approval of the other developers.
>
> As far as I can tell it seams that they've pretty much only done work on
> the egl specific code which I haven't worked on so that's going to be
> really easy to merge. Other than simple updates for tracking the changes
> I've made to glitz most of the code that have gone into CVS recently is
> just code from one of my old snapshots that I put in public_html on
> freedesktop.org a long time ago.
>
> If there's something else than the egl specific code in the CVS tree
> that's working better than my latest code, then I'm all for doing the
> work to get that merged but my understanding is that this isn't the
> case. Correct me if I'm wrong.
>

The main reason I'd like to merge your current tree back into kdrive
tree is for two reasons
1) we've got too many trees already,
2) merging into trees gives us a better idea when changes bust
something badly, I've already re-written the configure.ac to still
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Reveman | 3 Jan 2006 01:46
Picon
Favicon

Re: Latest Xgl code

On Tue, 2006-01-03 at 09:50 +1100, Dave Airlie wrote:
> On 1/3/06, David Reveman <davidr <at> novell.com> wrote:
> > On Mon, 2006-01-02 at 17:28 +0100, Christoph Hellwig wrote:
> > > On Mon, Jan 02, 2006 at 11:17:39AM +0100, David Reveman wrote:
> > > > 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.
> > >
> > > This sounds rather horrible.  Dave and Eric have done some nice work in
> > > the public, so you as the person who refused to work in the public
> > > should merged into that, after approval of the other developers.
> >
> > As far as I can tell it seams that they've pretty much only done work on
> > the egl specific code which I haven't worked on so that's going to be
> > really easy to merge. Other than simple updates for tracking the changes
> > I've made to glitz most of the code that have gone into CVS recently is
> > just code from one of my old snapshots that I put in public_html on
> > freedesktop.org a long time ago.
> >
> > If there's something else than the egl specific code in the CVS tree
> > that's working better than my latest code, then I'm all for doing the
> > work to get that merged but my understanding is that this isn't the
> > case. Correct me if I'm wrong.
> >
> 
> The main reason I'd like to merge your current tree back into kdrive
> tree is for two reasons
> 1) we've got too many trees already,
> 2) merging into trees gives us a better idea when changes bust
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Airlie | 3 Jan 2006 11:24
Picon
Gravatar

Re: Latest Xgl code

> >
> > The main reason I'd like to merge your current tree back into kdrive
> > tree is for two reasons
> > 1) we've got too many trees already,
> > 2) merging into trees gives us a better idea when changes bust
> > something badly, I've already re-written the configure.ac to still
> > allow kdrive to be useful...
>
> If most people like this better that's fine with me. I'll help out as
> much as I can.

Okay I've merged up your current tree to kdrive server, it should work
the same as the codedrop you've given out, except you'll need Mesa
CVS....

>
> I agree. I'll probably have a few updates in the next couple of days to
> the code drop I did today but I'll provide these as patches.

Well now you should be able to work the patches against the kdrive
tree, I've commited the fb/render changes that as individual patchsets
so as to make them easier for keithp/anholt (hint hint) to take a look
at :-)

If you can check the xserver tree operates like the tree you dropped
I'll try and make sure the Xegl works the same as I hoped it would....

Dave.
Permalink | Reply | 0 comments |
headers
Brian Paul | 4 Jan 2006 01:03

Re: mini mesa ?

Martin Roos wrote:
> Hello,
>  I want to ask if there's any sort of minimalistic mesa implementation 
> out there ? I'm currently stuck on a sis chipset laptop that has no dri 
> support (the doomed 760 chipset). Therefor i can't have hardware 
> acceleration and opengl is awfully slow. I've looked at some suggestions 
> how to speed things up, but if i run someone else's compiled code that 
> has lots of features turned on i have no chance to apply some of the 
> most important ones.
> 
>  Is there some kind of crippled mesa fork out there that does very basic 
> opengl rendering in software ? Or is there any kind of preload library 
> that overloads the hardcore visuality effect calls that transparently 
> disables the deeper wonders of opengl like dual lights etc. ?

We don't have anything like that.

>  I'm willing to give back a lot of beauty just to get some things 
> running over here :)
> 
> I've seen TiniGL that was programmed by a french programmer, but it's 
> implementation is rather incomplete and doesn't even pass the very basic 
> gl/glx calls. It can run glxgears but with weird results.
> 
>  If there are no implementations out there yet, do you have any 
> suggestions ? I guess both, a lightweight mesa and a preloading 
> "autodisabler" are quite possible but am not sure which one should be 
> selected for implementation.
> 
>  Some autodisablements and cutbacks should be enough to run things, i
(Continue reading)

Permalink | Reply | 6 comments |
headers
Michael Latiolais | 4 Jan 2006 05:30
Picon
Favicon

RADEON_CARD_AGP

I was compiling Mesa for use with egl, and I ran across a few issues. 
RADEON_CARD_AGP and a few other declarations were undeclared.I grepped 
the Mesa and xorg trees, and couldn't find them. Where are these 
declared? Thanks.

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Permalink | Reply | 2 comments |
headers
martin | 4 Jan 2006 06:45
Picon

Re: mini mesa ?

Thnx for enable.c hint :) Seems a rather long list of items in that swtich to dig through ...

I have some very newbish questions in my pocket, better i lay them out before i write one single 
line of code at all.

a) does mesa software rendering try to use the memory of the graphics chip ? the thing is, the sis 
chipset was invented by an "einstein", the graphics chip actually has to ask the cpu for memory 
since the memory controller is inside the cpu. so if i don't use the rendering capabilities of the 
gpu anyway i have no reason to make that memory trip there and back, i'd be much better off on a 
regular memory buffer and ignore the graphics card totally until i have the image ready to shoot at 
it.

b) does software rendering mesa use regular Xlib calls for drawing ? I just benchmarked my mplayer 
over here, the X11 driver and the XVideo driver do basically the same thing there, they shoot 
images into the screen one after another, but the xvideo driver performs twice as fast on 500x300 
images. if we could somehow render the image into the regular memory and then boost it to the 
screen via xvideo's XvPutImage or XvShmPutImage, it could be faster than it is right now ....

  Xvideo interface on my laptop has pretty good hardware scaling which probably also could be made 
use of.

has anybody attempted anything like this ?

are there any other systems out there that have xvideo acceleration but no dri drivers so mesa is 
slow as hell but could be possibly accelerated by xv hack ?

ps. just compared my laptop's xv tiny benchmark (pretty short C code, if you're interested just 
ask) to the one of my desktop with nvidia's geforce4 ...  laptop has twice the performance with 
XvShmPutImage ^^, i get around 900fps  <at>  320x240 and nearly 300fps  <at>  640x480 , just putting images 
as fast as the machine can into the video overlay ... somehow i feel that the Xlib interface isn't
(Continue reading)

Permalink | Reply | 5 comments |

Gmane