On Wed, 2007-03-07 at 14:48 -0500, Dan Williams wrote: > On Wed, 2007-03-07 at 20:07 +0100, salsaman wrote: > > Dan Williams wrote: > > > > >On Wed, 2007-03-07 at 19:38 +0100, salsaman wrote: > > > > > > > > >>Dan Williams wrote: > > >> > > >> > > >> > > >>>If you send X a pixmap that's not in the native framebuffer format > > >>>(which happens to be 565 right now) then X will have to format convert > > >>>that to 565 for you, which ends up being really slow, especially for > > >>>large pixmaps. The moral of the story is, don't format convert, and > > >>>keep everything you want to be fast in native framebuffer (ie 565) > > >>>format. > > >>> > > >>> > > >>> > > >>> > > >>Well, that could be a big problem for LiVES (and for any other > > >>application using GTK+/GDK). LiVES uses RGB24 as its internal format. > > >>Why the heck use 16bit colour for the X server ? Why not use 24bit like > > >>the rest of the modern world ;-) ? > > >> > > >> > > > > > >Because then you have to push around a lot more data, and you loose > > >about 6MB _more_ of memory to VRAM than we already loose. Plus, it's > > >unclear whether 888 is really a win. You gain because you don't have to > > >format convert, but you loose because the pixmaps are much larger. We > > >don't have a ton of memory bandwidth, and we're memory limited anyway. > > > > > > > > > > > The pixmaps will be the same size anyway, because GdkPixbuf uses RGB24. > > > > > > >We have explored going to 888 but there wasn't time to do real > > >performance measurements to make sure that 888 wasn't a regression in > > >the general case. > > > > > >We also explored going to 4444 or 1555 to make format conversions > > >unecessary when alpha was being used, but that will take some work in X > > >and cairo that we don't have time to do. > > > > > >Simply put, the Geode GX processor is not a very fast processor, and the > > >GPU has known limitations. Using the GX was a choice that was made > > >based on tradeoffs of price vs. performance and we may just have to live > > >with the limitations. > > > > > >If existing applications don't respect the limitations of OLPC, then > > >either they must be fixed to do so, or they will not be performant. > > > > > >Dan > > > > > > > > > > > > > > > > > > > > "Must be fixed to do so" !? > > OLPC doesn't cater to any specific existing application. It's a piece > of hardware with constraints, and all software running on that hardware > must respect those constraints if they want optimal performance. This > is the case with all hardware. It just happens that desktop computers > where LiVES probably already runs are fast enough to make this not a > problem. > > > It's not possible to use RGB565 in LiVES for a variety of reasons: it > > uses GDK, which only supports 24/32 bit colour; and RGB565 is not a > > supported palette in any of the modern video processing standards (the > > only application which I know supports it internally is MOB, and I > > believe is dropping it soon, or may already have). > > Yeah, we do suffer from some of that right now with Sugar. However, we > are using Cairo which does support 565. X also supports 565 fairly > well. You simply cannot depend on 888 (ie, 24/32 bit) being fast enough > here to do what you probably want on the OLPC machines for various > reasons. > > > We (video developers) decided about 2 years ago to drop RGB565 support > > in Livido (the now becoming common effect standard) > > http://livido.dyne.org/ and hence it is not present either in Weed > > (LiVES' own effect standard which is based on Livido). > > That's nice, but dropping support means you are limiting your options > for projects like OLPC that are not using the latest video hardware. > It's a tradeoff; to meet $100, we cannot use the latest hardware. > > > In short, supporting RGB565 in LiVES would require several man-years of > > work to make a hacked version of GDK, followed by several months of work > > to alter LiVES, plus rewriting all of the effect standards. Even then, > > since most effects process in RGB24, it would require a lot of palette > > conversions internally. > > > > I am not even sure if LiVES will run on a 16 bit display, AFAIK this has > > never been tested. > > That said, it wouldn't hurt to try and see what the performance is. X > will automatically convert anything you draw in 888 to 565 for you. So > it's likely that LiVES will run, but more slowly. > > > A really don't see what you lose going to a 24 bit Xserver. Sure, it > > needs a bit more memory, but for a 1024x768 screen resolution, you are > > only talking about 800KB more. > > We run a 1200x900 framebuffer. You also need EXA acceleration memory > and more memory for RandR rotation. Moving to 24-bit would mean the > loss of an additional 6MB of system memory on top of the existing 4 or 6 > we already lose to framebuffer.
I lied; right now 8MB out of 128 is devoted to VRAM. Moving to 24/32 bit would mean a loss of an additional 6MB, meaning that only 114MB is available to the rest of the system. Dan > > This also means that all pixmaps _everywhere_ will be 1/3 larger than > they are today. That means applications take up more memory on an > already limited 128MB system. That's life. Is the tradeoff here to > allow 24-bit only applications to work worth the loss in memory and > performance because you're shoving around 1/3 more data on every > graphics operation? I don't know. > > Furthermore, LCD panels don't give you all 8 bits per channel of color > fidelity. Most panels will only actually display 666 in the best case. > So using 888 is essentially loosing performance for something that the > user will _never_ ever see. > > > I think a lot of applications will have problems if you stick to 16 bit > > colour. Just my opinion though. > > 16 bit color isn't all that bad, since our LCD panel can only display > 666 anyway. But it's a fact of life that the OLPC machine is not the > fastest machine out there, and there are limitations that it has to get > to the $100 price point. Those limitation include graphics that are not > as fast, nor as flexible as a desktop with even an entry-level graphics > card sold today. That's life. > > Dan > > > _______________________________________________ > Devel mailing list > [email protected] > http://mailman.laptop.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
