Roland Scheidegger wrote:
I suspect that quite the contrary, almost noone has crashes. This is
probably part of the problem, if they happen only for few people with
very specific configurations, none of the developers can reproduce it
and it will just remain unfixed.
For reference, I never get c
Jacob Gorm Hansen wrote:
Roland Scheidegger wrote:
I'm not familiar with Xen, but I heard one of the few drivers which
are problematic with it are the agp drivers. This _could_ be such an
issue. If so the Xen guys are likely to know more about it. That's
really just a guess though.
hi,
yes this
The thing we can (and do) use radeon ioctls from within the driver. So
we can just call the Radeon ioctls directly - no need for R300 version.
This did bite us in the past, and ,probably, still does because of the
need for different "engine idle" sequence for R300.
Ah, I did not realise that we
>
> I fully support the idea of enabling gart texturing on the r200 driver. If
> the old client texturing code can be kept around as an X config option, so
> much the better, but it shouldn't stand in the way of gart texturing given the
> data above.
I think this is all in the client side of the
On Mon, 07 Feb 2005 16:00:54 -0800, Jacob Gorm Hansen <[EMAIL PROTECTED]> wrote:
> All this is running in domain0, the privileged one, and I am not trying
> to share the devices, so that should not be the issue.
The error most likely has to do with mesa not finding DRM's shared
memory segment. The
On Tue, 8 Feb 2005, Ben Skeggs wrote:
Hello Vladimir,
1) It does not appear to be R300 specific - why doesn't similar
Radeon ioctl work ? Also, I would imagine that this would
require a change in r300 driver to work, wouldn't it ?
No, I suspected that it wasn't r30
Jon Smirl wrote:
I believe xen has a mode where you can assign hardware exclusively to
a user kernel. You'll need to do that and then run apg/drm/mesa all in
the same user kernel. Without that I think you need changes to xen or
drm. This is just a guess based on the log, I have not tried running
Xe
On Tue, 08 Feb 2005 00:42:29 +0100, Roland Scheidegger
<[EMAIL PROTECTED]> wrote:
> > Linux agpgart interface v0.100 (c) Dave Jones
> > agpgart: Detected an Intel i875 Chipset.
> > agpgart: Maximum main memory to use for agp memory: 198M
> > agpgart: AGP aperture is 32M @ 0xe000
> > [drm] Initi
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://bugs.freedesktop.org/show_bug.cgi?id=2490
--- Additional Comments From [EMAIL PROTECTED] 2005-02-07 15:57 ---
This
Roland Scheidegger wrote:
I'm not familiar with Xen, but I heard one of the few drivers which are
problematic with it are the agp drivers. This _could_ be such an issue.
If so the Xen guys are likely to know more about it. That's really just
a guess though.
hi,
yes this is likely to do with Xen,
Jacob Gorm Hansen wrote:
hi,
after getting r300 working on my Radeon 9600SE under Linux, I am trying
to make the same thing happen under Xen (in domain0).
However, I get the following error when loading drm.ko:
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel i875 Chipset.
a
Okay can we open a bug on this, attaching xorg.conf and Xorg.0.log to
it...
I'm running r200, both 8500LE and 9200 cards at home and work without
issue, except a recent bug report where if you run
gears/euphoria/gtk-pixbufdemo it locks after a good while (hours...) as
tracking that sort of bug ta
Ian Romanick wrote:
Keith Whitwell wrote:
I'm still working on the age stuff, but the general strategy is to not
release memory back into the pool until it is guarenteed no longer
referenced. This means hanging onto it for a little while until
perhaps the end of a frame or until the next time y
hi,
after getting r300 working on my Radeon 9600SE under Linux, I am trying
to make the same thing happen under Xen (in domain0).
However, I get the following error when loading drm.ko:
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel i875 Chipset.
agpgart: Maximum main memo
Ian Romanick wrote:
Roland Scheidegger wrote:
Keith Whitwell wrote:
- Application calls glTexImage - Mesa allocates AGP/card memory and
copies texture directly to final destination (using memcpy().)
I have a couple questions about this. How does this handle things like
glGetTexImage? What happe
Currently Mesa needs to keep the system memory copy because texture
images in card or agp memory can be clobbered by other apps at any
time - Ian's texture manager will address this.
In the via and sis drivers, texture allocations are permanent, so
I've been able to try a different strategy:
- A
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://bugs.freedesktop.org/show_bug.cgi?id=2489
[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://bugs.freedesktop.org/show_bug.cgi?id=2490
Summary: Max anisotropy of less than 1.0 sets anisotropy to 16.0
Keith Whitwell wrote:
I'm still working on the age stuff, but the general strategy is to not
release memory back into the pool until it is guarenteed no longer
referenced. This means hanging onto it for a little while until perhaps
the end of a frame or until the next time you notice the engine
Adam K Kirchhoff schrieb:
Agreed, for the most part. I use an 8500 and 9200 at work and at home.
I regularly update my Mesa tree and build new version of the r200
driver. The only problems I've experienced is if I leave xscreensaver
up and running all night, randomly choosing from the OpenGL
Roland Scheidegger wrote:
Keith Whitwell wrote:
- Application calls glTexImage - Mesa allocates AGP/card memory and
copies texture directly to final destination (using memcpy().)
I have a couple questions about this. How does this handle things like
glGetTexImage? What happens when there is memo
I might be wrong, but the fglrx driver reported my card as being a
R280. It even ran at 8x AGP (A R280 feature, I've read). However, the
DRI radeon driver reports the cards as being a R250 running at 4x AGP.
I'm using an Acer laptop (Acer Ferrari 3000) with Ati Radeon Mobility
9200 M9+ 128MB.
I'd
Keith Whitwell wrote:
btw texdown showed that texture transfers to card memory are faster
than to AGP memory, but not by very much (something like 100MB/s
vs. 140MB/s in the best case, though the numbers I got fluctuated
quite a bit).
How are AGP texture uploads being done?
The card memory uploa
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://bugs.freedesktop.org/show_bug.cgi?id=2489
Summary: Invalid bound check of driver defined ioctls in
On Mon, 2005-02-07 at 15:11 +0100, [EMAIL PROTECTED] wrote:
> Hardware P4 with SIS chipset:
>
> :00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PC=
> I bridge (AGP) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
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://bugs.freedesktop.org/show_bug.cgi?id=701
--- Additional Comments From [EMAIL PROTECTED] 2005-02-07 12:20 ---
Sound
Roland Scheidegger wrote:
Geller Sandor wrote:
I just removed the AGPFastWrite and DynamicClocks options. The crashes
still happen though.
Looks like not only I have problems with the radeon driver. I update the
X.org, drm, Mesa CVS once a week, but haven't found a working
combination
since 4-5 m
Michel Dänzer <[EMAIL PROTECTED]> writes:
> On Sun, 2005-02-06 at 19:32 +0500, Dimitry Naldayev wrote:
>> Michel Dänzer <[EMAIL PROTECTED]> writes:
>>
>> > FWIW, the infamous radeon DRI reinit patch is at
>> > http://penguinppc.org/~daenzer/DRI/radeon-reinit.diff
>> >
>> look like it is realy no
On Mon, 2005-02-07 at 19:24 +0100, Roland Scheidegger wrote:
> Geller Sandor wrote:
> > I don't intend to start a flame-war, but is there anybody who can use the
> > r200 driver without X crashes? I'm testing X.org CVS regularly (almost on
> > every weekend) with my RV280, with the latest linux 2.6
Geller Sandor schrieb:
1. build and install everything from CVS, if the X server can be crashed,
go to step 2, otherwise be happy :))
2. use the X.org CVS version with the stock kernel's drm, if X still
crashes, go to step 3. Otherwise use the X.org CVS, live without
projected textures...
3. us
Geller Sandor wrote:
I just removed the AGPFastWrite and DynamicClocks options. The crashes
still happen though.
Looks like not only I have problems with the radeon driver. I update the
X.org, drm, Mesa CVS once a week, but haven't found a working combination
since 4-5 months...
I don't intend to
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://bugs.freedesktop.org/show_bug.cgi?id=1707
--- Additional Comments From [EMAIL PROTECTED] 2005-02-07 10:04 ---
Like
Hello Vladimir,
1) It does not appear to be R300 specific - why doesn't similar
Radeon ioctl work ? Also, I would imagine that this would
require a change in r300 driver to work, wouldn't it ?
No, I suspected that it wasn't r300 specific actually, all the code does
Hello Jan,
The patch to the drm shouldn't have actually done anything on it's
own. It requires that r300_ioctl be modified to be of any use at all.
I'll have a look into it some more in the morning.
Ben Skeggs.
Jan Kreuzer wrote:
Hi Ben
your patch seems to solve some of the lockups I experienced (
Ok the oops seems to be related to my sensor monitor (superkaramba), i
disabled it and i get no more oops (although this should not happen).
However i still am not able to get dri working when debugging is enabled
in the drm module (with and without Bens patch).
Here is the output from dmesg:
[dr
On Mon, 7 Feb 2005, Jan Kreuzer wrote:
Hi again
when i try to load the drm module with debug enabled i get the following
message in my syslog (and dri works not in xorg):
Unable to handle kernel NULL pointer dereference at 0018
RIP:
{:radeon:gpio_setsda+20}
Hi Ben,
Thank you for the patch :)
I have two concerns about it:
1) It does not appear to be R300 specific - why doesn't similar
Radeon ioctl work ? Also, I would imagine that this would
require a change in r300 driver to work, wouldn't it ?
2) I w
Hi again
when i try to load the drm module with debug enabled i get the following
message in my syslog (and dri works not in xorg):
Unable to handle kernel NULL pointer dereference at 0018
RIP:
{:radeon:gpio_setsda+20}
PML4 efa6067 PGD e4ce067 PMD 0
Oops: [1] PREEMPT
CPU 0
Modules
On Sun, 6 Feb 2005, Jerome Glisse wrote:
Hi,
I got little prob on ppc i get unknown texture format for
nehe lesson 6-7 (haven't tested other but i guess they have
the same prob). I think that somewhere there is a little
big endian issue (always this :)) because with previous
version i have got the
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://bugs.freedesktop.org/show_bug.cgi?id=1195
--- Additional Comments From [EMAIL PROTECTED] 2005-02-07 07:04 ---
Jim,
Hi Ben
your patch seems to solve some of the lockups I experienced (for example
without your patch i got random lockups after trying some of the nehe
lessons, now i can run most of them fine). However i noticed that xorg
cpu-usage went up to 10% (from around 1%) and that the screen rendering
(2D a
On Monday 07 February 2005 09:11, [EMAIL PROTECTED] wrote:
> (II) SIS(0): Primary V_BIOS segment is: 0xc000=20
> (II) SIS(0): VESA BIOS detected
> (II) SIS(0): VESA VBE Version 3.0
> (II) SIS(0): VESA VBE Total Mem: 16384 kB
> (II) SIS(0): VESA VBE OEM: SiS
> (II) SIS(0): VESA VBE OEM Software Rev:
Am Montag, den 07.02.2005, 15:12 +0100 schrieb [EMAIL PROTECTED]:
> Hardware:
>
> Toshiba Libretto L2 Tm5600 with:
>
> :00:04.0 VGA compatible controller: S3 Inc. 86C270-294=20
> Savage/IX-MV (rev 13) (prog-if 00 [VGA])
> Subsystem: Toshiba America Info Systems: Unknown device 0001
>
Hardware:
Toshiba Libretto L2 Tm5600 with:
:00:04.0 VGA compatible controller: S3 Inc. 86C270-294=20
Savage/IX-MV (rev 13) (prog-if 00 [VGA])
Subsystem: Toshiba America Info Systems: Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
Step
Hardware Celeron 433 with i810 chipset:
:00:00.0 Host bridge: Intel Corp. 82810E DC-133 GMCH [Graphics Memory
Controller Hub] (rev 03)
Subsystem: Intel Corp. 82810E DC-133 GMCH [Graphics Memory Controller
Hub]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr
Hardware P4 with SIS chipset:
:00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PC=
I bridge (AGP) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-=
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- Pa
Keith Whitwell wrote:
Yes, it doesn't make sense to try and incorporate this code at all. The
texstore.c fixes should help with download of argb textures,
otherwise I don't have a lot new to offer...
These are committed now - let me know if they make a difference.
Keith
Felix Kühling wrote:
Am Montag, den 07.02.2005, 12:14 + schrieb Keith Whitwell:
Felix Kühling wrote:
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
btw texdown showed that texture transfers to card memory are faster than
to AGP memory, but not by very much (something like 100M
On Sun, 6 Feb 2005, Richard Stellingwerff wrote:
> On Sun, 06 Feb 2005 13:45:47 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > Does it also happen without either or all of the options in the radeon
> > device section?
>
> I just removed the AGPFastWrite and DynamicClocks options. The crashes
Am Montag, den 07.02.2005, 12:14 + schrieb Keith Whitwell:
> Felix Kühling wrote:
> > Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
> >
> >>>btw texdown showed that texture transfers to card memory are faster than
> >>>to AGP memory, but not by very much (something like 100MB
Felix Kühling wrote:
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
btw texdown showed that texture transfers to card memory are faster than
to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s
in the best case, though the numbers I got fluctuated quite a bit).
Felix Kühling wrote:
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
btw texdown showed that texture transfers to card memory are faster than
to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s
in the best case, though the numbers I got fluctuated quite a bit).
Am Montag, den 07.02.2005, 09:20 + schrieb Keith Whitwell:
> > btw texdown showed that texture transfers to card memory are faster than
> > to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s
> > in the best case, though the numbers I got fluctuated quite a bit).
>
> How
btw texdown showed that texture transfers to card memory are faster than
to AGP memory, but not by very much (something like 100MB/s vs. 140MB/s
in the best case, though the numbers I got fluctuated quite a bit).
How are AGP texture uploads being done?
The card memory uploads are actually done v
Roland Scheidegger wrote:
Since Felix implemented a different heuristics for texture allocation, I
decided to do some measurements on the r100 how fast agp texturing
actually is.
Test conditions are as follows:
Celeron Tualatin [EMAIL PROTECTED] on bx-133 (note this has consequences for AGP
spee
Dnia 06-02-2005, nie o godzinie 14:53 -0500, Adam K Kirchhoff
napisał(a):
> Jacek Rosik wrote:
> >
> >BTW: I have working solution for color but I wonder if this will work
> >with color tiling. Of course offset Would have to be aligned to the
> >closest tile. Can You take a look at it? (It's missin
Dnia 06-02-2005, nie o godzinie 13:02 -0500, Alex Deucher napisał(a):
>
> On Sun, 06 Feb 2005 11:52:54 -0500, Adam K Kirchhoff
> <[EMAIL PROTECTED]> wrote:
> >
> > At one point someone posted to the dri-devel list an idea on how to
> > overcome the 2048x2048 limitation on 3D rendering (for r200
>
57 matches
Mail list logo
