On Wed, 2005-02-09 at 02:32 -0500, Vladimir Dergachev wrote:
On Tue, 8 Feb 2005, Michel [ISO-8859-1] Dnzer wrote:
On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote:
Could someone with knowledge of r200_dri explain how vertex buffer
uploads are put into framebuffer memory on r200?
On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote:
Could someone with knowledge of r200_dri explain how vertex buffer
uploads are put into framebuffer memory on r200?
AFAIK they aren't, the only data the radeon and r200 drivers upload to
the framebuffer is textures.
--
Earthling Michel
Michel Dnzer wrote:
On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote:
Could someone with knowledge of r200_dri explain how vertex buffer
uploads are put into framebuffer memory on r200?
AFAIK they aren't, the only data the radeon and r200 drivers upload to
the framebuffer is textures.
On Tue, 8 Feb 2005, Michel [ISO-8859-1] Dnzer wrote:
On Tue, 2005-02-08 at 14:59 +1100, Ben Skeggs wrote:
Could someone with knowledge of r200_dri explain how vertex buffer
uploads are put into framebuffer memory on r200?
AFAIK they aren't, the only data the radeon and r200 drivers upload to
the
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
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
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
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
Hello Vladimir,
I've attached a patch which implements the RADOEN_CMD_DMA_DISCARD ioctl from
the radeon/r200 drm. I thought I'd post here before commiting to cvs in
case I've
done something bad.
Without this, eventually r300AllocDmaRegion will get stuck in a loop
continually calling
drmDMA
14 matches
Mail list logo
