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
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 missing some
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
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
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 are AGP
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, 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/s vs.
On Sun, 6 Feb 2005, Richard Stellingwerff wrote:
On Sun, 06 Feb 2005 13:45:47 -0500, Michel Dnzer [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
still
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
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
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-
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-
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-=
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
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: 1.0
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
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 ---
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
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:
a004afe4{:radeon:gpio_setsda+20}
PML4 efa6067 PGD e4ce067 PMD 0
Oops: [1]
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
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:
a004afe4{:radeon:gpio_setsda+20}
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:
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
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
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 ---
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
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.
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
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 not best way do
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
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 ---
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=2489
Summary: Invalid bound check of driver defined ioctls in
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
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.
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
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
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
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
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
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:
-
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
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
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
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
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.
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
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 ---
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] Initialized drm
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
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
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. There
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
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
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
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
57 matches
Mail list logo
