🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: es.comp.os.linux.programacion
Article #6077

Re: Memcpy rápido en modo kernel

#6077
From: Jayr Al-Dyn
Date: Sun, 10 Aug 2003 16:52
60 lines
3657 bytes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Muy buenas.

Gorka Olaizola dec�a:

> El d�a Sat, 09 Aug 2003 10:43:27 +0200, Jayr Al-Dyn
> <jayraldyn@jayraldyn.net> escribi�:
>> 
>>  - copia del framebuffer a buffer local: 180 �s (tanto en MMX como en
>>  memcpy
>> normal)
>>  - conversi�n RGB565 a RGB24: 50 �s
>>
> Seguramente sea una tonter�a lo que estoy diciendo pero �No se puede hacer
> la conversi�n y reescalado directamente del primer buffer al buffer local?
> As� te evitas la copia y aunque la memorira gr�fica pueda ser m�s lenta a
> veces, seguro que algo te ahorras.
> O igual usando un mmap para mapear el primer buffer a memoria normal.
> Seguramente est� diciendo una chorrada.

No, que va, nada de eso. En realidad, ya intent� algo similar, pero el
problema era a�n peor (llegaba a tardar del orden de 500 �s). Lo del mmap,
es algo que ya se hace (se mapea el framebuffer a un espacio de direcciones
accesible). En realidad, es la �nica manera razonable de acceder al
contenido del framebuffer.

De todos modos, me temo que el problema es insalvable, ya que radica como
sospechaba en que el framebuffer no se "cachea", de modo que dif�cilmente
voy a poder conseguir mayor eficiencia. Todo lo que leo me lleva a la
conclusi�n de que los framebuffers est�n dise�ados para ser r�pidos en
escritura, pero que son lentos en lectura. 

�Soluci�n? La que me propusiste al principio: dividirlo en dos, uno en zona
de usuario que tome las capturas de pantalla y realice el trabajo "pesado"
y un m�dulo (device driver) que se encarga b�sicamente de implementar la
interfaz v4l. Esto tiene la ventaja de que la captura de la pantalla se
hace de una zona de memoria, no del framebuffer (de hecho, se har�a
mediante un simple XGetImage), con lo cual deber�a ser mucho m�s r�pido. De
momento, me estoy pensando c�mo hacerlo (si tienes curiosidad,
http://x2v4l.jayraldyn.net/x2v4l_0.3.pdf).

Gracias y un saludo.

- -- 
Jayr Al-Dyn
Usuario Linux #95614 / PGP-Key: d5678a00
http://www.jayraldyn.net

Ojo por ojo, jejentaicuatro
                -- An�nimo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/NnhG7KeWPNVnigARAl7IAJ41tA1puCfhskyKoSHkL7lDOfr3JwCfepsQ
XNJifzPvV06KjOF5P6GWcvI=
=dHgs
-----END PGP SIGNATURE-----
Technical Details
Message-ID: <bh5t8h$liv$1@rantanplan.linux.es>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!newshub1.home.nl!home.nl!amsnews01.chello.com!news-hub.cableinet.net!blueyonder!marmolejo.escomposlinux.org!frodo.antakira.com!news.antakira.com!mainake.escomposlinux.org!escomposlinux.org!not-for-mail
References: <bh1501$l76$1@rantanplan.linux.es> <slrnbj97uf.ped.gorka@conn.helvete.escomposlinux.org> <bh2c7r$dmi$1@rantanplan.linux.es> <slrnbjcfn7.pa6.gorka@conn.helvete.escomposlinux.org>

Show Full Headers
Complete Article Headers
X-Google-Language: SPANISH,ASCII
X-Google-Thread: f86c8,59ca0de1d90dfc08
X-Google-Attributes: gidf86c8,public
X-Google-ArrivalTime: 2003-08-10 09:52:39 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!newshub1.home.nl!home.nl!amsnews01.chello.com!news-hub.cableinet.net!blueyonder!marmolejo.escomposlinux.org!frodo.antakira.com!news.antakira.com!mainake.escomposlinux.org!escomposlinux.org!not-for-mail
From: Jayr Al-Dyn <jayraldyn@jayraldyn.net>
Newsgroups: es.comp.os.linux.programacion
Subject: Re: Memcpy rápido en modo kernel
Date: Sun, 10 Aug 2003 18:52:18 +0200
Organization: MALOU
Lines: 60
Message-ID: <bh5t8h$liv$1@rantanplan.linux.es>
References: <bh1501$l76$1@rantanplan.linux.es> <slrnbj97uf.ped.gorka@conn.helvete.escomposlinux.org> <bh2c7r$dmi$1@rantanplan.linux.es> <slrnbjcfn7.pa6.gorka@conn.helvete.escomposlinux.org>
NNTP-Posting-Host: 133.red-213-98-164.pooles.rima-tde.net
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit
X-Trace: rantanplan.linux.es 1060534353 22111 213.98.164.133 (10 Aug 2003 16:52:33 GMT)
X-Complaints-To: mainake@escomposlinux.org
NNTP-Posting-Date: Sun, 10 Aug 2003 16:52:33 +0000 (UTC)
User-Agent: KNode/0.7.2