> Well, this explains some things - but not all of them. Perhaps you can
> point out to me where I am wrong ?
>
> First of all, how PCI scatter-gather works: instead of having one
> physically contiguous buffer to DMA in/out, we have a list of page-sized
> buffers and a table (not more than a f
On Sat, 13 Oct 2001, Keith Whitwell wrote:
> On Sat, 13 Oct 2001 17:32, [EMAIL PROTECTED] wrote:
> > On Sat, 13 Oct 2001, Keith Whitwell wrote:
> > > > That's what I am trying to do. With not much luck so far. The reason
> > > > (at least to me) is that the 3d driver is the interaction of 3 par
On Sat, 13 Oct 2001 17:32, [EMAIL PROTECTED] wrote:
> On Sat, 13 Oct 2001, Keith Whitwell wrote:
> > > That's what I am trying to do. With not much luck so far. The reason
> > > (at least to me) is that the 3d driver is the interaction of 3 parts:
> > > kernel drm module, XFree driver (like radeon
On Sat, 13 Oct 2001, Keith Whitwell wrote:
>
> >
> > That's what I am trying to do. With not much luck so far. The reason (at
> > least to me) is that the 3d driver is the interaction of 3 parts: kernel
> > drm module, XFree driver (like radeon_dri.c) and the dri part (whatever
> > goes into ra
-- Forwarded Message --
Subject: Re: [Dri-devel] Using drm (fwd)
Date: Sat, 13 Oct 2001 16:42:59 -0600
From: Keith Whitwell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
> That's what I am trying to do. With not much luck so far. The reason (at
> least to me) is that the 3d drive
Well, it is late Saturday here. I know everyone is busy, but can at least
someone confirm that they know the answer but just don't have time for it ?
I'd hate to lose a weekend waiting for something that's not going to
come..
Vladimir Dergachev
-- Forwarded
On Sat, Oct 13, 2001 at 11:16:51PM +0200, Michael Zayats wrote:
> well back to our cows...
hi
> putting DMA might save about 25%...
A very reasonable assumption.
> another 2 questions:
> 1) may be I should just use some optimized version of memcpy? someone knows
> of MMX or SSI uses in glibc? I
> BTW. Somebody said that the mach64 driver crashed under 2.4.10 kernel (I
> don't remember who said it). I've made all these tests under 2.4.12 without
> problems.
That was me. I had enabled some of the new kernel debugging options,
including CONFIG_DEBUG_SLAB and CONFIG_DEBUG_IOVIRT. After re
well back to our cows...
I get frames from bt848 at 25 fps - F_CIF (710x576 YUV420 i.e. 12 bits) -0%
cpu usage if I just discard them.
since I get them in mmap'ed driver area and not shared memory, I use single
memcpy to copy them to one previously allocated shared memory - 25% CPU
time.
Now Xv
Hello.
I've been very busy lately at work, and have sadly checked that there have
been no progress in the mach64 work, or at least it wasn't posted in this
list.
Today I've tried to make gears work under the mach64 drm code. Well, gears
just shows a window with rests of KDE initialization s
> Actually 2.5 will see a lot of devices moving away from IOCTLs (even legacy
> ones) as Linux gains namespace support. From the Linus threads I've read,
> even older IOCTLs will be shot down. The unmaintainability and randomness
> of IOCTL numbering schemes is one of the things that brought th
* Keith Whitwell <[EMAIL PROTECTED]> on Sat, Oct 13, 2001:
>
> Instigate a rule where any released ioctl will always be supported, with the
> same semantics and interface.
>
[...]
>
> Secondly, it means no ioctls are ever removed or renamed. This was Linus'
> big concern and h
Jeff, Others,
I've been reviewing the work in the 3.5 branch for backwards compatibility
and to me it looks like we can do it with a lot less effort. Here's what I'm
proposing, in one simple sentence:
Instigate a rule where any released ioctl will always be supported, with the
same s
13 matches
Mail list logo
