Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00E1_55A45D2A.A5554E10"
David S. Miller wrote:
>
> Even if this were not the case, stupid compilation tools are not an
> excuse to put changes into the C library. That is a fact.
We've been talking about two completely separate issues:
- Fast thread-local storage for libGL and GL drivers.
- PIC for libGL and GL
Jens Owen wrote:
>
> Keith Whitwell wrote:
> >
> > > > The private-backbuffer case really has
> > > > to be the backbuffer as treating the frontbuffer as private would break the
> > > > blitting technique that we use to keep the (real) backbuffer uptodate... To
> > > > have a private backbuffer
Keith Whitwell wrote:
>
> Jens Owen wrote:
> >
> > Keith Whitwell wrote:
> >
> > > - Separate out the 'flip' and 'swap' functions
> > > to separate ioctls. (D'oh)
> >
> > I'm glad you added the new IOCTL for backwards compatability with older
> > kernels. I haven't tested with
Keith Whitwell wrote:
>
> > > The private-backbuffer case really has
> > > to be the backbuffer as treating the frontbuffer as private would break the
> > > blitting technique that we use to keep the (real) backbuffer uptodate... To
> > > have a private backbuffer & ignore cliprects, it really d
Jens Owen wrote:
>
> Keith Whitwell wrote:
>
> > - Separate out the 'flip' and 'swap' functions
> > to separate ioctls. (D'oh)
>
> I'm glad you added the new IOCTL for backwards compatability with older
> kernels. I haven't tested with older kernels, but I trust you are
> ch
Keith Whitwell wrote:
> - Separate out the 'flip' and 'swap' functions
> to separate ioctls. (D'oh)
I'm glad you added the new IOCTL for backwards compatability with older
kernels. I haven't tested with older kernels, but I trust you are
checking for the latest version (just
From: Gareth Hughes <[EMAIL PROTECTED]>
Date: Tue, 21 May 2002 15:22:33 -0700
Using a feature that is "a very new thing" (to quote Jakub) -- only "GCC
3.2 (mainline CVS), the Red Hat GCC 3.1 package and gcc-2.96-RH >=
2.96-108" support this.
He showed two ways to do it. One
David S. Miller wrote:
>
> Why does it matter? Jakub has shown how to get the same kind of
> non-PIC relocations you want in the GL libraries by using private
> versions of symbols.
Using a feature that is "a very new thing" (to quote Jakub) -- only "GCC
3.2 (mainline CVS), the Red Hat GCC
> > The private-backbuffer case really has
> > to be the backbuffer as treating the frontbuffer as private would break the
> > blitting technique that we use to keep the (real) backbuffer uptodate... To
> > have a private backbuffer & ignore cliprects, it really does have to be the
> > backbuffe
From: Gareth Hughes <[EMAIL PROTECTED]>
Date: Tue, 21 May 2002 14:06:09 -0700
In the mean time, a few questions:
- Does __thread require -fPIC? From my initial reading of the PDF
document on your website, I was under the impression that this was
the case.
Keith Whitwell wrote:
>
> >
> > KW> The good news is there's no real cost to switching between
> > KW> mechanisms,
> >
> > Isn't there an overhead when going into page flipping mode in that the
> > server has to duplicate the contents of the front buffer into the both
> > buffers?
>
> I really m
>
> KW> The good news is there's no real cost to switching between
> KW> mechanisms,
>
> Isn't there an overhead when going into page flipping mode in that the
> server has to duplicate the contents of the front buffer into the both
> buffers?
I really meant falling back from pageflipping to s
Keith Whitwell wrote:
>
> Jens Owen wrote:
> >
> > Keith Whitwell wrote:
> > >
> > > Jens Owen wrote:
> > > >
> > > > Keith Whitwell wrote:
> > > > >
> > > > > Michael wrote:
> > > > > >
> > > > > > On Tue, May 21, 2002 at 12:14:45AM +0100, Keith Whitwell wrote:
> > > > > > > I have a .XF86config
Sorry for the delay in getting back to you, I've been offline since late
last week moving into a new building at work.
I've been working on some sample code that clearly demonstrates the
issues we (as in vendors of OpenGL on Linux) face. I'm hoping to have
that wrapped up this afternoon and w
Al Tobey wrote:
>
> I read some of the stuff about "Longhorn" (it's cheese!) - looks like M$
> wants to do make all 2d operations into texture operations in 3d mode.
> No more 2d/3d mode switching issues.
> http://www.tomshardware.com/business/02q2/020417/winhec11-05.html
>
> My thought is that
Jens Owen wrote:
>
> Keith Whitwell wrote:
> >
> > Jens Owen wrote:
> > >
> > > Keith Whitwell wrote:
> > > >
> > > > Michael wrote:
> > > > >
> > > > > On Tue, May 21, 2002 at 12:14:45AM +0100, Keith Whitwell wrote:
> > > > > > I have a .XF86config-radeon that sets ModulesPath to that directory,
I read some of the stuff about "Longhorn" (it's cheese!) - looks like M$
wants to do make all 2d operations into texture operations in 3d mode.
No more 2d/3d mode switching issues.
http://www.tomshardware.com/business/02q2/020417/winhec11-05.html
My thought is that X could do this without distur
Patch against the trunk is at
http://penguinppc.org/~daenzer/DRI/radeon-ppc.diff
Requests for comments before I commit:
- I got bitten by the ASSERT in extras/Mesa/src/tnl_dd/t_dd_vbtmp.h when
I had debugging enabled there, but is this the correct fix?
- The fprintf in lib/GL/mesa/src/drv/ra
Keith Whitwell wrote:
>
> Jens Owen wrote:
> >
> > Keith Whitwell wrote:
> > >
> > > Michael wrote:
> > > >
> > > > On Tue, May 21, 2002 at 12:14:45AM +0100, Keith Whitwell wrote:
> > > > > I have a .XF86config-radeon that sets ModulesPath to that directory, and
>maybe
> > > > > I need to set an
I have tried out the recent branch of DRI and found out that the
textures looks great! So does the open-GL for some apps that aren´t as
demanding on the hardware (doom, hexen etc). Quake 2 hogs all cpu and
locks the xserver (at least i think the x-server locks because i can´t
kill it). I still
Mike Mestnik wrote:
>
> --- Michael <[EMAIL PROTECTED]> wrote:
> > Can we repair the damage? That doesn't seem to have been that successful
> > in the past in terms of recovery / carrying on running the 3d app -
> > others have more knowledge here. If anything, cleanly exiting from 3d
> > and, i
Jens Owen wrote:
>
> Keith Whitwell wrote:
> >
> > Michael wrote:
> > >
> > > On Tue, May 21, 2002 at 12:14:45AM +0100, Keith Whitwell wrote:
> > > > I have a .XF86config-radeon that sets ModulesPath to that directory, and maybe
> > > > I need to set an env var or two... I guess the magic is add
Jens Owen wrote:
>
> Keith Whitwell wrote:
> >
> > Michael wrote:
> > >
> > > On Tue, May 21, 2002 at 12:14:45AM +0100, Keith Whitwell wrote:
> > > > I have a .XF86config-radeon that sets ModulesPath to that directory, and maybe
> > > > I need to set an env var or two... I guess the magic is add
Keith Whitwell wrote:
>
> Michael wrote:
> >
> > On Tue, May 21, 2002 at 12:14:45AM +0100, Keith Whitwell wrote:
> > > I have a .XF86config-radeon that sets ModulesPath to that directory, and maybe
> > > I need to set an env var or two... I guess the magic is adding up.
> >
> > Yeah, I should ha
Michael wrote:
>
> On Tue, May 21, 2002 at 12:14:45AM +0100, Keith Whitwell wrote:
> > I have a .XF86config-radeon that sets ModulesPath to that directory, and maybe
> > I need to set an env var or two... I guess the magic is adding up.
>
> Yeah, I should have rtfm'd, ModulesPath into .../expor
The ATI Fire GL 4 is based on the IBM GXT chip series.
To all my knowledge IBM produced that high performance
grafics chip for their AIX based server and workstation
machines with IBM board design. Further there is the
FireGL board (the responsible high end group that is now
at ATI and was forme
Hi i was just wondering about the state of driver for the ATI GL4 on linux.
Ati have released driver for this and i was just wondering if anyone has
used this cards with the ati drivers. Or is there open source driver
avaible that is up to the task of running maya?.
Any sugestions welcome.
Nils
28 matches
Mail list logo
