From: Michael Z. <zmi...@po...> - 2001-09-23 08:10:39
|
> > > 1) theoretic: Why at all drm needs IRQ i.e. does AGP sends info back to > > > the driver? > > > > The irq is removed in the mesa-3-5 branch. If you feel ok about > downloading, > > compiling and installing a cvs branch, you might be able rid of the > problem > > that way. However, I don't know if Jeff has left the i810 driver in a > working > > state... > Can I remove irq from the current branch? I have no option in BIOS that will disable IRQ for video, but If I had I suppose that DRM would manage with that. Can I simulate "no irq available"? > > > 2) practical: AFAIK BIOS is in charge of setting IRQs, but the only > > > thing my AWARD bios enables to set for each IRQ is whether it is > > > Plug-n-Play or Reserved. How do I rearrange PCI cards IRQs? > > > > Open the box up, take out your ethernet card and put it in another slot. > > The problem is that the ethercard is on-board :( Michael |
From: Keith W. <ke...@va...> - 2001-09-23 13:54:08
|
Michael Zayats wrote: > > > > > 1) theoretic: Why at all drm needs IRQ i.e. does AGP sends info back > to > > > > the driver? > > > > > > The irq is removed in the mesa-3-5 branch. If you feel ok about > > downloading, > > > compiling and installing a cvs branch, you might be able rid of the > > problem > > > that way. However, I don't know if Jeff has left the i810 driver in a > > working > > > state... > > > > Can I remove irq from the current branch? I have no option in BIOS that > will > disable IRQ for video, but If I had I suppose that DRM would manage with > that. Can I simulate "no irq available"? Turning off the irq in hardware won't help you, you need to have a kernel module that doesn't rely on the irq. The i810 kernel module *will* share irqs with other devices, but it sounds like your network card won't. If you are capable of it, consider looking at the i810 driver in the -3-5 branch and seeing what it does differently where the trunk references irq's. Keith |
From: Michael Z. <zmi...@re...> - 2001-09-23 15:07:41
|
> Turning off the irq in hardware won't help you, you need to have a kernel > module that doesn't rely on the irq. The i810 kernel module *will* share irqs > with other devices, but it sounds like your network card won't. The message I get is: (II) I810(0): [drm] failure adding irq handler, there is a device already using that irq It doesn't seem to be a problem of the ethercard, besides everything functions properly in Windows (although I didn't try to do anything AGP related) BTW Windows doesn't show any IRQ for video card... > |
From: jhartmann <jha...@am...> - 2001-09-24 03:49:38
|
Keith Whitwell wrote: > > > Can I remove irq from the current branch? I have no option in BIOS that > > will > > disable IRQ for video, but If I had I suppose that DRM would manage with > > that. Can I simulate "no irq available"? > > Turning off the irq in hardware won't help you, you need to have a kernel > module that doesn't rely on the irq. The i810 kernel module *will* share irqs > with other devices, but it sounds like your network card won't. > > If you are capable of it, consider looking at the i810 driver in the -3-5 > branch and seeing what it does differently where the trunk references irq's. > He is using the 4.1.0 release, thats the problem as far as I can tell. -Jeff |
From: Keith W. <kei...@ya...> - 2001-09-24 04:17:28
|
On Sun, 23 Sep 2001 21:48, you wrote: > Keith Whitwell wrote: > > > Can I remove irq from the current branch? I have no option in BIOS > > > that will > > > disable IRQ for video, but If I had I suppose that DRM would manage > > > with that. Can I simulate "no irq available"? > > > > Turning off the irq in hardware won't help you, you need to have a kernel > > module that doesn't rely on the irq. The i810 kernel module *will* share > > irqs with other devices, but it sounds like your network card won't. > > > > If you are capable of it, consider looking at the i810 driver in the -3-5 > > branch and seeing what it does differently where the trunk references > > irq's. > > He is using the 4.1.0 release, thats the problem as far as I can tell. Why should that be a problem? Is that problem fixed later? Keith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Regard I. <zmi...@re...> - 2001-09-30 13:51:06
|
Does current i810 drm accelerate 2D path? I get about 6mln pps in drawpix :( Michael |
From: Keith W. <kei...@ya...> - 2001-09-30 14:01:15
|
On Sun, 30 Sep 2001 07:50, Regard Inbox wrote: > Does current i810 drm accelerate 2D path? > No. Keith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Michael Z. <zmi...@re...> - 2001-09-30 14:03:55
|
----- Original Message ----- From: Keith Whitwell <kei...@ya...> To: <dri...@li...>; Regard Inbox <zmi...@re...> Sent: Sunday, September 30, 2001 3:59 PM Subject: Re: [Dri-devel] glDrawPixels on i810 > On Sun, 30 Sep 2001 07:50, Regard Inbox wrote: > > Does current i810 drm accelerate 2D path? > > > > No. mesa 3.5 version? > > Keith > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > |
From: Keith W. <kei...@ya...> - 2001-09-30 14:24:14
|
On Sun, 30 Sep 2001 09:06, you wrote: > ----- Original Message ----- > From: Keith Whitwell <kei...@ya...> > To: <dri...@li...>; Regard Inbox <zmi...@re...> > Sent: Sunday, September 30, 2001 3:59 PM > Subject: Re: [Dri-devel] glDrawPixels on i810 > > > On Sun, 30 Sep 2001 07:50, Regard Inbox wrote: > > > Does current i810 drm accelerate 2D path? > > > > No. > > mesa 3.5 version? No. It's a difficult problem on consumer hardware and there isn't an obvious path on the i810 to accelerate it. The DMA buffers and the frame buffer are in a unified memory pool, so it isn't any quicker to put the data into DMA and then have hardware upload it. Very little consumer hardware provides support for the operations necessary to implement much of drawpixels anyway. Keith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Michael Z. <zmi...@re...> - 2001-09-30 14:41:23
|
so what approach should be faster: just Xlib or DrawPixels + DRI? ----- Original Message ----- From: Keith Whitwell <kei...@ya...> To: <dri...@li...> Sent: Sunday, September 30, 2001 4:22 PM Subject: Re: [Dri-devel] glDrawPixels on i810 > On Sun, 30 Sep 2001 09:06, you wrote: > > ----- Original Message ----- > > From: Keith Whitwell <kei...@ya...> > > To: <dri...@li...>; Regard Inbox <zmi...@re...> > > Sent: Sunday, September 30, 2001 3:59 PM > > Subject: Re: [Dri-devel] glDrawPixels on i810 > > > > > On Sun, 30 Sep 2001 07:50, Regard Inbox wrote: > > > > Does current i810 drm accelerate 2D path? > > > > > > No. > > > > mesa 3.5 version? > > No. > > It's a difficult problem on consumer hardware and there isn't an obvious path > on the i810 to accelerate it. The DMA buffers and the frame buffer are in a > unified memory pool, so it isn't any quicker to put the data into DMA and > then have hardware upload it. Very little consumer hardware provides support > for the operations necessary to implement much of drawpixels anyway. > > Keith > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: Michael Z. <zmi...@re...> - 2001-09-30 14:57:02
|
> The DMA buffers and the frame buffer are in > a > > unified memory pool, so it isn't any quicker to put the data into DMA and > > then have hardware upload it. Very little consumer hardware provides > support > > for the operations necessary to implement much of drawpixels anyway. what about glPixelsZoom? I would have been very pleased to see it hardware accelerated... > > > > Keith > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > _______________________________________________ > > Dri-devel mailing list > > Dri...@li... > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: ralf w. <b_...@gm...> - 2001-09-30 15:28:26
|
Michael Zayats wrote: > > what about glPixelsZoom? I would have been very pleased to see it hardware > accelerated... > when the pixmap wont change i would load it as a texture and draw it as a quad. if its changing use gltexsubimage to update it. i dont think its a special path for the 810 driver but it could run faster in other implementations. -- ralf willenbacher (bj...@oc...) |
From: Marcelo E. M. <mar...@bi...> - 2001-09-30 20:09:49
|
>> Keith Whitwell <kei...@ya...> writes: > Very little consumer hardware provides support for the operations > necessary to implement much of drawpixels anyway. Could you please elaborate on this? As someone who has suffered because of poor glDrawPixels and glReadPixels performance in the past but has never seen a good technical explanation for that, I'm interested in the details, if you are willing to at least sketch them. Is it really a pure hardware problem? Rumors on comp.graphics.opengl are that the vendors don't invest time optimizing that path (in the driver) because there's not much demand for it. The Radeon driver performs acceptably well (contrast with the mga driver, which is 10x slower, IIRC) but it doesn't hit the maximum speed allowable by the PCI bus. Could it be faster or the current implementation opmital for that particular hardware? TIA, -- Marcelo |
From: Allen A. <ak...@po...> - 2001-09-30 20:33:52
|
On Sun, Sep 30, 2001 at 10:09:47PM +0200, Marcelo E. Magallon wrote: | Is it really a pure hardware problem? Rumors on comp.graphics.opengl | are that the vendors don't invest time optimizing that path (in the | driver) because there's not much demand for it. ... Most consumer-level hardware doesn't support the esoteric functions in the pixel path, but there's no hardware reason for the most common case (data format matches the window pixel format; no scale/bias, convolutions, scaling, etc.) to be slow. It's trickier than you might think to get the data formats to match the window exactly, and many driver writers for consumer-level cards *are* reluctant to optimize a function that they believe will never be used by their largest market (games). But my experience in the workstation world is that if the pixel path is optimized for the straightforward cases, people use it heavily. Allen |
From: Marcelo E. M. <mar...@bi...> - 2001-09-30 22:15:08
|
>> Allen Akin <ak...@po...> writes: > Most consumer-level hardware doesn't support the esoteric functions > in the pixel path, but there's no hardware reason for the most common > case (data format matches the window pixel format; no scale/bias, > convolutions, scaling, etc.) to be slow. That's my point. Using the DRI drivers in 4.0.1 (I'm sorry, those are the numbers I have handy at the moment) with a G400 I can see something like 1-2 Mp/s (2-4 MB/s, ~ 1-2 fullscreen/s) in the common/best case for glReadPixels without any kind of pixel transformation. The Radeon pulls 10x as much, IIRC. So, is that a hardware problem (somehow I don't think so, the card doesn't seem to have a problem handling fullscreen video at 20 fps or whereabouts) or is it a driver problem? > It's trickier than you might think to get the data formats to match > the window exactly Yes, that I understand. -- Marcelo |
From: Daryll S. <da...@da...> - 2001-09-30 21:30:31
|
On Sun, Sep 30, 2001 at 10:09:47PM +0200, Marcelo E. Magallon wrote: > >> Keith Whitwell <kei...@ya...> writes: > > > Very little consumer hardware provides support for the operations > > necessary to implement much of drawpixels anyway. > > Could you please elaborate on this? As someone who has suffered > because of poor glDrawPixels and glReadPixels performance in the past > but has never seen a good technical explanation for that, I'm > interested in the details, if you are willing to at least sketch them. > Is it really a pure hardware problem? Rumors on comp.graphics.opengl > are that the vendors don't invest time optimizing that path (in the > driver) because there's not much demand for it. The Radeon driver > performs acceptably well (contrast with the mga driver, which is 10x > slower, IIRC) but it doesn't hit the maximum speed allowable by the PCI > bus. Could it be faster or the current implementation opmital for that > particular hardware? On the i810, the problem is that it only does triangles. There is no easy to glDrawPixels in an efficient way. In general, the issue with consumer boards is that it isn't a path they care about. You can replace "path they care about" with "path used in a high selling game." In older chips the hardware didn't support any acceleration. In professional drivers, it is more of an issue and often accelerated. Most of our drivers do accelerate it. We even did an AGP extension which really makes it scream. Depending on what you're doing, texture mapping a quad can be a fast substitute for glDrawPixels. Getting even close to PCI bus is probably as good as it gets. The AGP extension (on the G400) screams. We demonstrated writes at 500MB/s on an AGP 2x card. Compaq funded that work, by the way. - |Daryll |
From: Michael Z. <zmi...@po...> - 2001-10-03 07:44:17
|
I will present my problem in it's full, may be you will help me: I am grabbing frames from bt848 and should both store them for future reuse and get them on the screen. The box is i810 based and has many other tasks to do. putting video on a screen should be fast and very low CPU consuming. what pisses off my boss is that in Windows using DirectShow we get any resolution we want with 2-3% of CPU. Is it someway copying bytes from the grabber to the video card via PCI/DMA without using CPU on it's way? Can I achieve something like it on Linux with or without DRI? Michael |
From: ralf w. <b_...@gm...> - 2001-10-04 18:39:17
|
Michael Zayats wrote: > > I will present my problem in it's full, may be you will help me: > > I am grabbing frames from bt848 and should both store them for future reuse > and get them on the screen. The box is i810 based and has many other tasks > to do. > putting video on a screen should be fast and very low CPU consuming. > > what pisses off my boss is that in Windows using DirectShow we get any > resolution we want with 2-3% of CPU. Is it someway copying bytes from the > grabber to the video card via PCI/DMA without using CPU on it's way? > > Can I achieve something like it on Linux with or without DRI? > > Michael > all info about v4l.. http://roadrunner.swansea.uk.linux.org/v4l.shtml the bt8x8 can copy a frame directly to the framebuffer. dont know about capturing at the same time though. looks like dri is not an efficient way to do it. -- ralf willenbacher (bj...@oc...) |
From: Nathan H. <na...@ma...> - 2001-10-04 22:08:43
|
On Wed, Oct 03, 2001 at 10:47:08AM +0200, Michael Zayats wrote: > I will present my problem in it's full, may be you will help me: > > I am grabbing frames from bt848 and should both store them for future reuse > and get them on the screen. The box is i810 based and has many other tasks > to do. > putting video on a screen should be fast and very low CPU consuming. > > what pisses off my boss is that in Windows using DirectShow we get any > resolution we want with 2-3% of CPU. Is it someway copying bytes from the > grabber to the video card via PCI/DMA without using CPU on it's way? > > Can I achieve something like it on Linux with or without DRI? Yes. It's called V4L (Video 4 Linux) and the mode you want is called OVERLAY. All the standard TV applications for Linux (eg, xawtv) have support for this mode. What you are doing is called GRABBING and you have already found out that it's CPU intensive. In OVERLAY mode the bt848 becomes the PCI master and writes directly into the framebuffer. You'll need a memory mapped PCI video card, of course. Keep in mind that although the CPU usage is low, an 848 will consume a large portion of your PCI bus bandwidth. V4L is completely independent of DRI. Now if you want to put data from system memory to the video screen I suggest you look at XV (X Video). It can do various colour expansion techniques in hardware (eg, YUV12 expansion). XV is completely independent of V4L and the DRI. -- The more I know about the WIN32 API the more I dislike it. It is complex and for the most part poorly designed, inconsistent, and poorly documented. - David Korn |
From: Michel <mic...@ii...> - 2001-10-05 00:14:28
|
On Fri, 2001-10-05 at 00:08, Nathan Hand wrote: > XV is completely independent of V4L and the DRI. This is true conceptually and was true implementation-wise until recently. However, the r128 driver uses the DRM to transfer the XvImage data now when possible, and Peter Surda has been bug^Wasking us for some time to provide facilities to do the same for grabbing... --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Michael Z. <zmi...@po...> - 2001-10-07 11:10:38
|
----- Original Message ----- From: Michel Dänzer <mic...@ii...> To: Nathan Hand <na...@ma...> Cc: Michael Zayats <zmi...@po...>; <dri...@li...> Sent: Friday, October 05, 2001 2:14 AM Subject: Re: [Dri-devel] glDrawPixels on i810 > On Fri, 2001-10-05 at 00:08, Nathan Hand wrote: > > > XV is completely independent of V4L and the DRI. > > This is true conceptually and was true implementation-wise until > recently. However, the r128 driver uses the DRM to transfer the XvImage > data now when possible, and Peter Surda has been bug^Wasking us for some > time to provide facilities to do the same for grabbing... can it be also done for i810 (I mean using DRM for XvImage transfer), I found XVideo very CPU intensive on memory copies although performing hardware scaling very well. Do you know the mantainer of i810 for XVideo, may be he will do it... Michael |
From: Michael Z. <zmi...@po...> - 2001-10-07 14:41:03
|
----- Original Message ----- From: Michel Dänzer <mic...@ii...> To: Nathan Hand <na...@ma...> Cc: Michael Zayats <zmi...@po...>; <dri...@li...> Sent: Friday, October 05, 2001 2:14 AM Subject: Re: [Dri-devel] glDrawPixels on i810 > On Fri, 2001-10-05 at 00:08, Nathan Hand wrote: > > > XV is completely independent of V4L and the DRI. > > This is true conceptually and was true implementation-wise until > recently. However, the r128 driver uses the DRM to transfer the XvImage > data now when possible I am trying to contact i810 Xv driver mantainer to do the same for i810, but if he can't do it in near future would you assist me if I decide to make it myself? > , and Peter Surda has been bug^Wasking us for some > time to provide facilities to do the same for grabbing... > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Michel <mic...@ii...> - 2001-10-07 17:50:00
|
On Sun, 2001-10-07 at 17:43, Michael Zayats wrote: > > On Fri, 2001-10-05 at 00:08, Nathan Hand wrote: > > > > > XV is completely independent of V4L and the DRI. > > > > This is true conceptually and was true implementation-wise until > > recently. However, the r128 driver uses the DRM to transfer the XvImage > > data now when possible >=20 > I am trying to contact i810 Xv driver mantainer to do the same for i810, > but if he can't do it in near future would you assist me if I decide to m= ake > it myself? Yes, time permitting. Your best bet is probably to ask on this list or on Xpert. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |