Simon Toedt wrote:
>
> On Apr 11, 2005 4:34 PM, Brian Paul <[EMAIL PROTECTED]> wrote:
> > Simon Toedt wrote:
> > > Has anyone yet looked into ways to improve rendering performance? I
> > > have noticed that glXSwapBuffers() is slow (30secs +/-5secs on a
> > > P3/600Mhz) and mainly spends its time
Roland Mainz wrote:
[snip]
> > > The PsPutImage() function is an internal server function in the Xprint
> > > module. I have no idea why that would be getting called.
> >
> > I've just had a look at the code and did some modifications which
> > improve the
Brian Paul wrote:
[snip]
> > What about making MAX_WIDTH and MAX_HEIGHT runtime-configurable - would
> > that be possible (for stack allocations the Mesa code then has to depend
> > on |alloca()|) ?
>
> Probably do-able, but a lot of work.
Depends... if |alloca()| can safely be used on all platfo
Brian Paul wrote:
> >>>Ian Romanick wrote:
> >>>When I look at xc/extras/Mesa/src/mesa/main/config.h I see more items on
> >>>my wishlist: Would it be possible to increase |MAX_WIDTH| and
> >>>|MAX_HEIGHT| (and the matching texture limits of the software
> >>>rasterizer) to 8192 to support larger d
Brian Paul wrote:
> >>>On Apr 5, 2005 10:11 PM, Brian Paul <[EMAIL PROTECTED]> wrote:
> >>>Will increasing MAX_WIDTH/HEIGHT affect applications which run in
> >>>small windows or only those which use resolutions exceeding the 4Kx4K
> >>>limit?
> >>
> >>Increasing MAX_WIDTH/HEIGHT will result in mor
Ian Romanick wrote:
>
> For X.org 6.9 / 7.0 I would like to break the existing libGL / DRI
> driver interface. There is a *LOT* of crap hanging around in both libGL
> and in the DRI drivers that exists *only* to maintain backwards
> compatability with older versions of the interface. Since it's
Vladimir Dergachev wrote:
[snip]
> Interesting :) Could you try this with latest X.org source ?
>
> Also, what is gl-117 ?
OpenGL flight simulator.
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +
Jon Smirl wrote:
> > glxProxy effectively would put the GL rendering in its own thread. And
> > nothing necessarily prevents us from creating a new thread for in-server
> > DRI.
> >
> > If the rendering is properly encapsulated, then making it multicore-friendly
> > is cheap and easy; if libglx i
Felix Kühling wrote:
>
> Am Do, den 30.12.2004 schrieb Adam Jackson um 20:20:
> > The goal: Load DRI drivers from the server's libglx, rather than the
> > software-based libGLcore.
> >
> > Currently there are four server-side modules: dri, drm, glx, and GLcore.
> > There are also three client-side
Adam Jackson wrote:
> > I have a seventh option for you. Feel free to flame me if it sounds
> > stupid ...
> >
> > - Option 7: Run the GLX server as a separate process forked by the
> > Xserver. This way you get rid of the problem with the same library
> > linked into the same process multiple time
Alan Coopersmith wrote:
> >>>Why not help getting mesa-solo working so that we can move to X on top of
> >>>OpenGL?
> >>
> >>For one, in the two years that is going to take to bear fruit, we need a
> >>working X server. Two because mesa-solo isnt supported on most of
> >>the Xorg platforms.
> >
> >
11 matches
Mail list logo
