On Fri, Feb 28, 2003 at 10:29:04PM -0800, Ian Romanick wrote:
> Daniel Vogel wrote:
> > Does DRI have a future with neither NVIDIA nor ATI participating?
> > Are people actually talking to them about why they don't use it and
> > what has to be done to remedy this fact? Shouldn't this be a top prio
Daniel Vogel wrote:
Does DRI have a future with neither NVIDIA nor ATI participating?
Are people actually talking to them about why they don't use it and
what has to be done to remedy this fact? Shouldn't this be a top priority?
To clarify: I meant what has to be done to make DRI (direct rendering
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring available configuration options in
libGL. I had a look at xc/lib/GL/dri and it looks as if d
Ct0I6f
On Fri, 28 Feb 2003 14:57:35 -0800
Philip Brown <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 28, 2003 at 05:15:58PM -0500, Daniel Vogel wrote:
> >
> > So, are there technical reasons for NVIDIA not to use the DRI if ATI does?
> >
>
> yes.
>
> NVIDIA already has their own cross-platform low level d
Title: AD 3
IT'S NEVER BEEN EASIER TO ORDER YOUR PRESCRIPTIONS ONLINE
We are the largest U.S. Company specializing in Prescriptions for VIAGRA & other FDA approved medications.
Order from the comfort of your own home
** Free
--- "Mike A. Harris" <[EMAIL PROTECTED]> wrote:
> >> I don't see 100 unpaid hackers hacking feverishly
Since you have the specs, tell me how to reset a
Rage128 from protected mode so that I can add it to
the framebuffer driver.
I know about going into real mode and calling C000:3.
This can't be d
On Fri, 28 Feb 2003 15:56:41 -0500 (EST)
"Mike A. Harris" <[EMAIL PROTECTED]> wrote:
>
> I don't see 100 unpaid hackers hacking feverishly on anything X
> related right now. Why would 100 unpaid hackers come out of the
> woodwork all of a sudden? Quite unrealistic.
If you stood a chance in h
On Fre, 2003-02-28 at 21:51, AnonimoVeneziano wrote:
> Hi all, I want to know where I can fine The texmem trunk of DRI,
> possibly in debian packages. And if there aren't debian packages the
> other ways ;-) .
I'm not aware of any Debian packages of the texmem branch, I spend quite
some time ma
As Mike implied, NV doesn't do the DRI precisely BECAUSE
fragmentation isn't good. Their primary interest is a
single <> code base for <>
and not a single unfragmented framework for 3D accelerated
XFree86!!
Mike
Mike A. Harris wrote:
On Fri, 28 Feb 2003, Daniel Vogel wrote:
Fragmention still is
On Fri, 28 Feb 2003, Daniel Vogel wrote:
>Fragmention still isn't good, which brings me back to my
>original question whether folks are talking to NVIDIA why they
>aren't using the DRI framework.
I'm sure if Nvidia wanted to use DRI they would do so. What
benefit would there be to Nvidia really
> NVidia wanted to keep the source code base of the Windows drivers and the
> Linux drivers as close as possible, including what would be considered
> kernel mode stuff. They started with windows drivers and adapted that to
> linux. Part of their porting effort was bulding a kernel level wrapper,
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring available configuration options in
libGL. I had a look at xc/lib/GL/dri and it looks as if d
On Fre, 2003-02-28 at 19:03, Jon Smirl wrote:
> It is a fact that Microsoft Longhorn and the Mac GUI
> are moving towards 3D hardware for their base GUI. It
> is also a fact that it will take a lot of effort and
> probably several years to move X in the same
> direction. Personally I don't want to
NVidia wanted to keep the source code base of the Windows drivers and the
Linux drivers as close as possible, including what would be considered
kernel mode stuff. They started with windows drivers and adapted that to
linux. Part of their porting effort was bulding a kernel level wrapper,
which
On Fri, Feb 28, 2003 at 05:33:29PM -0500, Daniel Vogel wrote:
> Fragmention still isn't good, which brings me back to my original question
> whether folks are talking to NVIDIA why they aren't using the DRI framework.
Probably because of theirs UDA? I suspect it is easear to support 'more'
common
On Fri, 28 Feb 2003, Jon Smirl wrote:
>> I don't see 100 unpaid hackers hacking feverishly on
>> anything X
>
>Obviously you wouldn't see 100 people working full
>time
Obviously. Not even part time. I doubt you'd see more than
20-30 people "working" on it at all. And by that I mean making
a
On Fri, Feb 28, 2003 at 05:15:58PM -0500, Daniel Vogel wrote:
>
> So, are there technical reasons for NVIDIA not to use the DRI if ATI does?
>
yes.
NVIDIA already has their own cross-platform low level driver, with a
cross-platform 3d API. It's their "UDI", Unified Driver Interface,
or somethin
On Fre, 2003-02-28 at 23:11, Philip Brown wrote:
> On Fri, Feb 28, 2003 at 05:06:15PM +0100, Michel Dänzer wrote:
> > > I haven't look at this but if the DRM modules know
> > > about setting up the hardware and changing resolutions
> > > then there may be no need for framebuffer any more.
> > > You
> Well... for starters ATI *is* using the DRI infrastructure.
> Does that mean that you think DRI is doomed to success now?
I guess it means that it's at least not fundamentaly flawed ;-)
Fragmention still isn't good, which brings me back to my original question
whether folks are talking to N
On Fri, 28 Feb 2003, Daniel Vogel wrote:
>> Does DRI have a future with neither NVIDIA nor ATI participating?
>> Are people actually talking to them about why they don't use it and
>> what has to be done to remedy this fact? Shouldn't this be a top priority?
>
>To clarify: I meant what has to be d
Now that XFree86 4.3.0 is tagged/released, is there a plan for merging
4.3.0 into the DRI trunk?
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
__
> > My point was/is that without NVIDIA or ATI using the DRI
> > infrastructure it is doomed to fail.
>
> Uhmmm... ATI *does* use the DRI infrastructure for their drivers.
Googled for it a while but couldn't find any hints that they do so I assumed
they don't. Thanks for the clarification.
So, a
On Fri, Feb 28, 2003 at 05:06:15PM +0100, Michel Dänzer wrote:
> > I haven't look at this but if the DRM modules know
> > about setting up the hardware and changing resolutions
> > then there may be no need for framebuffer any more.
> > You could write a generic framebuffer driver that was
> > impl
On Fri, Feb 28, 2003 at 09:45:26PM +, José Fonseca wrote:
>
> Even if DRI stops being the main source of 3D drivers for Linux/BSD, it
> will remain to be the main source of _open_source_ 3D drivers. That,
> alone, gives DRI a competitive advantage over any other solution. Just
> in the same wa
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring available configuration options in
libGL. I had a look at xc/lib/GL/dri and it looks as if dri_glx.[ch]
would be
On Fri, 28 Feb 2003, Daniel Vogel wrote:
> > Does DRI have a future with neither NVIDIA nor ATI participating?
> > Are people actually talking to them about why they don't use it and
> > what has to be done to remedy this fact? Shouldn't this be a top priority?
>
> To clarify: I meant what has to
On Fri, Feb 28, 2003 at 03:00:03PM -0500, Daniel Vogel wrote:
> > So what is the best design for achieving this? The
> > project has to have DRI at it's core since it's the
> > only choice for 3D acceleration on Linux.
>
> Ironically, the only real choice for 3D acceleration on Linux is using
> NV
> Does DRI have a future with neither NVIDIA nor ATI participating?
> Are people actually talking to them about why they don't use it and
> what has to be done to remedy this fact? Shouldn't this be a top priority?
To clarify: I meant what has to be done to make DRI (direct rendering
*infrastructu
On Fri, 28 Feb 2003 10:03:10 -0800 (PST)
Jon Smirl <[EMAIL PROTECTED]> wrote:
> It is a fact that Microsoft Longhorn and the Mac GUI
> are moving towards 3D hardware for their base GUI. It
> is also a fact that it will take a lot of effort and
> probably several years to move X in the same
> direc
--- "Mike A. Harris" <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Feb 2003, Jon Smirl wrote:
>
> I don't see 100 unpaid hackers hacking feverishly on
> anything X
Obviously you wouldn't see 100 people working full
time but you might get detailed bug reports or patches
from 100 people. I know I get pa
Jon Smirl wrote:
>
> I really don't understand ATI's position on Linux
> drivers. They have better hardware but they are losing
> because of their drivers. I can't think of a better
> solution than having a couple hundred highly skilled,
> performance obsessed, unpaid hackers fixing their code
> fo
Hi all, I want to know where I can fine The texmem trunk of DRI,
possibly in debian packages. And if there aren't debian packages the
other ways ;-) .
Anyone can tell me the known bugs that actually these drivers have?
Thanks
Bye
---
This
On Fri, 28 Feb 2003, Jon Smirl wrote:
>> Does DRI have a future with neither NVIDIA nor ATI
>> participating?
>
>I really don't understand ATI's position on Linux
>drivers. They have better hardware but they are losing
>because of their drivers. I can't think of a better
>solution than having a c
--- Daniel Vogel <[EMAIL PROTECTED]> wrote:
> Does DRI have a future with neither NVIDIA nor ATI
> participating?
I really don't understand ATI's position on Linux
drivers. They have better hardware but they are losing
because of their drivers. I can't think of a better
solution than having a cou
> So what is the best design for achieving this? The
> project has to have DRI at it's core since it's the
> only choice for 3D acceleration on Linux.
Ironically, the only real choice for 3D acceleration on Linux is using
NVIDIA and ATI's (non DRI) binary drivers.
Does DRI have a future with neit
It is a fact that Microsoft Longhorn and the Mac GUI
are moving towards 3D hardware for their base GUI. It
is also a fact that it will take a lot of effort and
probably several years to move X in the same
direction. Personally I don't want to see Linux in the
position of having the new 3D effects i
On Fri, Feb 28, 2003 at 03:29:51PM +0100, Michel Dänzer wrote:
> On Fre, 2003-02-28 at 10:11, Felix Kühling wrote:
> >
> > I think this discussion is getting off track. We have to make clear what
> > we are talking about here. From the first mail on this subject I got the
> > impression, the goal
Dear Homeowner,
Interest Rates are at their lowest point in 40 years! We help you find the
best rate for your situation by matching your needs with hundreds of
lenders!
Home Improvement, Refinance, Second Mortgage,
Home Equity Loans, and much, much more!
You're eligible even with less than perfe
On Fri, Feb 28, 2003 at 09:25:56AM +0100, Sven Luther wrote:
| On Thu, Feb 27, 2003 at 02:01:22PM -0800, Jon Smirl wrote:
| > ... Moore's law
| > means that everyone is going to have super 3D hardware
| > in a couple of years.
|
| Even Embeded or handheld sys
On Fri, Feb 28, 2003 at 03:04:08PM +, Ian Molton wrote:
| On Thu, 27 Feb 2003 18:17:33 -0800
| Allen Akin <[EMAIL PROTECTED]> wrote:
|
| >
| > Then there are the arguments for deeper color channels based on the
| > need for higher-precision intermediate results -- for transparency,
|
On Fre, 2003-02-28 at 17:02, Jon Smirl wrote:
> --- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > > It would be simple to lift the mode setting and
> > > hardware identification code out of the fb drivers
> >
> >
> > But what would be the advantage over leaving it as a
> > framebuffer device
>
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > It would be simple to lift the mode setting and
> > hardware identification code out of the fb drivers
>
>
> But what would be the advantage over leaving it as a
> framebuffer device
> or whatever in the first place?
>
The X philosophy is to sh
On Thu, 27 Feb 2003 17:20:19 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> 64-bpp or 128-bpp isn't useful for display, but
> is useful.
Since you're talking intermediate, yes, agreed.
---
This sf.net email is sponsored by:ThinkGeek
Welcome
On Thu, 27 Feb 2003 18:17:33 -0800
Allen Akin <[EMAIL PROTECTED]> wrote:
>
> Then there are the arguments for deeper color channels based on the
> need for higher-precision intermediate results -- for transparency,
> antialiasing, multipass rendering, etc.
It's me Jennifer, I just wanted to send you that pic you asked for the other
day. Click
Here to catch me on my webcam & see more pics of me.
- xoxo Jennifer
áË ë^¨¥Ë)¢{(ç[É8bAzEÊ&zÚ yé!y«Þm§ÿí)äç¤r¿±ðëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
On Fre, 2003-02-28 at 10:11, Felix Kühling wrote:
>
> I think this discussion is getting off track. We have to make clear what
> we are talking about here. From the first mail on this subject I got the
> impression, the goal was
>
> - to implement accelerated 2D primitives using the 3D graphics e
On Don, 2003-02-27 at 20:52, Martin Spott wrote:
> Michel D?nzer <[EMAIL PROTECTED]> wrote:
>
> > The radeon driver uses the DRM for 2D acceleration when DRI is enabled,
>
> Is the radeon driver the only one doing so ?
I think all drivers supporting the DRI have to deal with 2D and 3D
concurre
Am Freitag, 28. Februar 2003 14:18 schrieb Felix Kühling:
> On 28 Feb 2003 14:02:14 +0100
>
> Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > On Fre, 2003-02-28 at 13:30, Felix Kühling wrote:
> > > On 28 Feb 2003 12:00:48 GMT
> > >
> > > Martin Spott <[EMAIL PROTECTED]> wrote:
> > > > Nick Kurshev <[E
On 28 Feb 2003 14:02:14 +0100
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Fre, 2003-02-28 at 13:30, Felix Kühling wrote:
> > On 28 Feb 2003 12:00:48 GMT
> > Martin Spott <[EMAIL PROTECTED]> wrote:
> >
> > > Nick Kurshev <[EMAIL PROTECTED]> wrote:
> > >
> > > > Image distortion became visible i
On Don, 2003-02-27 at 23:01, Jon Smirl wrote:
> -- Sven Luther <[EMAIL PROTECTED]> wrote:
> > Notice that the DRI drivers don't do anything like
> > mode setting and
> > such, they depend on the X drivers for that. So if
> > you take away the X
> > driver, you will not be able to get anything
> >
On Fre, 2003-02-28 at 13:30, Felix Kühling wrote:
> On 28 Feb 2003 12:00:48 GMT
> Martin Spott <[EMAIL PROTECTED]> wrote:
>
> > Nick Kurshev <[EMAIL PROTECTED]> wrote:
> >
> > > Image distortion became visible in oct 2002.
> >
> > This probably was the time when hardware-TCL came into play !?
>
On Fri, 2003-02-28 at 12:19, Sven Luther wrote:
> So, No 2D windows on the face of rotating cubes ?
Once your 2D windows are textures the rest is very much free, including
scaling, rotation occlusion and alpha blending. You can use it to build
the base X interfaces then worry about exposing the wa
On 28 Feb 2003 12:00:48 GMT
Martin Spott <[EMAIL PROTECTED]> wrote:
> Nick Kurshev <[EMAIL PROTECTED]> wrote:
>
> > Image distortion became visible in oct 2002.
>
> This probably was the time when hardware-TCL came into play !?
> You could try to set $RADEON_TCL_FORCE_DISABLE to 't' and see if i
On Fri, Feb 28, 2003 at 01:14:09PM +, Alan Cox wrote:
> On Fri, 2003-02-28 at 08:25, Sven Luther wrote:
> > Also, before you speak about unifying the 2D and 3D drivers
> > you need to look at how a 3D desktop would work.
>
> I would assume roughly like the Apple renders seem to work now, or ho
On Fri, 2003-02-28 at 08:25, Sven Luther wrote:
> Also, before you speak about unifying the 2D and 3D drivers
> you need to look at how a 3D desktop would work.
I would assume roughly like the Apple renders seem to work now, or how
the opengl accelerated canvas works in E. That bit is hardly rocke
Nick Kurshev <[EMAIL PROTECTED]> wrote:
> Image distortion became visible in oct 2002.
This probably was the time when hardware-TCL came into play !?
You could try to set $RADEON_TCL_FORCE_DISABLE to 't' and see if it makes
any difference,
Martin.
--
Unix _IS_ user friendly - it's just selecti
On Thu, Feb 27, 2003 at 06:04:36PM -0800, Jon Smirl wrote:
> --- Ian Romanick <[EMAIL PROTECTED]> wrote:
> > Let's see, XFree86 supports 2D for about 50
> > different chips, and it
> > supports 3D for about 5. MS might be in a position
> > to cast way support
> > for older hardware, but I don't
Hello!
I've met this problem (see attach) a long ago but it seems
that nobody fixed that :(
This problem happens not only with this game but with quake3 too!
It looks like every odd frame contains these black squares but every
even frame is free from them that causes image flickering!
These square
On Fri, 28 Feb 2003 04:39:58 +0100
Bernhard Kaindl <[EMAIL PROTECTED]> wrote:
> On Thu, 27 Feb 2003, Jon Smirl wrote:
>
> > Long ago I loved the command line. I was an expert at
> > it. When Window 1.0 came out I got my first exposure
> > to a mouse. For about a year I wouldn't get one, but
> > n
On Thu, Feb 27, 2003 at 02:01:22PM -0800, Jon Smirl wrote:
> --- Sven Luther <[EMAIL PROTECTED]> wrote:
> > Notice that the DRI drivers don't do anything like
> > mode setting and
> > such, they depend on the X drivers for that. So if
> > you take away the X
> > driver, you will not be able to get
61 matches
Mail list logo
