Comparing your log file with mine I couldn't spot anything special.
Can you try different depth and see if it change something ?
Also, are you using kernel video driver for silicon motion for your
frame buffer and does it works ?
___
xorg@lists.freedes
First things first, could you try to :
> (II) Module siliconmotion: vendor="X.Org Foundation"
> compiled for 1.6.5, module version = 1.7.1
upgrade to latest 1.7.3 version of siliconmotion driver
which git repository can be found on cgit.freedesktop.org
and :
> (--) SMI(0): videoram: 2048
Apart from minor bugs that are already largely solved, Yeelong video driver
suffers from performance issues related to video decoding.
The main problem, as I understand it, appears to be that the LynxEM chipset
can handle only packed YUV while most of the time frames are given as planar
YUV (I'm
Hello !
I still wonder where to patch my X11 to integrate a faster YUV packing function.
I've seen this sort of things in video drivers and in Xv itself, but in my
opinion this is pixman's job.
But I can't find in pixman right now the needed infrastructure to have
accelerated
packer/unpacker. M
-[ Thu, Feb 04, 2010 at 10:44:03AM -0500, Adam Jackson ]
> Yeah, probably.
So you fix it ?
Or maybe that's better to check for overlap in fbBlt so that we
still use memcpy which should be faster, avoiding the fastpath when
src and dest overlap ?
___
When playing some video with mplayer I noticed with oprofile that
half the time is spent in xf86XVCopyPacked() or xf86XVCopyYUV12ToPacked().
Looking at the former, I wonder why a mere memcpy was not used instead
of "manually" copying each words. glibc's memcpy is usually optimized
for the target a
> You must be looking at old source code. I changed this code in commit
> 52aa0495218d to use the sync instruction you mention.
Arg, I'm working on xserver 1.6.5 and forget to check on git.
Sorry for the noise.
___
xorg mailing list
xorg@lists.freedeskt
In compiler.h, is defined mem_barrier() which is used if I understand
correctly when accessing the memory mapped IO, to force the CPU to
ensure previous writes/reads are commited to the bus before the
following ones (gcc being independantly informed to keep the source code
reads/writes ordering by
There is a fastpath in fbBlt() using memcpy if the source and dest rasters are
properly aligned. This fastpath rely on MEMCPY_WRAPPED, which is (sometime) a
mere memcpy().
So, if the rasters do overlap the behavior is undefined. On my loongson (mips)
at home, it segfaults, bus error or sometime ha
