Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=960
--- Additional Comments From [EMAIL PROTECTED] 2004-10-06 23:50 ---
This one is
David Bronaugh wrote:
Thomas Hellstrom wrote:
Hi, Jon!
Jon Smirl wrote:
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and
Thomas Hellstrom wrote:
Hi, Jon!
Jon Smirl wrote:
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and again without it load
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=814
--- Additional Comments From [EMAIL PROTECTED] 2004-10-06 23:31 ---
I've tested
Hi, Jon!
Jon Smirl wrote:
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and again without it loaded.
[EMAIL PROTECTED] dr
Am Donnerstag, 7. Oktober 2004 02:00 schrieb Jon Smirl:
> This should fix it. I'm I'll check it in after I reboot and test it.
> It didn't occur to me that DRM(global) could be freed while the loop
> is in progress.
>
> I need to remember to keep testing everything with framebuffer loaded
> and aga
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=814
--- Additional Comments From [EMAIL PROTECTED] 2004-10-06 21:47 ---
Your patch d
On Thursday 07 October 2004 00:43, Alex Deucher wrote:
> On Thu, 7 Oct 2004 00:39:23 -0300, Paulo R. Dallan <[EMAIL PROTECTED]>
wrote:
> > On Wednesday 06 October 2004 09:58, Alex Deucher wrote:
> > > On Tue, 5 Oct 2004 23:40:17 -0300, Paulo R. Dallan <[EMAIL PROTECTED]>
> >
> > wrote:
> > > > On
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=982
[EMAIL PROTECTED] changed:
What|Removed |Added
-
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=982
[EMAIL PROTECTED] changed:
What|Removed |Added
-
On Thu, 7 Oct 2004 00:39:23 -0300, Paulo R. Dallan <[EMAIL PROTECTED]> wrote:
> On Wednesday 06 October 2004 09:58, Alex Deucher wrote:
> > On Tue, 5 Oct 2004 23:40:17 -0300, Paulo R. Dallan <[EMAIL PROTECTED]>
> wrote:
> > > On Tuesday 05 October 2004 19:56, Dave Airlie wrote:
>
> >
> > Use ldd t
On Wednesday 06 October 2004 09:58, Alex Deucher wrote:
> On Tue, 5 Oct 2004 23:40:17 -0300, Paulo R. Dallan <[EMAIL PROTECTED]>
wrote:
> > On Tuesday 05 October 2004 19:56, Dave Airlie wrote:
>
> Use ldd to check glxgears and make sure it's using the right libGL.
> come the output with ldd of gl
Alex Deucher wrote:
On Thu, 07 Oct 2004 01:31:18 +1100, Jonathan Adamczewski
<[EMAIL PROTECTED]> wrote:
Is it possible to run my 9700pro in dual head mode with the radeon driver?
Yes dualhead and mergedfb are supported on r300 chips.
Alex
Thanks. After a quick investigation and play aro
Jan Kreuzer wrote:
Jonathan Adamczewski wrote:
Hi,
After coming across r300.sf.net, I have the following configuration
up and running :
- 9700 pro aiw
- xorg-6.8.0 (patched as per r300.sf.net)
- linux kernel 2.6.9-rc3 (-rc2 patches seem to apply cleanly)
I obtained r300-demo from cvs, but cannot
Dieter Nützel wrote:
Am Mittwoch, 6. Oktober 2004 03:52 schrieb Ian Romanick:
Here's a simple patch that gives about a 50% (on my box) speed boost to
glReadPixels performance in 24-bit. I measured using the benchmark
built into progs/demos/readpix. The interesting thing is that the core
MMX & SSE
On Wednesday 06 October 2004 10:46, Vladimir Dergachev wrote:
> On Wed, 6 Oct 2004, Paulo R. Dallan wrote:
> > On Wednesday 06 October 2004 05:36, Paulo R. Dallan wrote:
> >> On Wednesday 06 October 2004 04:43, you wrote:
> >>> Paulo R. Dallan schrieb:
>I suggest you take a look at /proc/int
On Thu, 7 Oct 2004 02:10:37 +0100 (IST), Dave Airlie <[EMAIL PROTECTED]> wrote:
> So whats the major difference between a dri driver built in mesa and in
> Xorg? (should I suspect PTHREADS?)
At some point we are supposed to get to where mesa-solo and X and
using the same GL builds. That's a harder
On Thu, 07 Oct 2004 12:11:11 +1100, Jonathan <[EMAIL PROTECTED]> wrote:
>
>
> Alex Deucher wrote:
>
> >On Thu, 07 Oct 2004 01:31:18 +1100, Jonathan Adamczewski
> ><[EMAIL PROTECTED]> wrote:
> >
> >
> >>Is it possible to run my 9700pro in dual head mode with the radeon driver?
> >>
> >>
> >
> >Ye
I know someone asked a while back but I'm not sure anyone concluded what
was happening...
Last night I decided to give the d3demo a go on my r9200 under DRI, my
first attempt involved pointing LIBGL_DRIVERS_PATH to my S3TC enabled
Mesa tree, this works for me for a number of games and seems fine,
I've checked it now with both framebuffer loaded and unloaded. The
problem is not present in the drm_core version. I'm surprised no one
noticed this earlier, but it didn't impact the function of the driver
for a normal user it only faulted during unloaded. Fix is in CVS.
If you notice other proble
CC'ing dri-devel...
Ian any ideas on the texture bugs?
Alex
On Wed, 6 Oct 2004 23:14:10 +0200, Jörg Walter
<[EMAIL PROTECTED]> wrote:
> On Wed, Oct 06, 2004 at 10:05:38PM +0200, J?rg Walter wrote:
> > On Wed, Oct 06, 2004 at 08:49:55AM -0400, Alex Deucher wrote:
> > > On Wed, 6 Oct 2004 01:43:0
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1519
--- Additional Comments From [EMAIL PROTECTED] 2004-10-06 17:03 ---
(In reply t
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and again without it loaded.
[EMAIL PROTECTED] drm-bk]$ bk -r diffs -u
==
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=814
--- Additional Comments From [EMAIL PROTECTED] 2004-10-06 16:51 ---
Created an a
>
> How do we make sure the drm code that ends up in the currently shipping kernel
> is reasonably stable?
I wait until everyone stops complaining on dri-devel then I give it a good
batch of testing on my own boards (i810/i830/r200/anything else sitting on
my desk...) I then stick it in the drm-2.
Dave Airlie wrote:
Well via isn't shipped as it still (??) has security problems, or if they
are fixed no-one as requested me to pull it up to the kernel yet ...
The via drm still needs command verification checks of the AGP ring-buffer,
the 3D driver to be ported to use the ring-buffer and fina
Hi, Ian.
Ian Romanick wrote:
Since our CVS situation has changed, the policy has also changed. The
docs, unfortunately, have not. As near as I can tell, the situation
is as follows:
- Client-side driver development happens in the Mesa CVS trunk.
Stable code lives in a branch.
- DRM driver d
Hi, Jon.
Jon Smirl wrote:
I'm not sure this trap is in the via driver:
EIP is at __crc_via_fb_free+0x131f4b1b
via just happened to be the closest symbol since it was the last thing
you loaded.
You may be trying to execute the framebuffer.
recompile your kernel with the kernel debug framepointer opt
> Since our CVS situation has changed, the policy has also changed. The docs,
> unfortunately, have not. As near as I can tell, the situation is as follows:
>
> - Client-side driver development happens in the Mesa CVS trunk. Stable code
> lives in a branch.
>
> - DRM driver development happens
On Wed, 2004-10-06 at 13:09, Felix Kühling wrote:
> On Wed, 6 Oct 2004 22:03:40 +0200
> Felix Kühling <[EMAIL PROTECTED]> wrote:
>
> [snip]
> >
> > You're right. Thanks for catching this. I tried to understand what
> > force_emit in the i830 driver was for, now I understand. An updated
> > patch
For debug info:
insmod ./drm.ko drm_opts=debug:on
insmod ./radeon.ko drm_opts=debug:on
I haven't fully writen the code for the new parameters yet. When it is
finished the message will disappear.
Make sure you don't have any old DRM drivers loaded by accident or
compiled into your kernel. If you
José Fonseca wrote:
They happen one after the other so fast that they're never recorded on
/proc/kmsg. I got a screenshot (literaly, with a digital camera) on
http://jrfonseca.dyndns.org/misc/bugs/radeon-core.jpg after insmod'ing
radeon. It's likely that the first oops is within the loaded module,
Thomas Hellstrom wrote:
The last VIA-specific change was done sep 7th. If I check out a sep 8th
drm and compile the via module, at least I can do 4 modprobs and rmmods
before a kernel Oops. The big problem is that users are starting to
report problems also when the X server initializes and they
I just insmod/rmmod'd the current linux-2.6 CVS via driver 30 times
without problem. But I don't have the hardware so it is not fully
initializing.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITMan
I'm not sure this trap is in the via driver:
EIP is at __crc_via_fb_free+0x131f4b1b
via just happened to be the closest symbol since it was the last thing
you loaded.
You may be trying to execute the framebuffer.
recompile your kernel with the kernel debug framepointer option turned
on to get a be
On Wednesday 06 October 2004 06:54, Felix Kühling wrote:
> On Mon, 04 Oct 2004 12:09:09 +0100
>
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
> > John,
> >
> > I'd say the problem is with these lines in savagetris.c:
> >
> >
> >if (index & (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
> >EMIT_ATTR( _
Your fix works!
Thanks, Alex.
On Tue, 2004-10-05 at 14:20, Alex Deucher wrote:
> On Tue, 5 Oct 2004 15:07:22 -0400, Alex Deucher <[EMAIL PROTECTED]> wrote:
> > On Wed, 29 Sep 2004 13:16:44 -0500, Steve Holland <[EMAIL PROTECTED]> wrote:
> > > I downloaded the latest savage and c
On Wed, Oct 06, 2004 at 12:30:01PM -0400, Jon Smirl wrote:
> On Wed, 6 Oct 2004 14:37:14 +0100, José Fonseca
> <[EMAIL PROTECTED]> wrote:
> > Jon,
> >
> > I was trying to build and test the linux-core - I really like what
> > you've been doing there - but I get endless kernel oops after insmod'ing
On Mer, 2004-10-06 at 22:02, Ian Romanick wrote:
> Here's my question. Is there any way to "trick" it into doing
> back-to-back reads as a single PCI transfer? So, if I did something like:
Not that anyone has found. I'm not sure PCI even really allows it except
for prefetchable memory.
Except
Hi!
Now it's back again. After a number of unichrome user complaints I just
compiled the via driver in today's linux-2.6 drm and get a kernel Oops
after doing
modprobe via
rmmod via
The last VIA-specific change was done sep 7th. If I check out a sep 8th
drm and compile the via module, at lea
Alan Cox wrote:
On Mer, 2004-10-06 at 19:36, Ian Romanick wrote:
from video RAM to system RAM. It has to convert the pixel data from its
native, on-card format to RGBA. In the case of my patch, it
converts from BGRA to RGBA while doing the copy. That's why it needs
the SSE2 shift instruct
On Wed, 06 Oct 2004 15:22:08 -0500, Steve Holland <[EMAIL PROTECTED]> wrote:
> Your fix works!
> Thanks, Alex.
>
>
Sounds good. I'll commit the fix tonight and make sure it doesn't
break savage4.
Alex
>
>
> On Tue, 2004-10-05 at 14:20, Alex Deucher wrote:
> > On Tue, 5 Oct 2004 15:0
On Mer, 2004-10-06 at 19:36, Ian Romanick wrote:
> from video RAM to system RAM. It has to convert the pixel data from its
> native, on-card format to RGBA. In the case of my patch, it
> converts from BGRA to RGBA while doing the copy. That's why it needs
> the SSE2 shift instructions.
>
On Wed, 6 Oct 2004 22:03:40 +0200
Felix Kühling <[EMAIL PROTECTED]> wrote:
[snip]
>
> You're right. Thanks for catching this. I tried to understand what
> force_emit in the i830 driver was for, now I understand. An updated
> patch is attached. I'm going to commit that.
Still wrong. Sorry. :-/ I
On Wed, 06 Oct 2004 10:16:23 -0700
Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-10-06 at 04:54, Felix Kühling wrote:
> > On Mon, 04 Oct 2004 12:09:09 +0100
> > Keith Whitwell <[EMAIL PROTECTED]> wrote:
> >
> > > John,
> > >
> > > I'd say the problem is with these lines in savagetris.c:
Alan Cox wrote:
On Mer, 2004-10-06 at 16:56, Dieter NÃtzel wrote:
What about MMX2, 3DNow, 3DNow2 (pro), SSE (1)?
It would be nice if we have this like MPlayer:
Soreen wrote a set of routines for this that are in Xorg 6.8.* and
optimise the readback of video memory for render operations - naturally
Do any of my fellow DRI developers want a AGP savage IX card (8MB)? I
have the same chip in my laptop so I don't really have a use for the
AGP card. If any of you want the card to help in developing/debugging
the savage driver, you are welcome to it. I'll even pay the postage.
Alex
--
On Wed, Oct 06, 2004 at 10:32:57AM -0700, Ian Romanick wrote:
> Ville Syrjälä wrote:
> >On Mon, Oct 04, 2004 at 04:24:19PM -0700, Ian Romanick wrote:
> >
> >>I think the right answer is to apply the fix for reading alpha from the
> >>framebuffer and ignore the 888 modes. Since the hardware is ope
On Mer, 2004-10-06 at 16:56, Dieter NÃtzel wrote:
> What about MMX2, 3DNow, 3DNow2 (pro), SSE (1)?
>
> It would be nice if we have this like MPlayer:
Soreen wrote a set of routines for this that are in Xorg 6.8.* and
optimise the readback of video memory for render operations - naturally
enough t
Ville Syrjälä wrote:
On Mon, Oct 04, 2004 at 04:24:19PM -0700, Ian Romanick wrote:
I think the right answer is to apply the fix for reading alpha from the
framebuffer and ignore the 888 modes. Since the hardware is operating
in mode, pretending to be 888 is just wrong. We'd have to go
thr
On Wed, 2004-10-06 at 09:33, Vladimir Dergachev wrote:
> On Wed, 6 Oct 2004, Dieter [iso-8859-15] Nützel wrote:
>
> > Am Mittwoch, 6. Oktober 2004 03:52 schrieb Ian Romanick:
> >> Here's a simple patch that gives about a 50% (on my box) speed boost to
> >> glReadPixels performance in 24-bit. I me
On Wed, 2004-10-06 at 04:54, Felix Kühling wrote:
> On Mon, 04 Oct 2004 12:09:09 +0100
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
> > John,
> >
> > I'd say the problem is with these lines in savagetris.c:
> >
> >
> >if (index & (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
> >EMIT_ATTR( _TNL
Vladimir Dergachev wrote:
Am Mittwoch, 6. Oktober 2004 03:52 schrieb Ian Romanick:
Here's a simple patch that gives about a 50% (on my box) speed boost to
glReadPixels performance in 24-bit. I measured using the benchmark
built into progs/demos/readpix. The interesting thing is that the core
MMX
On Thu, 7 Oct 2004, Jonathan Adamczewski wrote:
Hi,
After coming across r300.sf.net, I have the following configuration up and
running :
- 9700 pro aiw
- xorg-6.8.0 (patched as per r300.sf.net)
- linux kernel 2.6.9-rc3 (-rc2 patches seem to apply cleanly)
I obtained r300-demo from cvs, but canno
On Wed, 6 Oct 2004, Dieter [iso-8859-15] Nützel wrote:
Am Mittwoch, 6. Oktober 2004 03:52 schrieb Ian Romanick:
Here's a simple patch that gives about a 50% (on my box) speed boost to
glReadPixels performance in 24-bit. I measured using the benchmark
built into progs/demos/readpix. The interesti
On Wed, 6 Oct 2004 14:37:14 +0100, José Fonseca
<[EMAIL PROTECTED]> wrote:
> Jon,
>
> I was trying to build and test the linux-core - I really like what
> you've been doing there - but I get endless kernel oops after insmod'ing
> any of the driver modules (not the common drm one though), regardles
On Wed, 6 Oct 2004 12:14:05 -0400, Jon Smirl <[EMAIL PROTECTED]> wrote:
> I'll revert these to the old DRM(order). One of the kernel developers
> wanted this changed and now I see these functions aren't identical.
This is checked in now.
--
Jon Smirl
[EMAIL PROTECTED]
-
I'll revert these to the old DRM(order). One of the kernel developers
wanted this changed and now I see these functions aren't identical.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJourn
You don't need to copy the DRM files into your kernel tree. Just type
make from the linux-2.6 directory. It you are booted on the kernel you
are building for it will automatically find the kernel source via
/lib/modules.
--
Jon Smirl
[EMAIL PROTECTED]
---
Am Mittwoch, 6. Oktober 2004 03:52 schrieb Ian Romanick:
> Here's a simple patch that gives about a 50% (on my box) speed boost to
> glReadPixels performance in 24-bit. I measured using the benchmark
> built into progs/demos/readpix. The interesting thing is that the core
> MMX & SSE2 routines ca
On Thu, 07 Oct 2004 01:31:18 +1100, Jonathan Adamczewski
<[EMAIL PROTECTED]> wrote:
> Is it possible to run my 9700pro in dual head mode with the radeon driver?
Yes dualhead and mergedfb are supported on r300 chips.
Alex
>
> Thanks.
>
> jonathan.
>
---
Is it possible to run my 9700pro in dual head mode with the radeon driver?
Thanks.
jonathan.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
You
Hi,
After coming across r300.sf.net, I have the following configuration up
and running :
- 9700 pro aiw
- xorg-6.8.0 (patched as per r300.sf.net)
- linux kernel 2.6.9-rc3 (-rc2 patches seem to apply cleanly)
I obtained r300-demo from cvs, but cannot achieve anything but high cpu
utilisation with
Hi dri-devel,
below is an automatically generated message from a failed snapshot
build. Right now only Eric Anholt and myself receive these failure
messages. I wonder if it would be useful to send such failure messages
to dri-devel so that people can notice and fix build failures quickly.
These me
On Wed, Oct 06, 2004 at 09:53:51AM -0400, Vladimir Dergachev wrote:
>
>
> On Wed, 6 Oct 2004, [iso-8859-15] José Fonseca wrote:
>
> >Jon,
> >
> >I was trying to build and test the linux-core - I really like what
> >you've been doing there - but I get endless kernel oops after insmod'ing
> >any o
Oct 5 22:01:59 miller kernel: Linux agpgart interface v0.100 (c) Dave Jones
Oct 5 22:01:59 miller kernel: agpgart: Detected VIA CLE266 chipset
Oct 5 22:01:59 miller kernel: agpgart: Maximum main memory to use for agp memory: 380M
Oct 5 22:01:59 miller kernel: agpgart: AGP aperture is 128M @ 0xd
On Wed, 6 Oct 2004, [iso-8859-15] José Fonseca wrote:
Jon,
I was trying to build and test the linux-core - I really like what
you've been doing there - but I get endless kernel oops after insmod'ing
any of the driver modules (not the common drm one though), regardless
the specific chip is present
On Wed, 6 Oct 2004, Paulo R. Dallan wrote:
On Wednesday 06 October 2004 05:36, Paulo R. Dallan wrote:
On Wednesday 06 October 2004 04:43, you wrote:
Paulo R. Dallan schrieb:
Hi Philipp, thanks for the reply!
Are you sure about that?
I've just tried the "ati" generic driver (option from xorgconfig
Jon,
I was trying to build and test the linux-core - I really like what
you've been doing there - but I get endless kernel oops after insmod'ing
any of the driver modules (not the common drm one though), regardless
the specific chip is present or not.
Before I search deeper into this could you l
On Wed, 6 Oct 2004 05:47:26 -0300, Paulo R. Dallan <[EMAIL PROTECTED]> wrote:
> On Wednesday 06 October 2004 05:36, Paulo R. Dallan wrote:
> > On Wednesday 06 October 2004 04:43, you wrote:
> > > Paulo R. Dallan schrieb:
>
>
>
> > Hi Philipp, thanks for the reply!
> >
> > Are you sure about that
On Tue, 5 Oct 2004 23:40:17 -0300, Paulo R. Dallan <[EMAIL PROTECTED]> wrote:
> On Tuesday 05 October 2004 19:56, Dave Airlie wrote:
>
>
>
> > your still doing soft rendering at a guess... glxinfo and check Direct
> > Rendering: Yes...
> >
> > Dave.
>
> Hi Dave! Thank you for the tip, but I don
On Wed, 6 Oct 2004 13:16:38 +0200, David <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Sep 2004 13:16:44 -0500, Steve Holland <[EMAIL PROTECTED]> wrote:
> > >- My previously reported problem with glDrawPixels is still happens.
> > > Card is S3 Inc. SuperSavage IX/C SDR (rev 05) on ThinkPad T23. The
>
I've just tried the "ati" generic driver (option from xorgconfig) and the
speed got even slower (however, glxinfo also gave me direct rendering: yes!).
Actually, I got a little confused over here.
In the dri/wiki, under the building description, it is described that the
"ati" is the 2D driver
On Wednesday 06 October 2004 05:36, Paulo R. Dallan wrote:
> On Wednesday 06 October 2004 04:43, you wrote:
> > Paulo R. Dallan schrieb:
> Hi Philipp, thanks for the reply!
>
> Are you sure about that?
>
> I've just tried the "ati" generic driver (option from xorgconfig) and the
> speed got even
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> John,
>
> I'd say the problem is with these lines in savagetris.c:
>
>
>if (index & (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
>EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
>EMIT_ATTR
On Wed, 29 Sep 2004 13:16:44 -0500, Steve Holland <[EMAIL PROTECTED]> wrote:
> >- My previously reported problem with glDrawPixels is still happens.
> > Card is S3 Inc. SuperSavage IX/C SDR (rev 05) on ThinkPad T23. The
> > problem seems to be that glDrawPixels doesn't work to the back buffer.
> Tried to reproduce the lockup problem, rebooting and re-starting x - to no
> effect untill now. Anyway, there is still the performance issue (the
> hardware acceleration still is aparently quite "slow").
Ok, some progress here.
Managed to get to the point I was before 400 FPS, and to *repro
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1519
--- Additional Comments From [EMAIL PROTECTED] 2004-10-06 02:18 ---
> Are you s
On Wed, 6 Oct 2004 05:36:02 -0300
"Paulo R. Dallan" <[EMAIL PROTECTED]> wrote:
> On Wednesday 06 October 2004 04:43, you wrote:
> > Paulo R. Dallan schrieb:
>
>
>
> > The radeon driver is a hardware-accelerated driver for Radeon 7500
> > chips. I don't know why it even works on your card.
I th
Paulo R. Dallan schrieb:
Just complementing: "man radeon" gives a list of the PCI and AGP ATI cards
supported by the xorg radeon driver, and the ATI Radeon 9200se is mentioned
there:
RV280 Radeon 9200PRO/9200/9200SE, M9+
So, either the man pages are wrong, or I was indeed using the correct
On Wednesday 06 October 2004 04:43, you wrote:
> Paulo R. Dallan schrieb:
> The radeon driver is a hardware-accelerated driver for Radeon 7500
> chips. I don't know why it even works on your card.
>
> Philipp
Hi Philipp, thanks for the reply!
Are you sure about that?
I've just tried the "ati"
Paulo R. Dallan schrieb:
Another strange thing, as i mentioned before, is that glxgears gives me 400
FPS output, but the drawing is quite slow, while in another machine here i
have 200-250FPS and, at the same time, the drawing seems amazingly fast...
Any suggestion?
The gears turn faster when fr
On Wednesday 06 October 2004 04:23, Paulo R. Dallan wrote:
> Ok, things are getting worse.
> The solution (for have an x-server operational for the moment) was to run
> xorgconfig again and selected the generic *radeon* drive (is it the same as
> the hardware accelerated one?). After this the sy
Paulo R. Dallan schrieb:
Ok, things are getting worse.
After I installed the dri drivers, i had only re-started the x-server - and
acceleration worked but not as expected, as mentioned before.
After a reboot, when trying to start x, i did modprobe radeon (ok), and issued
the startx command. The
Ok, things are getting worse.
After I installed the dri drivers, i had only re-started the x-server - and
acceleration worked but not as expected, as mentioned before.
After a reboot, when trying to start x, i did modprobe radeon (ok), and issued
the startx command. The system locked up. I coul
85 matches
Mail list logo
