On Thu, Jun 07, 2001 at 06:21:38PM -0400, Mike A. Harris wrote:
> Yep. I think any serious project out there works the same way
> also, at least all the Sourceforge projects do. With XFree86
> specifically I don't even know who all has CVS write priveledge.
> Do just the core developers have wri
On Thu, 7 Jun 2001, Brian Paul wrote:
>> >I'll read the agreement, but your statement about "applying" to join
>> >the development team gives me the impression that there is a secret
>> >magic ring. Just my observation.
>>
>> Well ok then, there is a secret ring. If you don't know the
>> magic
"Mike A. Harris" wrote:
>
> On Wed, 6 Jun 2001, Digital Z-Man wrote:
> >I'll read the agreement, but your statement about "applying" to join
> >the development team gives me the impression that there is a secret
> >magic ring. Just my observation.
>
> Well ok then, there is a secret ring. If
On Sun, 2006-06-25 at 19:57 +0400, Elie Morisse wrote:
> Nope, doesn't help :'(
> It still get corrupted after i commented out the 0x0140 stuff. I
> localized the nasty lines, though :
>
> ptr[0x01F8>>2] = 0x011A;
> ptr[0x01FC>>2] = 0x151557FF;
> ptr[0x01F8>
Mike A. Harris wrote:
> On Thu, 17 May 2001, Will Newton wrote:
>
>>> Unfortunately, until 4.x supports all the hardware, or at least
>>> the hardware that we consider important, we need to ship 3.3.6
>>> servers in addition to 4.x, and that has some really crummy side
>>> effects, like having t
On Tue, 2003-09-02 at 16:42, Mike A. Harris wrote:
> On Tue, 2 Sep 2003, Keith Whitwell wrote:
>
> >What is wrong right now is that we can't get uptodate versions of the
> >repository to non-developers.
> >
> >Non-developers currently don't have BK, arch, subversion or even cvsup
> >installed.
On Thu, May 09, 2002 at 11:00:51PM +0200, Frank Van Damme wrote:
> On Thursday 09 May 2002 10:12 pm, Mike A. Harris wrote:
>
> > Might not sound insane, but the bare fact is that it does not
> > work in XFree86. I could care less personally if it ever does,
> > as it is obsolete hardware. I onl
On Friday 10 May 2002 03:01 pm, Jules Bean wrote:
> If I run my desktop@1600x1200 on a voodoo 3 (which I am at the
> moment), but load a 3D game which switches the resolution down to
> something more sane like 800x600, will that game be able to use DRI
> then, at that reduced resolution? Or would
Frank Van Damme ([EMAIL PROTECTED]):
> On Friday 10 May 2002 03:01 pm, Jules Bean wrote:
> > If I run my desktop@1600x1200 on a voodoo 3 (which I am at the
> > moment), but load a 3D game which switches the resolution down to
> > something more sane like 800x600, will that game be able to use DRI
On Friday 10 May 2002 05:45 pm, Billy Biggs wrote:
> Unfortunately, in X you can't yet change the desktop resolution, only
> the visible resolution: the 2D desktop will still eat up all the video
> RAM. So while it might work in Windows, I don't think it will work in X
> until xrandr is done.
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch]- dispatcher files
APIspec file
gl*.py- Python API scripts
main/
Keith Whitwell wrote:
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch]- dispatcher files
APIspec file
gl*.py- Python API scripts
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
I think the DRI drivers should be moved into the dri/ directory
which itself should be in the drivers/ directory, because drivers/
contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc.
The dri/ direct
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
I think the DRI drivers should be moved into the dri/ directory
which itself should be in the drivers/ directory, because drivers/
contains the public APIs of Mesa, e.g. OSMesa, fxMesa e
Quoting Keith Whitwell ([EMAIL PROTECTED]):
> Brian Paul wrote:
> >>
> >>dri/- dri driver interface
> >>api/- public api
> >>common/- reusable driver code
> >>radeon/ - DRI driver
> >>r20
Quoting Brian Paul ([EMAIL PROTECTED]):
> Denis Oliver Kropp wrote:
>
> >>Also, I want to try to keep all source files as leaves in the tree.
> >>That is, a directory foo/ won't contain both files and subdirs; just
> >>one or the other.
> >
> >
> >What about this?
> >
> > dri/
Denis Oliver Kropp wrote:
Quoting Keith Whitwell ([EMAIL PROTECTED]):
Brian Paul wrote:
dri/- dri driver interface
api/- public api
common/- reusable driver code
radeon/ - DRI driver
r200/
Quoting Brian Paul ([EMAIL PROTECTED]):
> Denis Oliver Kropp wrote:
> >Quoting Keith Whitwell ([EMAIL PROTECTED]):
> >
> >>Brian Paul wrote:
> >>
> dri/- dri driver interface
> api/- public api
> common/- reusable driver
Quoting Denis Oliver Kropp ([EMAIL PROTECTED]):
> dri/common/ contains reusable code used by the DRI drivers
> while dri/common/api/ contains code to handle the drivers.
dri/api/, of course.
--
Best regards,
Denis Oliver Kropp
.--.
| DirectFB - Hardware
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
Quoting Keith Whitwell ([EMAIL PROTECTED]):
Brian Paul wrote:
dri/- dri driver interface
api/- public api
common/- reusable driver code
Right, but I want to build a libGL without MiniGLX, just with DRI.
Do you think it will be feasible for this new DRI interface to work with
drivers not based on Mesa? If so, the code should not be in the
src/mesa/ subtree.
I have to admit I'm lost now.
Keith
--
Keith Whitwell wrote:
Right, but I want to build a libGL without MiniGLX, just with DRI.
Do you think it will be feasible for this new DRI interface to work
with drivers not based on Mesa? If so, the code should not be in the
src/mesa/ subtree.
I have to admit I'm lost now.
Denis is proposi
On Wed, 4 Jun 2003, Brian Paul wrote:
>
> Denis is proposing a new public DRI-based API, presumably for
> fbdev-type environments. Suppose this API became popular and other
> parties wanted to implement drivers for it - drivers not based on
> Mesa. Is that conceivable? If so, this new inter
Quoting Linus Torvalds ([EMAIL PROTECTED]):
>
> On Wed, 4 Jun 2003, Brian Paul wrote:
> >
> > Denis is proposing a new public DRI-based API, presumably for
> > fbdev-type environments. Suppose this API became popular and other
> > parties wanted to implement drivers for it - drivers not based
Keith Whitwell wrote:
Hmm - I think that's a side issue to this reorg. Let's keep to code
that exists - I'm not sure that everyone's communicating acurately at
the moment.
I think that there will probably always be some small details about the
code that don't accurately map onto how the repos
Brian Paul wrote:
Keith Whitwell wrote:
Hmm - I think that's a side issue to this reorg. Let's keep to code
that exists - I'm not sure that everyone's communicating acurately at
the moment.
I think that there will probably always be some small details about
the code that don't accurately map
Keith Whitwell wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Hmm - I think that's a side issue to this reorg. Let's keep to code
that exists - I'm not sure that everyone's communicating acurately at
the moment.
I think that there will probably always be some small details about
the code tha
Brian Paul wrote:
Keith Whitwell wrote:
Right, but I want to build a libGL without MiniGLX, just with DRI.
Do you think it will be feasible for this new DRI interface to work
with drivers not based on Mesa? If so, the code should not be in the
src/mesa/ subtree.
I have to admit I'm lost
Denis Oliver Kropp wrote:
What do you mean by "drivers not based on Mesa"?
ATI, for example, has Linux OpenGL drivers that use the DRI but don't
use Mesa.
It seems to be common misconception that the DRI was designed around
Mesa, but it's not.
-Brian
Quoting Brian Paul ([EMAIL PROTECTED]):
> Denis Oliver Kropp wrote:
> >Quoting Brian Paul ([EMAIL PROTECTED]):
> >
> >>Denis Oliver Kropp wrote:
> >>
> >>>Quoting Keith Whitwell ([EMAIL PROTECTED]):
> >>>
> >>>
> Brian Paul wrote:
>
>
> >>dri/- dri driver interface
Brian Paul wrote:
Denis Oliver Kropp wrote:
What do you mean by "drivers not based on Mesa"?
ATI, for example, has Linux OpenGL drivers that use the DRI but don't
use Mesa.
It seems to be common misconception that the DRI was designed around
Mesa, but it's not.
Right, and the PowerVR driver a
Hi,
AFAIK there is not linux driver for X1600 (fglrx doesn't support this card
too). This card is nearly useless under linux for now.
Peter Zubaj
>
>John Clemens schrieb:
>>
>> There was a post on this list at the end of december(?) indicating that
>> ATI was not interested in helping open sour
Smitty wrote:
>>>I want to get started putting up the new site, but no-one has told me
>>>how to access the webspace...
>>>
>>>I've given my sourceforge details and been added to the project...
>>>
>>Ian,
>>
>>I can't help you with access details, but I'd like you to stage this
>>below the current
On Sun, 23 Jun 2002 22:52:09 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Smitty wrote:
> >>>I want to get started putting up the new site, but no-one has told me
> >>>how to access the webspace...
> >>>
> >>>I've given my sourceforge details and been added to the project...
> >>>
> >>Ian,
>
On Wed, Mar 19, 2003 at 09:31:41PM -0500, Mike A. Harris wrote:
> On Wed, 19 Mar 2003, Philip Brown wrote:
> >Even if the decision stands to no longer field new bugs there, it would
> >still be nice if someone cleaned out the bugs there that are no longer
> >relevant.
>
> Feel free.
that requires
Or, someone could just leave it as is, disable it and forget
about it because sourceforge's bug tracking system sucks. [1]
I don't think we ever found out how to disable it. Just another aspect of its
suckage - you can't turn it off.
Keiht
-
On Thu, Mar 20, 2003 at 08:14:33AM +, Keith Whitwell wrote:
>
> > Or, someone could just leave it as is, disable it and forget
> > about it because sourceforge's bug tracking system sucks. [1]
>
> I don't think we ever found out how to disable it. Just another aspect of its
> suckage - you
On Thu, 2003-03-20 at 09:31, Philip Brown wrote:
> On Thu, Mar 20, 2003 at 08:14:33AM +, Keith Whitwell wrote:
> >
> > > Or, someone could just leave it as is, disable it and forget
> > > about it because sourceforge's bug tracking system sucks. [1]
> >
> > I don't think we ever found out ho
On Thu, Mar 20, 2003 at 02:49:37PM +, Alan Cox wrote:
>...
> I guess they've been busy writing 3D drivers instead. If you know the
> SF system well then this kind of info could be a real help
I dont know it "well". I just poked around with it at admin-level for 10
minutes.
It would be a good
--snip---
>>
>> Maybe I should send it to Gareth with that beer I owe him. :)
>Excuse me, but WHAT's the problem here ??
>I'm using a Hauppauge TV card (BT878 based) together with the DRI and >it
>run PERFECTLY well !!!
>This is using the tdfx driver on a V5.
yeah, same goes for me, bt878 card
Dieter Nützel wrote:
>> > Are you sure that 3D hardware acceleration is working right?
>>
>> Appearently not.
>> It locked up once tring anothe benchmark,
>> and neither agpgart, not r128 modules
>> got loaded when I restarted:(
>
> Try to rmmod most of your modules and then modprobe agpgart an
On Thu, May 09, 2002 at 04:12:54PM -0400, Mike A. Harris wrote:
> On Thu, 9 May 2002, Michael wrote:
>
> >> >> High resolution video requires a lot of video memory. DRI
> >> >> requires approximately four TIMES that much video memory to work
> >> >> properly. However, people are using insane
On Thu, May 09, 2002 at 09:24:49AM -0600, Jens Owen wrote:
> Michael,
>
> I've included some inline feedback specific to your 3Dfx concerns...
Thanks, I shall have to see how far I can crank this monitor up to try
and reproduce it first and see what breaks.
> I agree. However, I understand wh
--- Felix Kühling <[EMAIL PROTECTED]> wrote:
> On the Savage IX it freezes now, when the 3D window gets too close to
> the bottom of the screen. There is an extra allocation of 128kb at
> the
> end of the frame buffer that is not included in RamNeedeFor3D. It
> doesn't seem to be used though.
>
>
On Sun, 21 Mar 2004 14:24:41 -0800 (PST)
Alex Deucher <[EMAIL PROTECTED]> wrote:
> --- Felix K_hling <[EMAIL PROTECTED]> wrote:
> > On the Savage IX it freezes now, when the 3D window gets too close to
> > the bottom of the screen. There is an extra allocation of 128kb at
> > the
> > end of the fr
On Wed, 17 Jul 2002, Leif Delgass wrote:
> On 17 Jul 2002, Michel Dänzer wrote:
>
> > On Tue, 2002-07-16 at 20:17, Leif Delgass wrote:
> > > On Tue, 16 Jul 2002, Keith Whitwell wrote:
> > >
> > > > > Well, it's not high on my list. I don't think flat-shading is used that
> > > > > often, and
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
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
On Fri, May 30, 2003 at 01:58:40PM +0200, Sven Luther wrote:
>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
"Mike A. Harris" wrote:
>
> >c) There are limited projects - cards are usually not supported because of
> >an nVidia-like situation or have a well known "guru" doing the coding. No
> >nice easy intros to coding drivers.
>
> The DESIGN document is pretty much a good start.
If one can get it. I
Digital Z-Man <[EMAIL PROTECTED]> writes:
> "Mike A. Harris" wrote:
>
> >
> > >c) There are limited projects - cards are usually not supported because of
> > >an nVidia-like situation or have a well known "guru" doing the coding. No
> > >nice easy intros to coding drivers.
> >
> > The DESIGN doc
On Wed, 6 Jun 2001, Andreas Ehliar wrote:
>> Perhaps, but it is a very very very minimal NDA. Definitely not
>> an evil NDA, or many people myself included wouldn't agree to it.
>
>Certainly, but you have to be "inside" to have any chance of
>getting this NDA. That is my impression at least. If
Finally I get some time to throw my 2 cents into this ... :)
First of all I would like to say it is a shame to see you go, Gareth. You've
done some really great work on this project and I think everybody appreciates
it a lot!! I hope you have a good time relaxing for a while and find a good
jo
"Mike A. Harris" wrote:
> On Tue, 5 Jun 2001, Digital Z-Man wrote:
>
>
> Well, you haven't looked very hard my friend. ;o)
>
> The design document is included in the XFree86 source code, and
> always has been.
>
> xc/programs/Xserver/hw/xfree86/doc/DESIGN
>
> In fairness to you though, it isn'
Digital Z-Man wrote:
>
> > There is a project on sourceforge to create a new X server from
> > scratch. "linuxgfx"
> >
> > While it is a cool idea, it will take 10 years to complete.
> > XFree86 wont be sitting idle for that time. It is easy to say
> > "scrap XFree86", and I agree that it is a
On Wed, 6 Jun 2001, Digital Z-Man wrote:
>> In fairness to you though, it isn't like someone would
>> accidentally stumble across it easily when it is buried 6 levels
>> deep.
>
>Maybe that should be relocated to a more visible spot, or a
>symlink to it in the rootdir? I guess you could 'find' i
Zilvinas Valinskas wrote:
>
> swoop@tweakster:~$ ./isosurf
> 7179 vertices, 7177 triangles
>
> :\ that's all I get :) Looks neat ...
Hit 'b' to run the benchmark. "Use the source, Luke..."
-- Gareth
___
Dri-devel mailing list
[EMAIL PROTECTED]
http
On Fri, 2002-05-24 at 19:54, Smitty wrote:
>
> 6) What is required in order to produce drivers for other architectures
> - If people tell me this, I will add it to the 'help us' section of the
> site.
Do you mean other architectures as in other OSs or as in other processor
architectures for an a
. Harris [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 24, 2002 08:31
> To: Marc Poulhiès
> Cc: [EMAIL PROTECTED]
> Subject: [Dri-devel] Re: Compilation
>
>
> On 23 Jun 2002, Marc Poulhiès wrote:
>
> >Date: 23 Jun 2002 22:28:14 +0200
> >From: Marc Poulhiès <
On Monday 24 June 2002 13:09, Alexander Stohr wrote:
> Or you are try out the current closed source drivers
> for X11 and the ATI FireGL 8700/8800 - they do run
> on the "BUILT BY ATI" Radeon 8500 boards as well.
> The board indicates this compatibility by a PCI
> Subvendor ID of 0x1002 or ATI.
H
Dieter Nützel wrote:
> On Monday 24 June 2002 13:09, Alexander Stohr wrote:
>
>>Or you are try out the current closed source drivers
>>for X11 and the ATI FireGL 8700/8800 - they do run
>>on the "BUILT BY ATI" Radeon 8500 boards as well.
>>The board indicates this compatibility by a PCI
>>Subvend
> Hello Alexander!
>
> No change to get this going on "your partner" boards?
> Even with flashed BIOS?
>
> I can get may hands on a 8500LE on top of my dual Athlon
> 1900+ MP/XP for
> testing.
>
> Thanks,
> Dieter
The partner boards do have individual board features
which aren't tested
Ian Romanick wrote:
Linus Torvalds wrote:
You _really_ want to use futex'es for any user-space locking. It's
back-ported to 2.4.x, and it gets these cases _right_. There are fair
user-space locks based on futexes as part of modern glibc sources, and
they are _fast_, since all non-contention (commo
On Sun, 6 Jul 2003, Ian Romanick wrote:
>
> The one catch that I see is that I don't see support for the futex ioctl
> in any 2.4 kernel. I did a 'grep -ri futex include/' in the source for
> 2.4.21-ac2 and for 2.5.69. The 2.4 kernel didn't have any hits, but the
> 2.5 kernel did. Of course, t
On Llu, 2003-07-07 at 07:44, Linus Torvalds wrote:
> I'm pretty sure that the futex code is backported at least into the redhat
> tree, since the new threading code really really wants it. But yes, it may
> not be in any "official" 2.4.x kernels, and I suspect it's only in the
> most recent RH t
Ian Romanick wrote:
Ian Romanick wrote:
Linus Torvalds wrote:
You _really_ want to use futex'es for any user-space locking. It's
back-ported to 2.4.x, and it gets these cases _right_. There are fair
user-space locks based on futexes as part of modern glibc sources, and
they are _fast_, since all
Ian Romanick wrote:
The real difference comes at the unlock. When a thread wants to release
the futex, it increments the variable. If the value is greater than
zero, the thread happily continues on. If the value is zero or
negative, the thread calls into the kernel to wake-up the next waiting
t
Jens Owen wrote:
Ian Romanick wrote:
The real difference comes at the unlock. When a thread wants to release
the futex, it increments the variable. If the value is greater than
zero, the thread happily continues on. If the value is zero or
negative, the thread calls into the kernel to wake-up t
On Sat, 11 Oct 2003 04:20:58 -0400 (EDT)
"Mike A. Harris" <[EMAIL PROTECTED]> wrote:
> On Fri, 10 Oct 2003, Felix [ISO-8859-1] Kühling wrote:
>
> >there were 2 reports from snapshot users on dri-users that DRI was
> >disabled with the new configuration stuff. In at least one case the
> >problem w
There is a difference in size between Intel and AMD with respect to allowed
mtrr ranges. I am not sure if you are seeing the same known bug.
Felix Kühling wrote:
> Am Mittwoch, den 26.01.2005, 17:23 +0200 schrieb [EMAIL PROTECTED]:
> > I compiled DRI CVS for Savage (X.org, Mesa and DRM stuff)
Alan Hourihane wrote:
I'm going to be merging the DRI cvs back into the XFree86 very soon.
Anyone have any furthur patches to the DRI cvs before I do this ?
I think I'll bring in my (minor) changes to the radeon kernel module from
the mesa-4.1 branch. This might save people from having to upgr
Brian Paul wrote:
Alan Hourihane wrote:
I'm going to be merging the DRI cvs back into the XFree86 very soon.
Anyone have any furthur patches to the DRI cvs before I do this ?
I think I'll bring in my (minor) changes to the radeon kernel module from
the mesa-4.1 branch. This might save peopl
On Mon, Oct 28, 2002 at 11:38:49AM -0700, Brian Paul wrote:
> Alan Hourihane wrote:
> > I'm going to be merging the DRI cvs back into the XFree86 very soon.
> >
> > Anyone have any furthur patches to the DRI cvs before I do this ?
>
> I think I'll bring in my (minor) changes to the radeon kernel
Ian Romanick wrote:
On Mon, Oct 28, 2002 at 11:38:49AM -0700, Brian Paul wrote:
Alan Hourihane wrote:
I'm going to be merging the DRI cvs back into the XFree86 very soon.
Anyone have any furthur patches to the DRI cvs before I do this ?
I think I'll bring in my (minor) changes to the radeon
Ian Romanick wrote:
Michel Dänzer wrote:
Hi Ian,
On Mit, 2003-01-22 at 00:33, Ian Romanick wrote:
When I've had spare cycles, I've been working on ARB_texture_cube_map
for the r100. It's almost working, but I think there something
subtle the I'm missing. :(
Do you have a patch for me to
ps to somewhat smoothly share the card & cpu -
otherwise you get very non-smooth interleaving or even starvation of
some of the graphics apps on 2.4.
Wouldn't a better sollution be to release the hardware lock then re-get
it? That should allow a blocked 3D process to get the lock and make
pr
w two graphics apps to somewhat smoothly share the card &
cpu - otherwise you get very non-smooth interleaving or even
starvation of some of the graphics apps on 2.4.
Wouldn't a better sollution be to release the hardware lock then re-get
it? That should allow a blocked 3D process t
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
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
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
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
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
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, 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
On Fri, Nov 20, 2009 at 11:29 PM, Jerome Glisse wrote:
> This patch series add ttm range validation function. Aim is to
> include this in 2.6.33 so i have time to iron out issue, comments.
I missed these first time around,
Thomas if you have any opinions on the TTM stuff please see if you
can ta
Dave Airlie wrote:
> On Fri, Nov 20, 2009 at 11:29 PM, Jerome Glisse wrote:
>
>> This patch series add ttm range validation function. Aim is to
>> include this in 2.6.33 so i have time to iron out issue, comments.
>>
>
> I missed these first time around,
>
> Thomas if you have any opinions
TECTED]
> >Content-Type: text/plain; charset=us-ascii; format=flowed
> >List-Id:
> >Subject: Re: Re: Radeon 8500, what's the plan?
> >
> >I have to disagree. If people are really concered about performance
> >they should be using Linux anyway.
>
> Th
On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote:
> With linux, it will say something along the lines of "works with Redhat
> 6.2". (take a look at many CAD packages, for example - they are _not_ very
> graphics intensive). Games are even trickier. I have not bought a single
> Loki game for this reason
> ** well, let's see how many flames I can generate with this.. **
I'll see if I can generate more.
>One point that I think has been missed is that while Open Source in
>general (and Linux, in particular) improves a lot user and developer
>experience, the binaries get even less value than in
On Wed, Oct 03, 2001 at 12:57:55AM +, David Johnson wrote:
|... I think a major problem for Linux is forward and
| backward compatibility issues and compatibility issues between
| distributions. ...
There are (at least) two issues here: Binary compatibility for
app
On Wed, Oct 03, 2001 at 12:57:55AM +, David Johnson wrote:
> Take a look at NVIDIA's linux driver website.
> http://www.nvidia.com/view.asp?PAGE=linux Is that confusing to a
> non-technical user or what? Is the average user going to know the
> difference between "Redhat 7.1 SMP Kernel" vs
>From: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>To: "David S. Miller" <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: [Dri-devel] Re: Re: Radeon 8500, what's the plan?
>Date: Tue, 2 Oct 2001 21:59:11 -0400 (EDT)
>But, you are right: I
On Wed, 3 Oct 2001, Damien Miller wrote:
> On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote:
>
> > With linux, it will say something along the lines of "works with Redhat
> > 6.2". (take a look at many CAD packages, for example - they are _not_ very
> > graphics intensive). Games are even trickier.
On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote:
> On the other hand, perhaps, I should give a try to writing a game engine
> myself.
I know of at least one open-source (LGPL) engine in development: Crystal
Space (http://crystal.linuxgames.com). It's a very ambitious project
which aims to be a compl
On Tue, 2 Oct 2001, Leif Delgass wrote:
> On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote:
>
> > On the other hand, perhaps, I should give a try to writing a game engine
> > myself.
>
> I know of at least one open-source (LGPL) engine in development: Crystal
> Space (http://crystal.linuxgames.com)
On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote:
>
>
> On Wed, 3 Oct 2001, Damien Miller wrote:
>
> > On Tue, 2 Oct 2001 [EMAIL PROTECTED] wrote:
> >
> > > With linux, it will say something along the lines of "works with Redhat
> > > 6.2". (take a look at many CAD packages, for example - they ar
On Tue, Oct 02, 2001 at 05:39:25PM -0400, [EMAIL PROTECTED] wrote:
> With linux, it will say something along the lines of "works with Redhat
> 6.2". (take a look at many CAD packages, for example - they are _not_ very
> graphics intensive). Games are even trickier. I have not bought a single
> Lok
Nathan Hand wrote:
> My alternative is of course to have a dedicated DOS-only box, just for
> games. I know perps who play the old Sierra adventures this way. So if
> people are willing to do this for DOS surely they're willing to have a
> Linux 2.2 system just for running Linux games? Not likely
Ok, ok, you persuaded me to be more open in this regard :) Though, still,
I would have preferred the source..
Vladimir Dergachev
On Fri, 5 Oct 2001, Nathan Hand wrote:
> On Tue, Oct 02, 2001 at 05:39:25PM -0400, [EMAIL PROTECTED] wrote:
> > With linux, it will say so
On Tue, Oct 02, 2001 at 03:40:18PM -0700, David S. Miller wrote:
>> Actually I think there is a "golden middle way" and ID actually showed it
>> too. Release binary games and when some time passes and they see no money
>> in engine licenses and maintaining the patches is too costly, release it
>>
1 - 100 of 17020 matches
Mail list logo
