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
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
On Wednesday 06 October 2004 04:23, Paulo R. Dallan wrote:
Ok, things are getting worse.
snip
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
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
On Wednesday 06 October 2004 04:43, you wrote:
Paulo R. Dallan schrieb:
snip
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:
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 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:
snip
The radeon driver is a hardware-accelerated driver for Radeon 7500
chips. I don't know why it even works on your card.
I think
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
snip
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).
snip
Ok, some progress here.
Managed to get to the point I was before 400 FPS, and to
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.
For
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 Wednesday 06 October 2004 05:36, Paulo R. Dallan wrote:
On Wednesday 06 October 2004 04:43, you wrote:
Paulo R. Dallan schrieb:
snip
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
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 for
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
problem
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:
snip
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't think
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:
snip
Hi Philipp, thanks for the reply!
Are you sure about that?
I've
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
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:
snip
Hi Philipp, thanks for the reply!
Are you sure about that?
I've just tried the ati generic driver (option from
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
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 @
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 of the driver
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
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
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
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.
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 can be
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]
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
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]
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), regardless
the
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
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
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 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_ATTRIB_COLOR1,
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 measured
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
On Mer, 2004-10-06 at 16:56, Dieter Ntzel 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 they
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 operating
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
Alan Cox wrote:
On Mer, 2004-10-06 at 16:56, Dieter Ntzel 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
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:
if
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 can't
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.
From
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:07:22
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
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
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 of
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
any of
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 common
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( _TNL_ATTRIB_COLOR1,
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
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
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
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
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 is attached.
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 in the
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
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
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
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.6
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
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=1519
--- Additional Comments From [EMAIL PROTECTED] 2004-10-06 17:03 ---
(In reply
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:05
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
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
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?
Yes dualhead and mergedfb are
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 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:
snip
I suggest you take a look at
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
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
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
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 glxinfo.
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 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 Tuesday 05
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
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 again
78 matches
Mail list logo
