> > I still maintain that immediate mode renderering is an inefficient
algorithm
> > designed to favor the use of memory over computations. A better
algorithm
> > will always win out given enough time to overtake the optimized versions
of
> > the more inefficient algorithms.
>
> Perhaps you've fo
On Mon, Apr 08, 2002 at 06:17:59PM -0700, Raystonn wrote:
> I still maintain that immediate mode renderering is an inefficient algorithm
> designed to favor the use of memory over computations. A better algorithm
> will always win out given enough time to overtake the optimized versions of
> the
Has anybody tried using the latest DRI trunk code with older versions of
libGL.so since the Mesa 4.0.2 merge? Michael D. reported the drmcommand
branch and the trunk were now incompatible. I know the drmcommand
drivers work with older libGL.so's, so I'm concerned we might have
introduced an inco
Michael reported in that the R128 driver is working--so we've completed
the main round of changes required for moving to DRM. Two items I plan
addressing before merging with the trunk are:
1) Moving the common xf86drm.h headers into the 2D driver
directory.
2) Introduce versioning to prevent ne
On Mon, Apr 08, 2002 at 06:17:59PM -0700, Raystonn wrote:
| As far as the reading of pixels from the framebuffer, this is a highly
| inefficient thing to do, no matter the hardware.
It doesn't have to be; that's just a tradeoff made by the hardware
designers depending on the applications for whic
> > The games perform overdraw, sure. But I am talking about at the pixel
> > level. A scene-capture algorithm performs 0 overdraw, regardless of
what
> > the game sends it.
>
> That's not true. I've designed and built machines like this and I know.
>
> You still need overdraw when:
>
> * you
On Mon, Apr 08, 2002 at 06:05:07PM -0600, Jens Owen wrote:
> Based on the results above, I would say the drmCommand changes are okay
> for the MGA. Obviously, the MGA driver has some problems that would be
> better addressed with the version from the trunk. I'm reluctant to
> address the non-dr
Ian Romanick wrote:
>
> On Mon, Apr 08, 2002 at 07:03:34PM -0400, Mike A. Harris wrote:
> > On Mon, 8 Apr 2002, Ian Romanick wrote:
> >
> > >I'm sending this as an HTML attachment. If this causes anybody problems,
> > >let me know and I can re-send as plain text.
> >
> > Doesn't cause any proble
On Mon, Apr 08, 2002 at 07:03:34PM -0400, Mike A. Harris wrote:
> On Mon, 8 Apr 2002, Ian Romanick wrote:
>
> >I'm sending this as an HTML attachment. If this causes anybody problems,
> >let me know and I can re-send as plain text.
>
> Doesn't cause any problems.. just can't read it. ;o)
D'o
On Mon, 8 Apr 2002, Ian Romanick wrote:
>Date: Mon, 8 Apr 2002 16:00:05 -0700
>From: Ian Romanick <[EMAIL PROTECTED]>
>To: DRI developer's list <[EMAIL PROTECTED]>
>Content-Type: multipart/mixed; boundary="J/dobhs11T7y2rNN"
>List-Id:
>Subject: G400 Compatibility Test Results
>
>I'm sending this
I'm sending this as an HTML attachment. If this causes anybody problems,
let me know and I can re-send as plain text.
--
Tell that to the Marines!
Title: drmcommand-0-0-1-branch on G400 Test Results
All driver combinations were tested with glxinfo, gears, and my Quake3 tests.
The Quake3 t
is not an actual
XFree86 release, we didn't bump any version numbers.
What I've done is to bring the date string up to date so we can tell if
you've got the latest DRM driver. You can get this latest package from
the usual place, it's called
Just FYI, the weekly IRC mtg will start in ~30 minutes. That's 5pm
Eastern time now that we're on daylight savings time in the US.
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
_
On Thu, 4 Apr 2002, Raystonn wrote:
> The games perform overdraw, sure. But I am talking about at the pixel
> level. A scene-capture algorithm performs 0 overdraw, regardless of what
> the game sends it.
That's not true. I've designed and built machines like this and I know.
You still need o
Hello Jens !
On Mon, Apr 08, 2002 at 09:40:30AM -0600, Jens Owen wrote:
> Thanks for the feedback on the TCL drivers and my packaging. I have a
> couple of questions that might help me understand what you're seeing...
This is written very nice - obviously I was somewhat too little precise.
>
Hi Martin,
Thanks for the feedback on the TCL drivers and my packaging. I have a
couple of questions that might help me understand what you're seeing...
Martin Spott wrote:
>
> Hello Jens,
> I'm having a try at each package of driver binaries you provide for
> download at ftp.tungstengraphics.
Hello Jens,
I'm having a try at each package of driver binaries you provide for
download at ftp.tungstengraphics.com. The radeon-20020404 is now the second
one that contains driver binaries not running on SuSE-7.3/XFree86-4.2.0.
To compare with older drivers ("connection refused" is the result of
17 matches
Mail list logo
