From: Robin Kay <komadori@my...> - 2001-11-27 14:11:49
>thank you for your interest in xine. I can confirm you that your
>observation is correct - solaris testing has been a bit low recently,
>so I'm very glad to hear you want to help out here.
I was hoping you would notice that since posting of my original bug report,=
I'd joined xine-devel and identified the cause of the seg faulting (see:=
[xine-devel] 0.9.5 segfault if no audio). The broken Sun audio plugin (f=
ixed, Juergen Keil) was exposing a bug in xine.c that caused a seg fault =
if the audio plugin was null (fixed, Miguel Freitas). Have patched my cop=
ies of the relavent files and xine now works as well as ever on Solaris.
The main performance hits of Solaris are that XSun doesn't support 16bpp co=
lour depths nor the Xv extension. Sun's PGX64 frambuffer supports these f=
eatures (harware scaling and colour space conversion on an overlay window=
) in hardware however and I'm trying to write a video_out plugin to utili=
se them. Need to convert xine's YUV data to YUV422 (or something like tha=
t). But, should I convert 24bpp RGB data to 16bpp before sending to the f=
ramebuffer (net performance)? When are frames given in RGB format?
My other concern is about the performance of Sun's libc implementation. I h=
aven't been able to get a benchmark on libc memcpy performance as probe r=
eturns 0 (bug?). It may be possible to borrow glibc/SPARC's highly optimi=
sed assembler routine to do the job. I've had go at patching my copy to d=
o this but haven't succeeded yet. As an afterthought, memcpy.c should ref=
er to 'libc memcpy' rather than 'glibc memcpy', if only for completeness =
From: Miguel Freitas <miguel@ce...> - 2001-11-27 16:14:19
Robin Kay wrote:
> My other concern is about the performance of Sun's libc
> implementation. I haven't been able to get a benchmark on libc
> memcpy performance as probe returns 0 (bug?). It may be possible to
> borrow glibc/SPARC's highly optimised assembler routine to do the
> job. I've had go at patching my copy to do this but haven't
> succeeded yet. As an afterthought, memcpy.c should refer to 'libc
> memcpy' rather than 'glibc memcpy', if only for completeness ^_^.
Thanks to xine architecture memcpy are almost not used on critical
parts. Don't expect any big performance improvement if you implement an
asm memcpy. Also the 0 value is because at x86 we use pentium counters
for measuring time and there's no implementation for other cpus.
I think you should try implementing the video_out driver you said if you
want significative performance gains...