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 forgotten
On Tue, 2002-04-09 at 07:43, Jens Owen wrote:
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
On Mon, Apr 08, 2002 at 05:23:31PM -0700, Ian Romanick wrote:
I'm a little bit suspicious of these hangs, and I would like to see if
anyone else can reproduce them. Volunteers?
I just tested with quake3. The startup video doesn't work at all. I just
see the brownish background (first frame
Also, are people testing older X servers with new DRMs? In particular,
has anyone used a mesa4 or tcl Radeon DRM with a 4.1.0/4.2.0 X Server?
At this point I have a FreeBSD DRM set which is mesa4 but with
drmcommand and tcl bits pulled in, working for Radeon with TCL and I
think for the other
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.
... Any logs available for the public?
Cheers,
Sergey
___
Dri-devel mailing list
[EMAIL PROTECTED]
Jens,
On Mon, Apr 08, 2002 at 03:01:29PM -0600, Jens Owen wrote:
[...] You can get this latest package from the usual place, it's called
radeon-20020408-i386-Linux.tar.gz
[...]
[drm] Initialized radeon 1.3.0 20020408 on minor 0
Everything works as desired - thanks alot.
There's still the
On Sat, 6 Apr 2002, Brian Paul wrote:
Date: Sat, 06 Apr 2002 08:56:32 -0700
From: Brian Paul [EMAIL PROTECTED]
To: DRI-Devel [EMAIL PROTECTED], [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Subject: Red Hat glide problem (was What about a trunk update to 4.0.2?)
Brian Paul wrote:
Eric Anholt wrote:
Also, are people testing older X servers with new DRMs? In particular,
has anyone used a mesa4 or tcl Radeon DRM with a 4.1.0/4.2.0 X Server?
Yes, I do this for the radeon, and have found a few bugs this way.
Keith
___
On Mon, Apr 08, 2002 at 03:01:29PM -0600, Jens Owen wrote:
[...] You can get this latest package from the usual place, it's called
radeon-20020408-i386-Linux.tar.gz
[...]
[drm] Initialized radeon 1.3.0 20020408 on minor 0
Everything works as desired - thanks alot.
Nah, not everything
I agree with the you have to read pixels back from the frame
buffer and
then continue rendering polygons. For a hardware
implementation I might
agree with the you need to draw more polygons than your
hardware has room
to store, but only if the hardware implementation decides to perform
I think i know about that state.
Terminating it doesnt work in the end.
It does happen to me that way if corrupt
the command buffers for the grafics chip.
This is either a direct programming error
like an inadequate amount of data after
a specific command package, an illegal
command or some
Michel Dänzer wrote:
On Tue, 2002-04-09 at 07:43, Jens Owen wrote:
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
Martin Spott wrote:
On Mon, Apr 08, 2002 at 03:01:29PM -0600, Jens Owen wrote:
[...] You can get this latest package from the usual place, it's called
radeon-20020408-i386-Linux.tar.gz
[...]
[drm] Initialized radeon 1.3.0 20020408 on minor 0
Everything works as desired - thanks
Eric,
First off, let me say: Good work on the porting, it's nice to see the
OS independence put to the test.
Eric Anholt wrote:
Also, are people testing older X servers with new DRMs? In particular,
has anyone used a mesa4 or tcl Radeon DRM with a 4.1.0/4.2.0 X Server?
Yes, at this
On Tue, Apr 09, 2002 at 07:26:36AM -0600, Jens Owen wrote:
Do you get the lockup with $RADEON_NO_TCL set to '1'?
Yes, definitely. Hmmm, it's difficult to test the other case while the boss
is standing near me :-)
Martin.
--
Unix _IS_ user friendly - it's just selective about
Ville Syrjälä wrote:
I'm going to try to the trunk later today.
Ville,
If you really want to isolate whether this is related to drmCommand
changes, then try the trunk from the day we split out the drmcommand
branch. That should have all the bugs the drmcommand branch has with
out any of the
I have the same problem with the introduction of quake3 (it renders only
the firt frame), using the latest Xfree86-CVS with Mesa-4.0.2.
So this is not a bug of drm-command.
Regards
Panagiotis Papadakos
___
Dri-devel mailing list
[EMAIL
Stephen J Baker wrote:
Everything starts out in hardware and eventually moves to software.
That's odd - I see the reverse happening. First we had software
The move from hardware to software is an industry-wide pattern for all
technology. It saves money. 3D video cards have been
Keith,
Just FYI. In the last week or so, something has caused gears to
slowdown on my box by about 15%. Perhaps this was expected.
Regards,
Jens
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
On Sat, Apr 06, 2002 at 09:42:36AM -0700, Brian Paul wrote:
Ian Romanick wrote:
Also, I just noticed that when Maya starts up it logs the following message
in its script editor windows. It repeats four times.
// Warning: Unable to get OpenGL visual with a depth buffer, trying
Jens Owen wrote:
Michel Dänzer wrote:
On Tue, 2002-04-09 at 07:43, Jens Owen wrote:
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
versioning and header names are done. I'm freezing now and will start
the merge process.
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Dri-devel mailing
Ian Romanick wrote:
On Sat, Apr 06, 2002 at 09:42:36AM -0700, Brian Paul wrote:
Ian Romanick wrote:
Also, I just noticed that when Maya starts up it logs the following message
in its script editor windows. It repeats four times.
// Warning: Unable to get OpenGL visual with a
Wow. I just get to be the bearer of bad news today!
After doing some cursory Maya testing, I decided to put the TCL branch up
against glean, and glean won. It consistently explodes in one of the
blendFunc tests. This is with the latest glean CVS trunk and DRI TCL branch
as of the morning of
On Tue, Apr 09, 2002 at 09:00:44PM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
In other news, I tried (using CVS as of the morning of 4/9) running in
1152x864 and maximizing the Maya (so that it would fit) and running in
Maya's expected 1280x1024. In both cases, I hit the following
Hello,
I got a helpfully mail pointing me to a post at glide.sourceforge.net on
Thursday or Friday last week and bingo, I got it.
http://sourceforge.net/tracker/index.php?func=detailaid=451696group_id=369atid=100369
So most kudos go to ??? --- I don't know.
Both patches apply but the second
I put up the contents of my X-Chat buffer from last Moday at the usual
place:
http://dri.sourceforge.net/IRC-logs/
If someone has logs for the missing dates or maybe a better replacement
for one of the ones we have, please let us know.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux
Jens Owen wrote:
versioning and header names are done. I'm freezing now and will start
the merge process.
Merge to trunk done. drmcommand-0-0-1-branch is now dead.
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat
Thanks for pointing them out Dieter.
I've applied them to the Glide source tree.
Alan.
On Tue, Apr 09, 2002 at 11:54:23PM +0200, Dieter Nützel wrote:
Hello,
I got a helpfully mail pointing me to a post at glide.sourceforge.net on
Thursday or Friday last week and bingo, I got it.
I just submitted bug #541782. There is a rendering error on the Radeon in
Quake 3 when cg_shadows is 2. The bug does *not* happen with it is set to
3. The problem seems to be related to alpha blending, primarilly in weapon
effects. There is a screen shot with the bug report.
--
Tell that to
Ufh!! 8-O
I've finally ( hopefully) finished the rewrite of Mesa's MMX blend code.
The code is configurable - allowing to choose several methods for the
blending equation.
Here are the benchmarks that I made (on a Pentium III 700Mhz):
C code: 8.142382 sec
Old MMX code: 4.363946
On 2002.04.09 23:02 Jens Owen wrote:
Jens Owen wrote:
versioning and header names are done. I'm freezing now and will start
the merge process.
Merge to trunk done. drmcommand-0-0-1-branch is now dead.
What are the effects of this on the package and installations scripts?
José
On Tue, 9 Apr 2002, Keith Whitwell wrote:
Ian Romanick wrote:
On Sat, Apr 06, 2002 at 09:42:36AM -0700, Brian Paul wrote:
Ian Romanick wrote:
Also, I just noticed that when Maya starts up it logs the following message
in its script editor windows. It repeats four times.
On Wed, 2002-04-10 at 01:01, Leif Delgass wrote:
The mach64 can only use a 16-bit depth buffer, even with a 32bpp framebuffer,
so I'm also interested in this. I couldn't see a way to request a
smaller buffer from the XFree framebuffer manager (currently we
allocate a 32-bit depth buffer,
On 10 Apr 2002, Michel Dänzer wrote:
On Wed, 2002-04-10 at 01:01, Leif Delgass wrote:
The mach64 can only use a 16-bit depth buffer, even with a 32bpp framebuffer,
so I'm also interested in this. I couldn't see a way to request a
smaller buffer from the XFree framebuffer manager
Ian Romanick wrote:
On Tue, Apr 09, 2002 at 09:00:44PM +0100, Keith Whitwell wrote:
Ian Romanick wrote:
In other news, I tried (using CVS as of the morning of 4/9) running in
1152x864 and maximizing the Maya (so that it would fit) and running in
Maya's expected 1280x1024. In both
On Tue, Apr 09, 2002 at 05:54:55PM -0600, Jens Owen wrote:
Ian Romanick wrote:
On Tue, Apr 09, 2002 at 09:00:44PM +0100, Keith Whitwell wrote:
I committed a fix for a similar-sounding problem today - it would be
interesting to see if this has changed.
I checked CVS with 'cvs -z3
José Fonseca wrote:
On 2002.04.09 23:02 Jens Owen wrote:
Jens Owen wrote:
versioning and header names are done. I'm freezing now and will start
the merge process.
Merge to trunk done. drmcommand-0-0-1-branch is now dead.
What are the effects of this on the package and
Leif Delgass wrote:
On Tue, 9 Apr 2002, Keith Whitwell wrote:
Probably just the way it was done. It would be fairly easy to allow an
XF86Config option for zbuffer depth, but quite a bit more work to support 16
and 32 bpp side-by-side.
We talked about this a bit at yesterday's IRC. The
On Tue, Apr 09, 2002 at 03:24:36PM -0700, Ian Romanick wrote:
I just submitted bug #541782. There is a rendering error on the Radeon in
Quake 3 when cg_shadows is 2. The bug does *not* happen with it is set to
3. The problem seems to be related to alpha blending, primarilly in weapon
On Tue, Apr 09, 2002 at 06:13:30PM -0600, Brian Paul wrote:
Ian Romanick wrote:
The issue is that Maya is requesting at least 23-bits of Z-buffer. In
16-bit mode, we only have 16-bits of Z-buffer, so it can't find a visual.
Just for grins you could hack glXChooseVisual so that a 16-bit
I agree with the you have to read pixels back from the frame
buffer and
then continue rendering polygons. For a hardware
implementation I might
agree with the you need to draw more polygons than your
hardware has room
to store, but only if the hardware implementation decides to
With the rest I disagree. The Kyro, for example, has some high-speed
local
memory (cache) it uses to hold the pixels for a tile. It can antialias
and
render translucent scenes without ever blitting the cache to the
framebuffer
more than once.
It can't have infinite storage for tile
I agree. You may want to take a look at the following article:
http://www.tech-report.com/reviews/2001q2/tnl/index.x?pg=1
It shows, among other things, a 400MHz PII with a 3dfx Voodoo2 (hardware
rasterization) getting almost double the framerate of a 1.4GHz Athlon
doing software rendering
On Tue, Apr 09, 2002 at 09:16:41AM -0600, Jens Owen wrote:
Ville Syrjälä wrote:
I'm going to try to the trunk later today.
Ville,
If you really want to isolate whether this is related to drmCommand
changes, then try the trunk from the day we split out the drmcommand
branch. That
On Tue, Apr 09, 2002 at 08:39:10AM -0700, Ian Romanick wrote:
This is a known issue. It's in the texture management code. IIRC, the
problem is that the whole texture isn't uploaded properly. In any case, the
new texture management code that I (still) am awaiting permission to release
fixes
On Tue, 9 Apr 2002, Raystonn wrote:
If you want to get back to the topic of software rendering, I would be more
than happy to oblige.
Better yet, if you are serious - how about furthering your argument with
patches to optimise and improve Mesa's software paths?
If you want to get back to the topic of software rendering, I would be
more
than happy to oblige.
Better yet, if you are serious - how about furthering your argument with
patches to optimise and improve Mesa's software paths?
Patches will not do the job. My ideas include a change in
Odd, I sent a few emails to the list and I have
received none of them. An hour after that I sent one more and I just got
it from the list. This leaves me wondering of my other emails have sunken
into a black hole somewhere...
Has anyone else had these troubles on this
list?
-Raystonn
49 matches
Mail list logo
