On Fri, 30 May 2003, Keith Whitwell wrote:
> Adam K Kirchhoff wrote:
> > For the past 24 hours, I've been having build problems with the cvs trunk:
> >
> > make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/common'
> > cleaning in lib/GL/mesa/src/drv/r200...
> > make[5]: Entering d
*Warning - your PC is vulnerable to Messenger Spam*
Ever have a window pop up on your screen, offering to sell you some garbage you don't need? This is a cruel invasion of your privacy and should not be allowed to continue. Here are some facts about unsolicited Messenger advertising:
- ISPs and
Adam K Kirchhoff wrote:
For the past 24 hours, I've been having build problems with the cvs trunk:
make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/common'
cleaning in lib/GL/mesa/src/drv/r200...
make[5]: Entering directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200'
Makefile:8:
For the past 24 hours, I've been having build problems with the cvs trunk:
make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/common'
cleaning in lib/GL/mesa/src/drv/r200...
make[5]: Entering directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200'
Makefile:8: *** missing separator.
On Thu, May 29, 2003 at 11:53:32AM -0400, David Dawes wrote:
> On Thu, May 29, 2003 at 07:34:28AM +0200, Sven Luther wrote:
> >On Thu, May 29, 2003 at 12:00:22AM -0400, Mike A. Harris wrote:
> >> On Wed, 28 May 2003, Sven Luther wrote:
> >>
> >> >> > I was being sarcastic, his message was encoded
[This e-mail has been automatically generated.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugs.xfree86.org/) that require
attention.
All of these bugs are in the NEW state, and have not been touched
in 7 days or more. You need to take a look at th
Title: New Page 1
On Fri, May 30, 2003 at 12:49:57AM -0500, John Sheu wrote:
> Two questions...
>
> 1.Are the wrapped binary driver packages ever coming back?
Appearently there is a problem while building them, because they are
back for some time. I'm going to look into it.
> 2.It seems with an old one I
On Thu, May 29, 2003 at 10:52:15PM -0700, Linus Torvalds wrote:
>
> On Thu, 29 May 2003, Ian Romanick wrote:
> >
> > You're right. We do _really_ want to use futex'es. However, I don't
> > think they're available on *BSD or Solaris.
>
> ...
> And once you have a nice wrapper and they look lik
Quoting Linus Torvalds ([EMAIL PROTECTED]):
>
> On Fri, 30 May 2003, Denis Oliver Kropp wrote:
> >
> > In the kernel part of Fusion (our IPC API) I'm currently calling yield()
> > after unlocking a "long-time" lock. Maybe you have some hints before I'm
> > working on that issue.
>
> You really s
On Thu, 29 May 2003, Ian Romanick wrote:
>
> You're right. We do _really_ want to use futex'es. However, I don't
> think they're available on *BSD or Solaris.
No. But you don't want to use them directly anyway, they're at the wrong
level. I haven't checked what glibc does, but I bet it has a
Two questions...
1. Are the wrapped binary driver packages ever coming back?
2. It seems with an old one I got (binary driver packages) it was missing the
libGL's so that once installed, (for example) glxinfo segfaults as it tries
to load old libGL's. An oversight or purposeful omissi
Linus Torvalds wrote:
On Fri, 30 May 2003, Denis Oliver Kropp wrote:
In the kernel part of Fusion (our IPC API) I'm currently calling yield()
after unlocking a "long-time" lock. Maybe you have some hints before I'm
working on that issue.
You really shouldn't unconditionally yield. That just tell
I copied together (from r200 driver)
a patch which enables GL_NV_texture_rectangle
on radeon.
The yuvrect.c test from mesa seems to work,
but texrect.c doesnt. strange.
Other issues:
1) radeonEmitBlit uses an already shifted
color_fmt, which is defined in radeon_reg.h,
r200EmitBlit uses an unshifte
wmfacm2zpf63pcguh13x8wab1
Stop
Mailings Here
ffk0j21cvznp0mj0y3nfsnd72
On Fri, 30 May 2003, Denis Oliver Kropp wrote:
>
> In the kernel part of Fusion (our IPC API) I'm currently calling yield()
> after unlocking a "long-time" lock. Maybe you have some hints before I'm
> working on that issue.
You really shouldn't unconditionally yield. That just tells the kernel
*Warning - your PC is vulnerable to Messenger Spam*
Ever have a window pop up on your screen, offering to sell you some garbage you don't need? This is a cruel invasion of your privacy and should not be allowed to continue. Here are some facts about unsolicited Messenger advertising:
- ISPs and
Quoting Linus Torvalds ([EMAIL PROTECTED]):
>
> On Thu, 29 May 2003, Keith Whitwell wrote:
> >
> > The lock doesn't seem to be 'fair' like that - in practise it isn't transfered
> > to the waiting process (unless you do a sched_yield() after unlocking).
>
> Indeed. If you want fairness, you nee
[This e-mail has been automatically generated.]
Please do not reply to this email. if you want to comment on the bug, go to the
URL shown below and enter your comments there.
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=108
[EMAIL PROTECTED] changed:
What
On Thu, 29 May 2003, Keith Whitwell wrote:
>
> The lock doesn't seem to be 'fair' like that - in practise it isn't transfered
> to the waiting process (unless you do a sched_yield() after unlocking).
Indeed. If you want fairness, you need to code for it explicitly. It's not
hard per se, but it
Ian Romanick wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
The bottom line is that with a 2.5 kernel, sched_yield() will discard
the time slice of the process, so misuse of it will cause bad
performance.
I guess it's possible that this could be a problem. The yield is
there to allow two g
Leif Delgass wrote:
On Thu, 29 May 2003, Ian Romanick wrote:
Ian Romanick wrote:
Ian Romanick wrote:
Log message:
Fixed the various supported texture wrap modes. Added a fallback for
unsupportable combinations of S/T wrap modes.
All of the exported modes on Radeon, R200, and MGA should be
On Thu, 29 May 2003, Ian Romanick wrote:
> Ian Romanick wrote:
> > Ian Romanick wrote:
> >
> >> Log message:
> >> Fixed the various supported texture wrap modes. Added a fallback for
> >> unsupportable combinations of S/T wrap modes.
> >
> >
> > All of the exported modes on Radeon, R200, a
Ian Romanick wrote:
Ian Romanick wrote:
Log message:
Fixed the various supported texture wrap modes. Added a fallback for
unsupportable combinations of S/T wrap modes.
All of the exported modes on Radeon, R200, and MGA should be correct
now. I'm going to try and look at i830 this week. C
On Thu, May 29, 2003 at 07:34:28AM +0200, Sven Luther wrote:
>On Thu, May 29, 2003 at 12:00:22AM -0400, Mike A. Harris wrote:
>> On Wed, 28 May 2003, Sven Luther wrote:
>>
>> >> > I was being sarcastic, his message was encoded with koi8-r, which, along
>> >> > with being html, is one of the indesc
25 matches
Mail list logo
