On Thu, 26 Jul 2012 09:45:35 -0400 (EDT) david.obo...@aliceadsl.fr said: we can't use memcpy for it becuase its a 32->24 bit conversion. it is converting to a PACKED 3 bytes per pixel setup. most fb's dont use this - they use 32bits per pixel. it's a rare case you have.
> I wonder why don't use a memcpy to copy for the 24bpp conversion like this > patch (when it's possible), and use conventional method for the other > endianness. In my board I can go approximately 30% faster (I don't know for > other archi than i686). > > ----- Mail original ----- > De: "david oboeuf" <david.obo...@aliceadsl.fr> > À: "Enlightenment developer list" <enlightenment-devel@lists.sourceforge.net> > Cc: "Carsten Haitzler" <ras...@rasterman.com> > Envoyé: Jeudi 26 Juillet 2012 11:02:27 > Objet: Re: [E-devel] Patch for endianness conversion > > I think x86 processor have a hardware-fixups to process unaligned writes > (with some improvement with new x86 processor, the difference is nearly 0% > now, it's why it works faster). But it's a very specific case and don't work > in other architecture. > > ----- Mail original ----- > De: "david oboeuf" <david.obo...@aliceadsl.fr> > À: "Carsten Haitzler" <ras...@rasterman.com> > Cc: "Enlightenment developer list" <enlightenment-devel@lists.sourceforge.net> > Envoyé: Jeudi 26 Juillet 2012 08:55:32 > Objet: Re: [E-devel] Patch for endianness conversion > > I use this on a x86 platform so it's actually faster, because I use a bgr > picture for my framebuffer (the data is in order, so I write that I read). > But yes, it's a disaster for platform without support of unaligned writes. In > fact, I made this, because I wanna read only one time the value in RAM and > after I use rotation and bitshift instruction (Commonly used processor), so I > must memorize this in a "register" and write 4 pixel at once. But I don't > know it's really faster with 4 pixe, because we need to have some control > instruction (aligned write, end of line). > > > ----- Mail original ----- > De: "Carsten Haitzler" <ras...@rasterman.com> > À: "david oboeuf" <david.obo...@aliceadsl.fr> > Cc: "Enlightenment developer list" <enlightenment-devel@lists.sourceforge.net> > Envoyé: Jeudi 26 Juillet 2012 05:51:25 > Objet: Re: [E-devel] Patch for endianness conversion > > On Wed, 25 Jul 2012 06:28:48 -0400 (EDT) david.obo...@aliceadsl.fr said: > > umm... is this actually faster? in fact this does unaligned writes. that's > disaster on platforms without hardware-fixups (like x86). on arm this would > fall over in a stinking heap performance-wise (like be 1/1000th the speed if > kernel fixups are enabled OR simply segfault if they are not). so as such > since this would cause segv's on some platforms... cant' do this (that's why i > mentioned doing 4 pixels at a time in "registers" to avoid unaligned access - > you'd also need alignment checks for destination ptrs for scanline starts). > > the reason the R/G/B_VAL macros use byte reads is that i've found them to > ultimately be faster or the same speed on most platforms i see (x86, arm) > compared to word access+bitshift. > > if on your system this is faster - maybe try this. in evas_common.h change the > *_VAL() macros to do these things: > > #define A_VAL(p) (((*((DATA32 *)p)) >> 24)) > #define R_VAL(p) (((*((DATA32 *)p)) >> 16) & 0xff) > #define G_VAL(p) (((*((DATA32 *)p)) >> 8) & 0xff) > #define B_VAL(p) (((*((DATA32 *)p))) & 0xff) > #define AR_VAL(p) (((*((DATA32 *)p)) >> 16)) > #define GB_VAL(p) (((*((DATA32 *)p)) ) & 0xffff) > > there's a bigendian ifdef handler there to try... the compiler should be able > to optimize these down to about the same as done more manually. > > > Hi, > > > > Ok, I try to find out the root of the problem. I've also made a patch to > > speed up the conversion from rgba to rgb in 24bpp. > > > > ----- Mail original ----- > > De: "Carsten Haitzler" <ras...@rasterman.com> > > À: "david oboeuf" <david.obo...@aliceadsl.fr> > > Cc: "Enlightenment developer list" > > <enlightenment-devel@lists.sourceforge.net> Envoyé: Mercredi 25 Juillet > > 2012 12:07:40 Objet: Re: [E-devel] Patch for endianness conversion > > > > On Tue, 24 Jul 2012 07:31:28 -0400 (EDT) david.obo...@aliceadsl.fr said: > > > > if you can find out why evas is using the wrong format - that'll be useful. > > i dont know what fbset output means. :) > > > > > The color format is wrong, but now, I don't know if it's our framebuffer > > > or evas the problem. Except for this point, all runs fine (I run Enna on > > > my STB). I'm right to make this patch, I will work this afternoon on this > > > > > > ----- Mail original ----- > > > De: "Carsten Haitzler" <ras...@rasterman.com> > > > À: "david oboeuf" <david.obo...@aliceadsl.fr> > > > Cc: "Enlightenment developer list" > > > <enlightenment-devel@lists.sourceforge.net> Envoyé: Mardi 24 Juillet 2012 > > > 11:39:42 Objet: Re: [E-devel] Patch for endianness conversion > > > > > > On Tue, 24 Jul 2012 05:34:06 -0400 (EDT) david.obo...@aliceadsl.fr said: > > > > > > > Mea Culpa, I haven't see it's already make in evas_common.h with the > > > > macros. It's a problem with my platform. > > > > > > no worries - happy to help out. if evas's color format choosing is wrong - > > > please let us know - or ecore-evas. check there. the 24bpp support is > > > almost never used so its never tested "in real life". > > > > > > nb - the converter COULD be faster by handling 4 pixels at once packing > > > them into 32bit registers (well just vars - registers will be handled by > > > the compiler) and writing out whole ints at a time (read 4 pixels, write > > > 3 ints which contain 4 pixels). THEN endianess WOULD matter. :) you'd be > > > right to want to patch. :) also if we had mmx/sse asm to do this too. > > > > > > > Thanks > > > > > > > > ----- Mail original ----- > > > > De: "Carsten Haitzler" <ras...@rasterman.com> > > > > À: "Enlightenment developer list" > > > > <enlightenment-devel@lists.sourceforge.net> Cc: "david oboeuf" > > > > <david.obo...@aliceadsl.fr> Envoyé: Mardi 24 Juillet 2012 11:27:50 > > > > Objet: Re: [E-devel] Patch for endianness conversion > > > > > > > > On Tue, 24 Jul 2012 05:21:08 -0400 (EDT) david.obo...@aliceadsl.fr said: > > > > > > > > > I don't think so, the source is 32bit, so we advance 4 bytes (for the > > > > > source) and we choose 1 bytes for each color (and write it in the > > > > > destination), the endianness make sens when we write from source to > > > > > destination. > > > > > > > > those R_VAL etc. macros handle edianess already - evas's rgb vormat is > > > > fixed in memory. per pixel its an int (4 bytes) with MSB being A, LSB > > > > being B. if you address it as an int and bitshift u never have to care > > > > about endianness. if u access byte by byte you do. the output is > > > > byte-based. you swapped the output in your patch and as such there are 2 > > > > diferent routines to deal with the 2 orderings for output - RGB or BGR > > > > (byte-by-byte order). > > > > > > > > > here is the RGBA result of fbset: > > > > > rgba 8/16,8/8,8/0,0/0 > > > > > > > > > > and evas detect a RGB format > > > > > > > > > > ----- Mail original ----- > > > > > De: "Carsten Haitzler" <ras...@rasterman.com> > > > > > À: "Enlightenment developer list" > > > > > <enlightenment-devel@lists.sourceforge.net> Cc: "david oboeuf" > > > > > <david.obo...@aliceadsl.fr> Envoyé: Mardi 24 Juillet 2012 10:27:44 > > > > > Objet: Re: [E-devel] Patch for endianness conversion > > > > > > > > > > On Tue, 24 Jul 2012 03:32:25 -0400 (EDT) david.obo...@aliceadsl.fr > > > > > said: > > > > > > > > > > > Hi everybody, > > > > > > > > > > > > I work actually on a set-top-box little endian with a 24-bit depth > > > > > > framebuffer (evas version 1.2.1). I noticed there are no conversion > > > > > > between little endian and big endian (my color was inverted). I > > > > > > propose a patch to handle the endianness for this depth (I test only > > > > > > the evas_common_convert_rgba_to_24bpp_rgb_888 fonction). > > > > > > > > > > hmm this is wrong. as its writing 1 byte at a time and advancing 3 > > > > > bytes a time this has nothing to do with endianess. your 24bit > > > > > framebuffer (unusual these days) is literally BGR nor RGB. not an > > > > > endianess matter (it would be if we were writing int's (32bits) at a > > > > > time). :) ie uw ant to be using > > > > > > > > > > evas_common_convert_rgba_to_24bpp_rgb_888() > > > > > > > > > > instead of > > > > > > > > > > evas_common_convert_rgba_to_24bpp_bgr_888()... > > > > > > > > > > or the other way around - i have no idea which one is being used in > > > > > your case > > > > > - but something is telling the evas convert subsystem to use the > > > > > wrong 24bpp format for your hardware. :) > > > > > > > > > > -- > > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > > > > -------------- The Rasterman (Carsten Haitzler) > > > > > ras...@rasterman.com > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > Live Security Virtual Conference > > > > > Exclusive live event will cover all the ways today's security and > > > > > threat landscape has changed and how IT managers can respond. > > > > > Discussions will include endpoint security, mobile security and the > > > > > latest in malware threats. > > > > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > > _______________________________________________ enlightenment-devel > > > > > mailing list enlightenment-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > -- > > > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
