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
> > 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 i
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?
___
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
> fi
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.
> 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 ren
> > 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 fo
On 10 Apr 2002, Michel Dänzer wrote:
> On Wed, 2002-04-10 at 01:52, Leif Delgass wrote:
> > 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
> > 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 implementati
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
On Wed, 2002-04-10 at 01:52, Leif Delgass wrote:
> 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 re
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
> ef
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 Z buffer
satisfies the request for 23 bits.
> On the Radeon, i
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 I
"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 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
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 1280
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
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 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 re
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?
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 se
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
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.
>
>
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 Sp
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
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=detail&aid=451696&group_id=369&atid=100369
So most kudos go to ??? --- I don't know.
Both patches apply but the secon
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 fo
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 4/
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 O
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 l
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 incompa
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, t
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
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
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 PROTE
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
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 w
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 poi
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
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
>
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 situ
> 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
> 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 everyt
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
___
Dri
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 P
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
> 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]
https://lists.so
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 ca
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 m
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 libGL.s
51 matches
Mail list logo
