On Mit, 2002-11-13 at 23:30, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
> > On Die, 2002-11-12 at 20:41, Manuel Bilderbeek wrote:
> >>How can it be so little while having 32MB of videoRAM?
> >
> > The amount of memory available for textures is the total amount of video
> > RAM minus the amou
On Mit, 2002-11-13 at 23:30, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
> > On Die, 2002-11-12 at 20:41, Manuel Bilderbeek wrote:
> >>How can it be so little while having 32MB of videoRAM?
> >
> > The amount of memory available for textures is the total amount of video
> > RAM minus the amou
Michel Dänzer wrote:
On Die, 2002-11-12 at 20:41, Manuel Bilderbeek wrote:
How can it be so little while having 32MB of videoRAM?
The amount of memory available for textures is the total amount of video
RAM minus the amount occupied by the front, back and depth buffers and
the pixmap cache. In
Michel Dänzer wrote:
On Die, 2002-11-12 at 20:41, Manuel Bilderbeek wrote:
How can it be so little while having 32MB of videoRAM?
The amount of memory available for textures is the total amount of video
RAM minus the amount occupied by the front, back and depth buffers and
the pixmap cache. In
On Die, 2002-11-12 at 20:41, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
> >>(II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5
> >
> > That's very little indeed.
>
> How can it be so little while having 32MB of videoRAM?
The amount of memory available for textures is the tota
On Die, 2002-11-12 at 20:41, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
> >>(II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5
> >
> > That's very little indeed.
>
> How can it be so little while having 32MB of videoRAM?
The amount of memory available for textures is the tota
Michel Dänzer wrote:
(II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5
That's very little indeed.
How can it be so little while having 32MB of videoRAM?
Why do almost all other GL apps work fine, even Return to Castle
Wolfenstein and the Quake 3 Arena demo? I guess they need
Michel Dänzer wrote:
(II) RADEON(0): Will use 2752 kb for textures at offset 0x1d5
That's very little indeed.
How can it be so little while having 32MB of videoRAM?
Why do almost all other GL apps work fine, even Return to Castle
Wolfenstein and the Quake 3 Arena demo? I guess they need
On Mon, 2002-11-11 at 19:48, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
> - Tux's right arm is still a bit white and so is the bottom of his feet
> - Lots of these messages on the screen: radeonUploadTexImages: ran into
> bound texture
> >>>
> >>>Hmm, I don't see that, maybe you
On Mon, 2002-11-11 at 19:48, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
> - Tux's right arm is still a bit white and so is the bottom of his feet
> - Lots of these messages on the screen: radeonUploadTexImages: ran into
> bound texture
> >>>
> >>>Hmm, I don't see that, maybe you
Michel Dänzer wrote:
- Tux's right arm is still a bit white and so is the bottom of his feet
- Lots of these messages on the screen: radeonUploadTexImages: ran into
bound texture
Hmm, I don't see that, maybe you're still low on texture memory?
grep 'for textures' /var/log/XFree86.0.log
(II)
Michel Dänzer wrote:
- Tux's right arm is still a bit white and so is the bottom of his feet
- Lots of these messages on the screen: radeonUploadTexImages: ran into
bound texture
Hmm, I don't see that, maybe you're still low on texture memory?
grep 'for textures' /var/log/XFree86.0.log
(II) R
On Son, 2002-11-10 at 00:39, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
>
> >>- Tux's right arm is still a bit white and so is the bottom of his feet
> >>- Lots of these messages on the screen: radeonUploadTexImages: ran into
> >>bound texture
> >
> > Hmm, I don't see that, maybe you're s
On Son, 2002-11-10 at 00:39, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
>
> >>- Tux's right arm is still a bit white and so is the bottom of his feet
> >>- Lots of these messages on the screen: radeonUploadTexImages: ran into
> >>bound texture
> >
> > Hmm, I don't see that, maybe you're s
Michel Dänzer wrote:
On Sam, 2002-11-09 at 18:23, Manuel Bilderbeek wrote:
What problems exactly? Note that it is slow in depth 24, and it shows
some incorrect rendering unless RADEON_TCL_FORCE_DISABLE=1 is set.
This doesn't really make a difference. The problems are:
- Every about 0.4 second
On Sam, 2002-11-09 at 18:23, Manuel Bilderbeek wrote:
>
> >>Most debug messages are gone now (e.g. when dragging the
> >>glxgears window), but the problems with Tuxracer remain.
> >
> > What problems exactly? Note that it is slow in depth 24, and it shows
> > some incorrect rendering unless RADEO
Michel Dänzer wrote:
On Sam, 2002-11-09 at 18:23, Manuel Bilderbeek wrote:
What problems exactly? Note that it is slow in depth 24, and it shows
some incorrect rendering unless RADEON_TCL_FORCE_DISABLE=1 is set.
This doesn't really make a difference. The problems are:
- Every about 0.4 seconds
On Sam, 2002-11-09 at 18:23, Manuel Bilderbeek wrote:
>
> >>Most debug messages are gone now (e.g. when dragging the
> >>glxgears window), but the problems with Tuxracer remain.
> >
> > What problems exactly? Note that it is slow in depth 24, and it shows
> > some incorrect rendering unless RADEO
Michel Dänzer wrote:
Hmm, might be caused by some cruft left over in the postinst. Cleaning
that up for the next version.
OK, I'm doing a dist-upgrade everyday, so I guess I'll see it coming then.
I downgraded the xserver-xfree86-dri-trunk package, which solved the
problem.
Ah, this might b
Michel Dänzer wrote:
Hmm, might be caused by some cruft left over in the postinst. Cleaning
that up for the next version.
OK, I'm doing a dist-upgrade everyday, so I guess I'll see it coming then.
I downgraded the xserver-xfree86-dri-trunk package, which solved the
problem.
Ah, this might be
On Sam, 2002-11-09 at 13:29, Manuel Bilderbeek wrote:
> Setting up xserver-xfree86-dri-trunk (2002.11.06-1) ...
> Argument "180=" isn't numeric in numeric lt (<) at
> /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 25.
Hmm, might be caused by some cruft left over in the postinst. Cleaning
that u
Michel Dänzer wrote:
>> > - TuxRacer: Tux looks white!
>>
>>Hah! Tux looks normal now!
>>However, still problems with Tuxracer: with the new drivers, the game
>>slows down incredibly about every second. It seems to go smoooth,
almost
>>stops then, continues smoothly then, almost stop
On Sam, 2002-11-09 at 13:29, Manuel Bilderbeek wrote:
> Setting up xserver-xfree86-dri-trunk (2002.11.06-1) ...
> Argument "180=" isn't numeric in numeric lt (<) at
> /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 25.
Hmm, might be caused by some cruft left over in the postinst. Cleaning
that u
Michel Dänzer wrote:
>> > - TuxRacer: Tux looks white!
>>
>>Hah! Tux looks normal now!
>>However, still problems with Tuxracer: with the new drivers, the game
>>slows down incredibly about every second. It seems to go smoooth,
almost
>>stops then, continues smoothly then, almost stops
On Fre, 2002-11-08 at 20:25, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
> > On Don, 2002-11-07 at 22:11, Manuel Bilderbeek wrote:
> >
> >>Michel Dänzer wrote:
> > kernel-image-2.4.19-k7 also contains some DRM modules, use
> > --force-overwrite .
>
> OK, I did it!
>
> And, I have 3D
On Fre, 2002-11-08 at 20:25, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
> > On Don, 2002-11-07 at 22:11, Manuel Bilderbeek wrote:
> >
> >>Michel Dänzer wrote:
> > kernel-image-2.4.19-k7 also contains some DRM modules, use
> > --force-overwrite .
>
> OK, I did it!
>
> And, I have 3D
Michel Dänzer wrote:
> On Don, 2002-11-07 at 22:11, Manuel Bilderbeek wrote:
>
>>Michel Dänzer wrote:
> kernel-image-2.4.19-k7 also contains some DRM modules, use
> --force-overwrite .
OK, I did it!
And, I have 3D again! :-)
Now, coming back to my previous problems (I only did a quick test
Michel Dänzer wrote:
> On Don, 2002-11-07 at 22:11, Manuel Bilderbeek wrote:
>
>>Michel Dänzer wrote:
> kernel-image-2.4.19-k7 also contains some DRM modules, use
> --force-overwrite .
OK, I did it!
And, I have 3D again! :-)
Now, coming back to my previous problems (I only did a quick test
t
On Don, 2002-11-07 at 22:11, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
>
> goemon:/usr/src# dpkg -i
> drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb
> (Reading database ... 88700 files and directories currently installed.)
> Unpacking drm-trunk-module-2.4.19-k7 (from
> drm-tru
On Don, 2002-11-07 at 22:11, Manuel Bilderbeek wrote:
> Michel Dänzer wrote:
>
> goemon:/usr/src# dpkg -i
> drm-trunk-module-2.4.19-k7_10.00.Custom+2002.10.02-1_i386.deb
> (Reading database ... 88700 files and directories currently installed.)
> Unpacking drm-trunk-module-2.4.19-k7 (from
> drm-tru
Michel Dänzer wrote:
> On Mit, 2002-11-06 at 21:17, Manuel Bilderbeek wrote:
>
>>goemon:~> glxgears
>>Radeon DRI driver:
>> Compatibility mode for DRM driver version 1.1.1
>> TCL will be disabled, expect reduced performance
>> (prefer DRM radeon.o 1.3.x or newer)
>>
Michel Dänzer wrote:
> On Mit, 2002-11-06 at 21:17, Manuel Bilderbeek wrote:
>
>>goemon:~> glxgears
>>Radeon DRI driver:
>> Compatibility mode for DRM driver version 1.1.1
>> TCL will be disabled, expect reduced performance
>> (prefer DRM radeon.o 1.3.x or newer)
>>
On Mit, 2002-11-06 at 21:17, Manuel Bilderbeek wrote:
>
> goemon:~> glxgears
> Radeon DRI driver:
> Compatibility mode for DRM driver version 1.1.1
> TCL will be disabled, expect reduced performance
> (prefer DRM radeon.o 1.3.x or newer)
> disabling TCL support
Hi again,
Michel Dänzer wrote:
>>I configed it more than one time and I can't remember that debconf asked
>>me about FBDev...
>
> Maybe it's a low priority question, otherwise it's probably autodetected
> from /proc/fb .
Could be, but my /proc/fb is empty.
>>However, I have serious problems wit
On Mit, 2002-11-06 at 21:17, Manuel Bilderbeek wrote:
>
> goemon:~> glxgears
> Radeon DRI driver:
> Compatibility mode for DRM driver version 1.1.1
> TCL will be disabled, expect reduced performance
> (prefer DRM radeon.o 1.3.x or newer)
> disabling TCL support
Hi again,
Michel Dänzer wrote:
>>I configed it more than one time and I can't remember that debconf asked
>>me about FBDev...
>
> Maybe it's a low priority question, otherwise it's probably autodetected
> from /proc/fb .
Could be, but my /proc/fb is empty.
>>However, I have serious problems with
On Die, 2002-11-05 at 21:18, Manuel Bilderbeek wrote:
>
> Michel Dänzer wrote:
> >>I'm running X at [EMAIL PROTECTED] My XFree86-4 is config'ed with
> >>debconf (except that I removed the Use FBdev stuff that is put there by
> >>default).
> >
> > I don't think it is unless you told it to.
>
Branden wrote:
I don't think it is the cable, since:
1) I used the original cable that came with my Iyama A902MT monitor,
which is brand new
2) the problem only occurs in X, not in textmode or in Windows (sorry
for that)
Those don't necessarily rule out signal degradation.
1) Iiyama may have
On Die, 2002-11-05 at 21:18, Manuel Bilderbeek wrote:
>
> Michel Dänzer wrote:
> >>I'm running X at 1600x1200x32@85Hz. My XFree86-4 is config'ed with
> >>debconf (except that I removed the Use FBdev stuff that is put there by
> >>default).
> >
> > I don't think it is unless you told it to.
>
Hi,
Michel Dänzer wrote:
>>I'm running X at [EMAIL PROTECTED] My XFree86-4 is config'ed with
>>debconf (except that I removed the Use FBdev stuff that is put there by
>>default).
>
> I don't think it is unless you told it to.
I configed it more than one time and I can't remember that debconf ask
On Mon, Nov 04, 2002 at 09:22:15PM +0100, Manuel Bilderbeek wrote:
> Blars Blarson wrote:
> >In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> >[ghosting]
> >
> >This is usually caused by a problem with your monitor or the cable to
> >it. If you can, try a different (shorter and/or higher
Branden wrote:
I don't think it is the cable, since:
1) I used the original cable that came with my Iyama A902MT monitor,
which is brand new
2) the problem only occurs in X, not in textmode or in Windows (sorry
for that)
Those don't necessarily rule out signal degradation.
1) Iiyama may have g
Hi,
Michel Dänzer wrote:
>>I'm running X at 1600x1200x32@85Hz. My XFree86-4 is config'ed with
>>debconf (except that I removed the Use FBdev stuff that is put there by
>>default).
>
> I don't think it is unless you told it to.
I configed it more than one time and I can't remember that debconf ask
On Mon, Nov 04, 2002 at 09:22:15PM +0100, Manuel Bilderbeek wrote:
> Blars Blarson wrote:
> >In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> >[ghosting]
> >
> >This is usually caused by a problem with your monitor or the cable to
> >it. If you can, try a different (shorter and/or higher
On Mon, 2002-11-04 at 20:38, Manuel Bilderbeek wrote:
>
> I'm running testing (always upgraded to the newest packages). I have an
> Athlon XP 1600+ with VIA K7T266 Pro 2 mainboard and an ATI Radeon SDR
> 32MB AGP videocard (I think that is now called the Radeon 7200).
> I'm running X at [EMAIL P
On Mon, 2002-11-04 at 20:38, Manuel Bilderbeek wrote:
>
> I'm running testing (always upgraded to the newest packages). I have an
> Athlon XP 1600+ with VIA K7T266 Pro 2 mainboard and an ATI Radeon SDR
> 32MB AGP videocard (I think that is now called the Radeon 7200).
> I'm running X at 1600x120
Stephen Depooter wrote:
On Mon, 2002-11-04 at 14:38, Manuel Bilderbeek wrote:
Problem 2:
==
This is regarding 3D. The 3D acceleration seems to work fine, but there
are minor problems:
- TuxRacer: Tux looks white! Something is wrong with the colors of the
Tux character in this game, on
On Mon, 2002-11-04 at 14:38, Manuel Bilderbeek wrote:
> Problem 2:
> ==
> This is regarding 3D. The 3D acceleration seems to work fine, but there
> are minor problems:
> - TuxRacer: Tux looks white! Something is wrong with the colors of the
> Tux character in this game, only the shadows o
Blars Blarson wrote:
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
[ghosting]
This is usually caused by a problem with your monitor or the cable to
it. If you can, try a different (shorter and/or higher quality)
cable. If you are using a switch box, try without.
This problem may be
Stephen Depooter wrote:
On Mon, 2002-11-04 at 14:38, Manuel Bilderbeek wrote:
Problem 2:
==
This is regarding 3D. The 3D acceleration seems to work fine, but there
are minor problems:
- TuxRacer: Tux looks white! Something is wrong with the colors of the
Tux character in this game, onl
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>Since I bought my computer and installed Debian, I have been
>experiencing some weird problems in X...
>Problem 1:
[ghosting]
This is usually caused by a problem with your monitor or the cable to
it. If you can, try a different (shorter
On Mon, 2002-11-04 at 14:38, Manuel Bilderbeek wrote:
> Problem 2:
> ==
> This is regarding 3D. The 3D acceleration seems to work fine, but there
> are minor problems:
> - TuxRacer: Tux looks white! Something is wrong with the colors of the
> Tux character in this game, only the shadows o
Hi!
Since I bought my computer and installed Debian, I have been
experiencing some weird problems in X... I hope this is the right
mailinglist to post this to
I hoped XFree86 4.2.1 would solve some of them, but my hope was in vain:
nothing changed after upgrading my 4.1.0 to 4.2.1 yesterda
Blars Blarson wrote:
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
[ghosting]
This is usually caused by a problem with your monitor or the cable to
it. If you can, try a different (shorter and/or higher quality)
cable. If you are using a switch box, try without.
This problem may be
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>Since I bought my computer and installed Debian, I have been
>experiencing some weird problems in X...
>Problem 1:
[ghosting]
This is usually caused by a problem with your monitor or the cable to
it. If you can, try a different (shorter
Hi!
Since I bought my computer and installed Debian, I have been
experiencing some weird problems in X... I hope this is the right
mailinglist to post this to
I hoped XFree86 4.2.1 would solve some of them, but my hope was in vain:
nothing changed after upgrading my 4.1.0 to 4.2.1 yesterday
56 matches
Mail list logo
