Re: vertex program support in r200 driver - patches
On Thu, 19 Aug 2004 18:40:12 +0200, Philipp Klaus Krause [EMAIL PROTECTED] wrote: Attached are patches to enable support for GL_ARB_vertex_program in the r200 driver. Thats very cool, but does this mean that it is hardware accelerated now? -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex program support in r200 driver - patches
Patrick McFarland schrieb: On Thu, 19 Aug 2004 18:40:12 +0200, Philipp Klaus Krause [EMAIL PROTECTED] wrote: Attached are patches to enable support for GL_ARB_vertex_program in the r200 driver. Thats very cool, but does this mean that it is hardware accelerated now? No, I don't have any Radeon docs and the docs that some dri developers have don't cover programmable vertex processing as far as I know. So it seems we'll neve get any hardware accelerated support on these cards. That isn't really as bad as it seems since when vertex processing is done in software the rest of the graphics pipeline can still be hardware accelerated. I've done some benchmarking with a vertex-transform limited scene with a single directional light with ambient, diffuse and specular and both hardware tcl and a vertex program that does the same (it's the first vertex program I ever wrote, so probably one could write a faster one for the same purpose). On a Radeon 9000 Pro, 2x Athlon MP 2600+ I get these framerates: Hardware tcl: 10.0 fps Vertex program: 2.5 fps Since most programs use fixed-fuction vertex processing for most of the scene and vertex programs only for specific ceffects (water waves, animation of player models, etc) it should be ok. I hope that it gets included in the r200 driver. Philipp Klaus Krause --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI DDX to xorg merge
Ok. I'll describe some experiments I've made with that program:
1) A (very) few artifacts appear on the right side whatever you do.
2) The program starts at 704x480. A black vertical line of about 4 pixels
width is shown on the right side of the image. If you put another window on
top of the left edge of this window, that black line changes its width from
the initial value (4?) to zero.
3) Horizontal stretching (352) seems to have no effect when the vertical size
remains =480 (that misterious vertical line on the right side is also
stretching with the image).
4)However, when you stretch (horizontally) the window to 352 pixels (the half
of the original width) you get a image 1 pixel wide. If you strech it to 351
you get a 2 pixel wide image, 350 - 4 pixels, 349 - 8 pixels, and so on. To
188. When you strech the window to 187 pixels you get similar behavior (one
pixel wide), etc... but this time with some flickering. To 118. Before
reaching this point the resulting image is larger (mosaic) than the original.
117 shows an image of 2 pixels wide.
5) Vertical stretching is causing HEAVY artifacts on the right side of the
image ONLY when you past 703 pixels wide. However 3 zones are showing (the
3rd zone is difficult to see).
--
So, summarizing:
a) Very few artifacts showing on the right side whatever happen.
b) A misteryous black vertical line showing on the right side, however its
width depends on another window covering the left edge.
c) (width = (704/2)) {strange horizontal zomming effects}
d) (width = 704) (height 480) {heavy artifacts on the right side}
I have a Savage4 chip.
Hope this can help.
David.
I've been able to see the same artifacts on my ProsavageDDR
For a b c, I see the same behavior.
For the d case, my artifacts are showing up on the left side not the right.
I'll add some more observations.
I think the black line is the padding in the image between rasterlines.
Shouldn't be there. I don't have a theory for why it is yet.
It now looks to me that the source of our problems is the hardware
scaler. It looks like we are scaling correctly vertically but we get
into a bad place because the horizontal scaling is hosed. Horizontally,
we drive it too strongly for certain ranges.
The source image in our example is 704 x 480.
As I scale the destination window width down, here is what I see.
Widths Description
703-352 Normal image, scaled appropriately.
351-235The image scales, but too much so. At 351 pixels
wide, the image is stretched excessivly such that only one pixel or so
is visible in the destination window. As you continue to shrink the
destination window, the exessive scaling lessens the point that at a
width of 235 or so, the image appears almost normal, there is still some
moderate stretching, however it becomes apparent that you are looking at
the right half of the source image.
234-177 The displayed image switches to show the left half
of the source image. It too is streched, though not excessively. As
you lessen the width, to 177, the image returns to the natural
unstreched appearance.
176-141The pattern expressed in the 351-235 range repeats.
There is a great deal of flickering at this width, however.
140-118The pattern expressed in the 234-177 range repeats.
Still lots of flickering.
etc
The patterns continue at pixel widths representing power of two
divisions of the original width (i.e 1/2, 1/4, 1/8, 1/16, etc)
until it is too small to see anything.
As I scale the width up, for all widths greater than the size of the
source image, the image shows two regions that contain the right half of
the image.
As I scale the image down horizontally, if the width is in the 703-352,
234-177, 140-188, etc, then correct vertical down scaling also occurrs
with destination window height changes.
In the other width ranges (351-235, 176-141, etc) smaller than the
source image witdh and all widths greater than the source width, then
vertical scaling does occur, but there are noticeable image distortions
that occur when the destination height is changed.
On another note, I've found a solution to get gdb pointed at this driver
while it runs so I should be able to test some things out.
begin:vcard
fn:Robert S. Kerr
n:Kerr;Robert
org:Digital Sandbox, Inc.
adr;dom:Suite 501;;12355 Sunrise Valley Drive;Reston;VA;20191
email;internet:[EMAIL PROTECTED]
title:Chief Software Architect
tel;work:703-390-9770
tel;fax:703-390-9778
tel;cell:703-861-0510
url:http://www.dsbox.com
version:2.1
end:vcard
Re: Unichrome DRM ring buffer patch
On Thu, Aug 19, 2004 at 03:26:07PM -0700, Erdi Chen wrote: This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver: DRM_IOCTL_VIA_DMA_INIT DRM_IOCTL_VIA_CMDBUFFER The first call sets up an area in AGP memory that will be used as the ring buffer. The second call copies a command buffer from user space memory to the ring buffer. A few comments to the coding style - nothing to the functionality. [inlining your patch would make it soo much easier to review and comment] 1) Defines are mixed casisng. Usual style is upper case only except if casing match definitions in datasheet. 2) via_dma.c - remove emacs tagging -*- linux-c -*- 3) What's the purpose of #define __NO_VERSION__ 4) viaCheckDma = via_check_dma 5) via_dma_cleanup always return 0. No need to return anything. - Also drop extern in prototype in .h file 6) SetRag2DAGP - no mixed casing - why is vb casted to uint32_t* - vb is of correct type. - Put the define close to the (sole) user 7) viaAlingBuffer - no mixed casing in name - use tabs for indention 8) via_cmdbuf_wait - no mixed casing in name - use tabs for indention 9) In general use tabs for indention 10) What doeis this do? qwPadCount = (CMDBUF_ALIGNMENT_SIZE3) - uint32_t)vb) CMDBUF_ALIGNMENT_MASK) 3); There is _no_ guarantee a pointer will fir into uint_32 Above construction used in several places. 11) via_drm.h - Drop typedef of drm_via_dma_init - Linux style is to _not_ hide when you work with a struct - Same for drm_via_cmdbuffer_t 12) Comment about typedef is also valid for via_drv.h 13) unsigned int dmaLow - I'm suspicious this is OK on 64 bit platforms? Sam --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unichrome DRM ring buffer patch
Thank you for your comments. This is exactly why I didn't rush to check the code into CVS. Sam Ravnborg wrote: On Thu, Aug 19, 2004 at 03:26:07PM -0700, Erdi Chen wrote: This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver: DRM_IOCTL_VIA_DMA_INIT DRM_IOCTL_VIA_CMDBUFFER The first call sets up an area in AGP memory that will be used as the ring buffer. The second call copies a command buffer from user space memory to the ring buffer. A few comments to the coding style - nothing to the functionality. [inlining your patch would make it soo much easier to review and comment] 1) Defines are mixed casisng. Usual style is upper case only except if casing match definitions in datasheet. Defines come from VIA's driver source. I didn't want to make change them. 2) via_dma.c - remove emacs tagging -*- linux-c -*- Sin of code copying. 3) What's the purpose of #define __NO_VERSION__ Came from the i915_dma.c that I've used as a template. I have no idea what it is for. It seems to exist in many drm source files. 4) viaCheckDma = via_check_dma 5) via_dma_cleanup always return 0. No need to return anything. - Also drop extern in prototype in .h file 6) SetRag2DAGP - no mixed casing - why is vb casted to uint32_t* - vb is of correct type. - Put the define close to the (sole) user 7) viaAlingBuffer - no mixed casing in name - use tabs for indention 8) via_cmdbuf_wait - no mixed casing in name - use tabs for indention 9) In general use tabs for indention Much of this code came from the DRI userspace code. I didn't want to make too much change so that the two code bases diff too much. It was much easier to debug in userspace. Once the kernel code works reliably, I will work on style cleanup. 10) What doeis this do? qwPadCount = (CMDBUF_ALIGNMENT_SIZE3) - uint32_t)vb) CMDBUF_ALIGNMENT_MASK) 3); There is _no_ guarantee a pointer will fir into uint_32 Above construction used in several places. qwPadCount is the number of quad-words (inherited from windows driver code) to pad the buffer to meet alignment requirement. I will use dev_priv-dmaLow instead. 11) via_drm.h - Drop typedef of drm_via_dma_init - Linux style is to _not_ hide when you work with a struct - Same for drm_via_cmdbuffer_t Will do. 12) Comment about typedef is also valid for via_drv.h 13) unsigned int dmaLow - I'm suspicious this is OK on 64 bit platforms? dmaLow is an offset. It is not an address. 32 bit is good enough. Sam --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unichrome DRM ring buffer patch
Sam Ravnborg wrote: On Thu, Aug 19, 2004 at 03:26:07PM -0700, Erdi Chen wrote: This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver: DRM_IOCTL_VIA_DMA_INIT DRM_IOCTL_VIA_CMDBUFFER The first call sets up an area in AGP memory that will be used as the ring buffer. The second call copies a command buffer from user space memory to the ring buffer. A few comments to the coding style - nothing to the functionality. [inlining your patch would make it soo much easier to review and comment] 1) Defines are mixed casisng. Usual style is upper case only except if casing match definitions in datasheet. I have no problem at all with the use of mixed case in register defines. This file looks like it is a drop from a third party and was probably autogenerated from a register database. I'd prefer not to subject it to hand-reformatting. Keith --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unichrome DRM ring buffer patch
On Fri, Aug 20, 2004 at 11:32:06AM -0700, Erdi Chen wrote: 3) What's the purpose of #define __NO_VERSION__ Came from the i915_dma.c that I've used as a template. I have no idea what it is for. It seems to exist in many drm source files. I was not sure but google confirmed. __NO_VERSION__ was required in the linux kernel 2.3 days, which has passed even for drm. So it should go in all drivers. No drivers in linux kernel (2.6.8.1 has this definition. 10) What doeis this do? qwPadCount = (CMDBUF_ALIGNMENT_SIZE3) - uint32_t)vb) CMDBUF_ALIGNMENT_MASK) 3); There is _no_ guarantee a pointer will fir into uint_32 Above construction used in several places. qwPadCount is the number of quad-words (inherited from windows driver code) to pad the buffer to meet alignment requirement. Maybe include/linux/kernel-h - ALIGN is usefull here? Sam --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unichrome DRM ring buffer patch
On Fri, Aug 20, 2004 at 07:48:44PM +0100, Keith Whitwell wrote: Sam Ravnborg wrote: On Thu, Aug 19, 2004 at 03:26:07PM -0700, Erdi Chen wrote: This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver: DRM_IOCTL_VIA_DMA_INIT DRM_IOCTL_VIA_CMDBUFFER The first call sets up an area in AGP memory that will be used as the ring buffer. The second call copies a command buffer from user space memory to the ring buffer. A few comments to the coding style - nothing to the functionality. [inlining your patch would make it soo much easier to review and comment] 1) Defines are mixed casisng. Usual style is upper case only except if casing match definitions in datasheet. I have no problem at all with the use of mixed case in register defines. This file looks like it is a drop from a third party and was probably autogenerated from a register database. I'd prefer not to subject it to hand-reformatting. Agree with you here. Copied from a third party is as valid as copied from a data sheet. I expect the third-party allow such copying.. Sam --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 oops
I attached a patch that should fix this problem. Dave, can you and Alex
give it a test. I have very limited programming time at the moment.
Check it in if it looks good.
--- Dave Airlie [EMAIL PROTECTED] wrote:
c040-c043 : eth1
d000-dfff : :00:00.0
e000-e7ff : PCI Bus #01
e000-e7ff : :01:00.0
e000-e059b8bf : vesafb
this is the culprit .. vesafb is loaded...
Jon can you figure out what do in this situation?
Dave.
ff80- : reserved
i am sending the laptop back to ibm so i won't be able to run any
tests for a while. hope this helps.
--alex--
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail = linux/drm_drv.h 1.8 vs edited =
--- 1.8/linux/drm_drv.h Tue Aug 17 11:38:31 2004
+++ edited/linux/drm_drv.h Fri Aug 20 16:37:08 2004
@@ -635,7 +635,7 @@
static int __init drm_init( void )
{
struct pci_dev *pdev = NULL;
- struct pci_driver *pdriver = NULL;
+ struct pci_device_id *pid;
int i;
DRM_DEBUG( \n );
@@ -647,21 +647,26 @@
DRM(mem_init)();
for (i=0; DRM(pciidlist)[i].vendor != 0; i++) {
- pdev = pci_get_subsys(DRM(pciidlist[i]).vendor, DRM(pciidlist[i]).device, DRM(pciidlist[i]).subvendor, DRM(pciidlist[i]).subdevice, NULL);
- if (pdev)
- {
- pdriver = pci_dev_driver(pdev);
- if (pdriver)
- {
-DRM(fb_loaded)=1;
+ pid = DRM(pciidlist[i]);
+
+ /* pass back in pdev to account for multiple identical cards */
+ while ((pdev = pci_get_subsys(pid-vendor, pid-device, pid-subvendor, pid-subdevice, pdev))) {
+ /* is there already a driver loaded, or (short circuit saves work) */
+ /* does something like VesaFB have control of the memory region? */
+ if (pci_dev_driver(pdev) || pci_request_regions(pdev, DRM scan)) {
+/* go into stealth mode */
+DRM(fb_loaded) = 1;
drm_probe(pdev, DRM(pciidlist[i]));
+/* keep looping to get all devices */
+continue;
}
- else
-pci_dev_put(pdev);
+ /* no fbdev or vesadev, put things back and wait for normal probe */
+ pci_release_regions(pdev);
+ pci_dev_put(pdev);
}
}
- if (DRM(fb_loaded)==0)
+ if (DRM(fb_loaded) == 0)
pci_register_driver(drm_driver);
else
DRM_INFO(Used old pci detect: framebuffer loaded\n);
Re: r200 oops
Jon Smirl [EMAIL PROTECTED] writes: I attached a patch that should fix this problem. Dave, can you and Alex give it a test. I have very limited programming time at the moment. Check it in if it looks good. thanks for the patch. i'll test it as soon as i get my laptop back (about a week i would reckon). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Wiki spam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We're getting an extensive amount of Wiki spam recently, from one particular host. I'd like to hack moin.cgi a bit to blacklist this IP but since I'm not listed as a Developer on the sourceforge page I can't ssh in. Would one of the project owners be kind enough to add my sourceforge account (ajaxx) to the Developers list? I've emailed the abuse contact for the offending host - which looks like an open HTTP proxy - but I've not heard anything back yet. Thanks. - - ajax -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBJrgjW4otUKDs0NMRArWHAKDfn1fjsmrhcAXZ5oMRVCX/KzGubACgpODT bhg2I6zpsgKmKwD3pa02xMI= =pYRB -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
On Fri, 2004-08-20 at 19:23, Fernando Pablo Lopez-Lezcano wrote: Here's a new one, this is 2.6.8.1 (NOT 2.4.8.1!, sigh) + voluntary P6, voluntary+kernel preemption enabled, threaded = 0 for the soundcard. ALSA /usr/src/redhat/BUILD/alsa-driver-1.0.6a/alsa-kernel/core/pcm_lib.c:139: XRUN: pcmC0D0p [f8ff9b8f] snd_pcm_period_elapsed+0x36f/0x560 [snd_pcm] [c011eec7] scheduler_tick+0x2b7/0x580 [f88e4fe4] ehci_irq+0xe4/0x300 [ehci_hcd] [f90e1891] snd_ice1712_interrupt+0x171/0x1e0 [snd_ice1712] [c012b2c0] generic_handle_IRQ_event+0x30/0x60 [c0108506] do_IRQ+0x146/0x3b0 [c0106a88] common_interrupt+0x18/0x20 [c01157b8] delay_pmtmr+0x18/0x20 [c0215579] __delay+0x9/0x10 [f88f3aa3] radeon_do_wait_for_fifo+0x43/0x60 [radeon] [f88f3ad2] radeon_do_wait_for_idle+0x12/0x60 [radeon] [f88eefec] radeon_ioctl+0xbc/0x150 [radeon] [f88f5290] radeon_cp_idle+0x0/0xa0 [radeon] [c01968de] sys_ioctl+0x21e/0x3d0 [c01068c9] sysenter_past_esp+0x52/0x71 It looks like the timeout for many Radeon DRI operations is controlled by the dev_priv-usec_timeout value, which is copied from userspace via ioctl in radeon_cp_init. This value can be as large as 100 MSECS! radeon_drv.h:#define RADEON_MAX_USEC_TIMEOUT 10 /* 100 ms */ The driver does not seem to have a default for this, so you need to find the userspace code that is initializing the DRI and find the value it is being set to. Why is this allowed to be so large? Lee --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: No DRM kernel support for i830 ?
On Fri, Aug 13, 2004 at 09:20:54AM -0700, Eric Anholt wrote: On Fri, 2004-08-13 at 01:45, Alexey Dokuchaev wrote: On Thu, Aug 12, 2004 at 02:40:19AM -0700, Eric Anholt wrote: You'll need to use the DDX (i810_drv.o -- the 2d driver) from X.Org CVS to get the i915 support. Note that the next X.Org release should be out in two weeks. Hmm. But files in `xc/programs/Xserver/hw/xfree86/drivers/i810/' dir in CVS have been last modified 2 months ago. Am I looking the wrong place? Grepping in i810/ for '915' also revealed no results. URL I'm using: http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/i810/ Yep, wrong place. Unfortunately, we haven't updated our docs for the correct place, so it's definitely our fault. The i915 DDX was never merged from xorg/XFree86 to DRI. Since then, DRI CVS has merged into X.Org and all further GLX and DDX work will be going on in X.Org. (Also, DRI driver development has moved into Mesa, and DRM development is in DRI CVS's drm module). So basically, DRI CVS is finished. Have compiled X.Org recent sources (2 days ago). Grabbing i810_drv.o (placed in /usr/X11R6/lib/modules/drivers) and i915_dri.so (placed in /usr/X11R6/lib/modules/dri) resulted in lock up. X Log file is empty. i915.ko (DRM module) compiled from DRI CVS's drm module. Any clue? Maybe I need something else from compiled X.Org base to put in my current installation (from ports)? Thanks. ./danfe --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
The delay is very large because this routine is waiting for the
graphics coprocessor to finish an operation. Some of the operations can
take many ms to complete; for example telling the chip to copy 64MB of
memory somewhere. I would think the question should be, how do we wait
on the GPU without killing both audio and video latency.
The problem here is that most graphics commands are very short in
duration. Some of these commands can be issued a million of times per
second. A few commands are much longer running. I don't believe there
is an easy way to tell how long the commands will run.
A better solution might be to loop twenty times to pick up the very
short commands. After 20us switch to a loop that allows the kernel to
schedule. You don't want to immediately schedule since that will kill
graphics performance.
What's the right way to write a loop like this that meets the above
requirements and also satisfies the audio needs?
static int radeon_do_wait_for_idle( drm_radeon_private_t *dev_priv )
{
int i, ret;
dev_priv-stats.boxes |= RADEON_BOX_WAIT_IDLE;
ret = radeon_do_wait_for_fifo( dev_priv, 64 );
if ( ret ) return ret;
for ( i = 0 ; i dev_priv-usec_timeout ; i++ ) {
if ( !(RADEON_READ( RADEON_RBBM_STATUS )
RADEON_RBBM_ACTIVE) ) {
radeon_do_pixcache_flush( dev_priv );
return 0;
}
DRM_UDELAY( 1 );
}
#if RADEON_FIFO_DEBUG
DRM_ERROR( failed!\n );
radeon_status( dev_priv );
#endif
return DRM_ERR(EBUSY);
}
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.4.8.1+P6: radeon, dri xruns
It looks like the timeout for many Radeon DRI operations is controlled by the dev_priv-usec_timeout value, which is copied from userspace via ioctl in radeon_cp_init. This value can be as large as 100 MSECS! radeon_drv.h:#define RADEON_MAX_USEC_TIMEOUT 10 /* 100 ms */ The driver does not seem to have a default for this, so you need to find the userspace code that is initializing the DRI and find the value it is being set to. the current default is 1 usecs from radeon_dri.h in xc/programs/Xserver/hw/xfree86/drivers/ati (Xorg tree) you can use the option CPusecTimeout in your /etc/X11/xorg.conf file to tweak this value .. Previous investigations have found getting the 3D card and soundcard to balance latencies is difficult :-), I think the DRM could do with a bit of profiling on what the average times it takes for the GPU to become idle.. Dave. Why is this allowed to be so large? Lee --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
