Re: DRM change for R300 DMA
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? AFAIK they aren't, the only data the radeon and r200 drivers upload to the framebuffer is textures. I was mistaken then. So the sizes that Xserver prints during startup is the result of partitioning of AGP memory ? Not sure which ones you mean exactly, but the answer is probably yes anyway. :) Is there are a reason why this could not have been allocated dynamically as needed ? I guess the lack of an appropriate memory manager is a reason... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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 Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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. I didn't think that they were, at least, I couldn't see where it was done and thought I was misunderstanding something. Thankyou for clearing that up. Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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 framebuffer is textures. I was mistaken then. So the sizes that Xserver prints during startup is the result of partitioning of AGP memory ? Is there are a reason why this could not have been allocated dynamically as needed ? thank you ! Vladimir Dergachev -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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 and 3D) stops a short time every second. Also nehe-lesson-16 still produces a hardlock. I will test more with neverball and tuxracer (as i am in x86_64 i could not test 32-bit legacy apps). Greetings Jan --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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] PREEMPT
CPU 0
Modules linked in: md5 ipv6 ide_cd cdrom snd_ioctl32 snd_pcm_oss
snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq usblp joydev
usbmouse usbhid snd_via82xx snd_ac97_codec snd_pcm snd_timer
snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd
soundcore i2c_viapro ehci_hcd uhci_hcd sd_mod sata_promise libata
scsi_mod tuner bttv video_buf firmware_class v4l2_common btcx_risc
videodev evdev usbcore ext3 jbd mbcache eeprom i2c_sensor radeon
i2c_algo_bit i2c_core drm powernow_k8 freq_table processor r8169 crc32
unix
Pid: 13336, comm: sensors Not tainted 2.6.10-gentoo-r7
RIP: 0010:[a004afe4] a004afe4{:radeon:gpio_setsda
+20}
RSP: 0018:01000f303c50 EFLAGS: 00010246
RAX: RBX: 01001e715a50 RCX: ffda
RDX: 0060 RSI: RDI: 01001e715780
RBP: 01001e715790 R08: 01001e715000 R09: 0006
R10: 0051e010 R11: a003cd00 R12: 01001e715790
R13: 0006 R14: 0001 R15: 01001e715790
FS: 002a95b646e0() GS:803d0a40()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0018 CR3: 00101000 CR4: 06e0
Process sensors (pid: 13336, threadinfo 01000f302000, task
01000ef9f270)Stack: a003c028 01000f303d58
a003c4b9 a00f45e8
01000f303d78 000100100100 a00f4828
fffdfe96
01000f303d98 00010020
Call Trace:a003c028{:i2c_algo_bit:i2c_start+40}
a003c4b9{:i2c_algo_bit:bit_xfer+41}
a0034f6b{:i2c_core:i2c_transfer+59}
a0035a51{:i2c_core:i2c_smbus_xfer+1265}
801ad65e{sysfs_lookup+382} 8017dce6{do_lookup
+214}
a0035bd3{:i2c_core:i2c_smbus_read_i2c_block_data+51}
8017d720{generic_permission+208}
8017d7f9{permission+41}
a0035548{:i2c_core:i2c_check_functionality+8}
a005b13d{:eeprom:eeprom_read+317}
801ae491{read+145}
8016fd96{vfs_read+214} 80170073{sys_read+83}
8010d376{system_call+126}
Code: 48 03 50 18 8b 02 25 ff ff fe ff 89 c1 81 c9 00 00 01 00 85
RIP a004afe4{:radeon:gpio_setsda+20} RSP 01000f303c50
CR2: 0018
Anyone knows what this means ?
Uname -a output:
Linux rockerduck 2.6.10-gentoo-r7 #1 Sun Feb 6 11:49:23 CET 2005 x86_64
AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
Cheers Jan
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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 was able to play Quake for somewhat prolonged periods, I don't think this would have really worked if aging was truly broken, though, maybe, I am wrong on this one. Would you have a test app that shows brokenness ? Perhaps something that uses a lot of textures once. Also, if aging does not work on your setup, it might have to do with amount of system RAM and memory controller settings. I *was* wondering why fbLocation is 0 for R300. If so, this needs to be fixed in the 2d driver. best Vladimir Dergachev On Sun, 6 Feb 2005, Ben Skeggs wrote: 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 (r300_ioctl.c::r300RefillCurrentDmaRegion). It seems that the drm buffer management code depends on having a scratch register containing the age of a buffer. I'm not sure of the details, I just know that it stops the infinite drmDMA loop. Is this the correct way of fixing this? Or have I completely missed something? Regards, Ben Skeggs. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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}
^^
This is I2C code, probably something to do with DDC. Nothing to do with 3d
or R300. Could be that you need a different kernel version or something.
Alternatively, you might need to do make clean - if some headers have
changed, for example, and did not trigger dependency for some reason.
best
Vladimir Dergachev
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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: [drm:drm_stub_open] [drm:drm_open_helper] pid = 14658, minor = 0 [drm:drm_setup] [drm:drm_ioctl] pid=14658, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1 [drm:drm_release] open_count = 1 [drm:drm_release] pid = 14658, device = 0xe200, open_count = 1 [drm:drm_fasync] fd = -1, device = 0xe200 [drm:drm_takedown] [drm:radeon_do_cleanup_cp] [drm:drm_ati_pcigart_cleanup] *ERROR* no scatter/gather memory! [drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART! [drm:drm_stub_open] [drm:drm_open_helper] pid = 14658, minor = 0 [drm:drm_setup] [drm:drm_ioctl] pid=14658, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1 [drm:drm_release] open_count = 1 [drm:drm_release] pid = 14658, device = 0xe200, open_count = 1 [drm:drm_fasync] fd = -1, device = 0xe200 [drm:drm_takedown] [drm:radeon_do_cleanup_cp] [drm:drm_ati_pcigart_cleanup] *ERROR* no scatter/gather memory! [drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART! [drm:drm_stub_open] [drm:drm_open_helper] pid = 14658, minor = 0 [drm:drm_setup] [drm:drm_ioctl] pid=14658, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0106401, nr=0x01, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0106401, nr=0x01, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0106407, nr=0x07, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0x, size = 0x2000, type = 2 [drm:drm_addmap] 8192 13 ff1f6000 [drm:drm_mmap] start = 0x2a9e274000, end = 0x2a9e276000, offset = 0xff1f6000 [drm:drm_vm_open] 0x2a9e274000,0x2000 [drm:drm_do_vm_shm_nopage] shm_nopage 0x2a9e274000 [drm:drm_do_vm_shm_nopage] shm_nopage 0x2a9e275000 [drm:drm_ioctl] pid=14658, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0xb000, size = 0x0800, type = 0 [drm:drm_addmap] Looking for: offset = 0xb000, size = 0x0800, type = 0 [drm:drm_addmap] Checking: offset = 0xff1f6000, size = 0x2000, type = 2 [drm:drm_addmap] Checking: offset = 0xb000, size = 0x1000, type = 0 [drm:drm_addmap] Found existing: offset = 0xb000, size = 0x0800, type = 0 [drm:drm_ioctl] pid=14658, cmd=0xc0106426, nr=0x26, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0106426, nr=0x26, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0xc0406400, nr=0x00, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0x6430, nr=0x30, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0x80386433, nr=0x33, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0x80386433, nr=0x33, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0x80386433, nr=0x33, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0x40086432, nr=0x32, dev 0xe200, auth=1 agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: X passes broken AGP3 flags (1f000a0f). Fixed. agpgart: Putting AGP V3 device at :00:00.0 into 8x mode agpgart: Putting AGP V3 device at :01:00.0 into 8x mode [drm:drm_ioctl] pid=14658, cmd=0xc0206434, nr=0x34, dev 0xe200, auth=1 [drm:drm_ioctl] pid=14658, cmd=0x40106436, nr=0x36, dev 0xe200, auth=1 [drm:drm_agp_bind] base = 0xd000 entry-bound = 0xd000 [drm:drm_ioctl] pid=14658, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0x, size = 0x00101000, type = 3 [drm:drm_mmap] start = 0x2a9e276000, end = 0x2a9e377000, offset = 0xd000 [drm:drm_mmap]Type = 3; start = 0x2a9e276000, end = 0x2a9e377000, offset = 0xd000 [drm:drm_vm_open] 0x2a9e276000,0x00101000 [drm:drm_ioctl] pid=14658, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0x00101000, size = 0x1000, type = 3 [drm:drm_mmap] start = 0x2a9e377000, end = 0x2a9e378000, offset = 0xd0101000 [drm:drm_mmap]Type = 3; start = 0x2a9e377000, end = 0x2a9e378000, offset = 0xd0101000 [drm:drm_vm_open] 0x2a9e377000,0x1000 [drm:drm_ioctl] pid=14658, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0x00102000, size = 0x0020, type = 3 [drm:drm_mmap] start = 0x2a9e378000, end = 0x2a9e578000, offset = 0xd0102000 [drm:drm_mmap]Type = 3; start = 0x2a9e378000, end = 0x2a9e578000, offset = 0xd0102000 [drm:drm_vm_open] 0x2a9e378000,0x0020 [drm:drm_ioctl] pid=14658, cmd=0xc0286415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap] offset = 0x00302000, size = 0x004e, type = 3 [drm:drm_mmap] start = 0x2a9e578000, end = 0x2a9ea58000, offset = 0xd0302000 [drm:drm_mmap]Type = 3; start = 0x2a9e578000, end = 0x2a9ea58000, offset
Re: DRM change for R300 DMA
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 (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 and 3D) stops a short time every second. Also nehe-lesson-16 still produces a hardlock. I will test more with neverball and tuxracer (as i am in x86_64 i could not test 32-bit legacy apps). Greetings Jan --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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 is
write to a scratch register. So perhaps I should've just hooked up
a R300_* ioctl number to the radeon code.
2) I was able to play Quake for somewhat prolonged periods,
I don't think this would have really worked if aging was
truly broken, though, maybe, I am wrong on this one.
Would you have a test app that shows brokenness ? Perhaps
something that uses a lot of textures once.
It only seems to occur after the reference counts for all the dma
buffers hit
zero. After that, no more r300AllocDmaRegion calls are successful.
The code I was referring to was r300_dri hacked up to use r300AllocDmaRegion
to grab buffers for vertex data, rather than using rsp-gartTextures.map to
store the data. It was just a little experiment I was trying, I've
attached a diff
so you can see what happens for yourself, I may have missed something
important.
In r300ReleaseDmaRegion there is a #if/#endif to either use the ioctl or
not.
One more thing, I'm not sure how to find the gart offset of the
vertex/indirect
buffers, I've been hardcoding the value for now (r300_ioctl.h::GET_START),
you may need to look in your X log for the handle as it might differ
from mine.
glxgears looks a little broken using this aswell, I have some random
colours across the faces of the gears.
Anyhow, it was a little experiment I was doing to see how to implement
vertex buffers.
Ben Skeggs.
diff -Nur orig/r300_context.h mod/r300_context.h
--- orig/r300_context.h 2005-02-04 04:48:32.0 +1100
+++ mod/r300_context.h 2005-02-05 04:08:09.0 +1100
@@ -96,7 +96,11 @@
drmBufPtr buf;
};
-#define GET_START(rvb) (rmesa-radeon.radeonScreen-gart_buffer_offset +
\
+//#define GET_START(rvb) (rmesa-radeon.radeonScreen-gart_buffer_offset +
\
+ (rvb)-address - rmesa-dma.buf0_address + \
+ (rvb)-start)
+
+#define GET_START(rvb) (0xe0102000 + \
(rvb)-address - rmesa-dma.buf0_address + \
(rvb)-start)
diff -Nur orig/r300_ioctl.c mod/r300_ioctl.c
--- orig/r300_ioctl.c 2005-02-02 02:46:23.0 +1100
+++ mod/r300_ioctl.c2005-02-08 03:02:21.0 +1100
@@ -414,7 +414,7 @@
if (rmesa-dma.flush)
rmesa-dma.flush(rmesa);
-
+#if 1
if (--region-buf-refcount == 0) {
drm_radeon_cmd_header_t *cmd;
@@ -424,13 +424,15 @@
cmd =
(drm_radeon_cmd_header_t *) r300AllocCmdBuf(rmesa,
- sizeof(*cmd),
+ sizeof(*cmd) /
4,
__FUNCTION__);
- cmd-dma.cmd_type = RADEON_CMD_DMA_DISCARD;
+ cmd-dma.cmd_type = R300_CMD_DMA_DISCARD;
cmd-dma.buf_idx = region-buf-buf-idx;
FREE(region-buf);
+
rmesa-dma.nr_released_bufs++;
}
+#endif
region-buf = 0;
region-start = 0;
diff -Nur orig/r300_render.c mod/r300_render.c
--- orig/r300_render.c 2005-02-04 06:51:57.0 +1100
+++ mod/r300_render.c 2005-02-08 03:10:41.149064384 +1100
@@ -381,6 +381,8 @@
/* vertex buffer implementation */
/* We use the start part of GART texture buffer for vertices */
+ static struct r300_dma_region rvb[8];
+ static int nr_rvb = 0;
static void upload_vertex_buffer(r300ContextPtr rmesa, GLcontext *ctx)
@@ -394,33 +396,38 @@
/* A hack - we don't want to overwrite vertex buffers, so we
just use AGP space for them.. Fix me ! */
+#if 0
static int offset=0;
if(offset2*1024*1024){
//fprintf(stderr, Wrapping agp vertex buffer offset\n);
offset=0;
}
+#endif
+
/* Not the most efficient implementation, but, for now, I just want
something that
works */
/* to do - make single memcpy per column (is it possible ?) */
/* to do - use dirty flags to avoid redundant copies */
#define UPLOAD_VECTOR(v)\
{ \
+ r300AllocDmaRegion(rmesa, rvb[nr_rvb], v-stride*VB-Count,
4); \
/* Is the data dirty ? */ \
if (v-flags ((1v-size)-1)) { \
/* fprintf(stderr, size=%d vs stride=%d\n, v-size,
v-stride); */ \
if(v-size*4==v-stride){\
/* fast path */ \
- memcpy(rsp-gartTextures.map+offset, v-data,
v-stride*VB-Count); \
+
Re: DRM change for R300 DMA
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 r300 specific actually, all the code does is write to a scratch register. So perhaps I should've just hooked up a R300_* ioctl number to the radeon code. 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. 2) I was able to play Quake for somewhat prolonged periods, I don't think this would have really worked if aging was truly broken, though, maybe, I am wrong on this one. Would you have a test app that shows brokenness ? Perhaps something that uses a lot of textures once. It only seems to occur after the reference counts for all the dma buffers hit zero. After that, no more r300AllocDmaRegion calls are successful. AFAIK, r300AllocDMA region allocates one of a several predefined buffers (you can see them printed by r300_demo), so if you do not free them there is nothing more to allocate. I could be completely off on this one though - I can't look at the actual code at the moment and might have confused functions. With regard to vertex buffers - these are in framebuffer memory, not in AGP one on R200 hardware (at least this was my understanding). best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM change for R300 DMA
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 could (and do) just call the radeon ioctls. AFAIK, r300AllocDMA region allocates one of a several predefined buffers (you can see them printed by r300_demo), so if you do not free them there is nothing more to allocate. They do get freed at the end of r300_run_vb_render. r300ReleaseDmaRegion is the function which calls the ioctl. I could be completely off on this one though - I can't look at the actual code at the moment and might have confused functions. With regard to vertex buffers - these are in framebuffer memory, not in AGP one on R200 hardware (at least this was my understanding). r200EmitArrays (which does much that same as upload_vertex_buffer in r300_dri) uses the alloc/release dma calls to grab the regions. Could someone with knowledge of r200_dri explain how vertex buffer uploads are put into framebuffer memory on r200? I had just assumed that the driver told r200 of the address of the buffer acquired from AllocDma. I've mostly likely got something very confused here. Thanks, Ben Skeggs. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
