|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: possible directfb bug
Quoting Alex SONG (firstname.lastname@example.org): > On Wed, 12 Jun 2002, Denis Oliver Kropp wrote: > > > Quoting Alex Song (email@example.com): > > > hi, > > > > > > while i was working with the savage driver i noticed something that might > > > be a bug in the generic graphics routines. the savage driver accelerates > > > blits and not stretchblits and when i first stretchblit (software) > > > everything is fine and then when i blit (hardware) everything is fine too > > > but when i stretchblit (software) after doing a blit things slow down quite > > > significantly. this does not happen in full software mode (with > > > --dfb:no-hardware). i had a brief look at the code and i think it is to do > > > with the software pipeline in the generic routines not being reset properly > > > when changing from a hardware blit to a software stretchblit. this is just > > > a gut feeling, someone with more experience with the source code may have a > > > better guess. what does the directfb people think about this ? > > > > I think it's related to the surface management, especially handling of > > "auto-video" surfaces. The function "dfb_surface_software_lock()" in > > "src/core/surfaces.c" decides if access by the software driver or the > > application is done using system or video memory. It chooses the video memory > > instance if the surface has been written to by the hardware. > > > > Does it happen with df_dok? > > no, because df_dok has separate surfaces for blit and stretchblit and the > problem does not occur. the problem only shows up if doing hardware blits > and software stretchblits (i assume vice versa will also show problems) > between the same set of surfaces. df_dok uses the same surface for blit and stretch-blit (melted.png). > > ---- something for the conceptual docs ---- > > > > A surface "buffer" can be allocated in video and/or system memory. > > The allocation in one of these pools is called the buffer's "instance". > > Both the system and the video memory instance have a "health". > > The health of an instance is "invalid" unless there's something allocated. > > If an instance is allocated the health is normally "stored", but turns to > > "restore" if the other instance (video/system) got written to. > > > > After creating an "auto-video" surface (default) a system memory instance > > exists that is marked "stored". The video memory instance is marked "invalid". > > If the hardware does a read-lock the video memory instance gets allocated, > > filled with the buffer data and marked "stored". If the hardware does a > > write-lock the system memory instance gets marked "restore". If the software > > does a lock while the system memory instance is not marked "stored" the video > > memory instance is used. > > > > ---- end ---- > > i think i actually understood all that, just one question just to check my > understanding. so hardware functions operate surfaces in video memory and > software functions operate surfaces in system memory ? is this correct ? > if it is then is it because the graphics has faster access to video ram > and cpu has faster access to system ram ? The hardware accesses the video memory only, the software accesses system or video memory. Writing to the video memory may be faster than writing to the system memory. Reading from the video memory is usually about ten times slower than reading from system memory. > if what i said so far is correct then the problem we are having is that > the same image data is being thrown around between video ram and system > ram because the blit is hardware and the stretchblit is software ? i > think i notice it more because i have shared memory for my savage chip. > > > So the question is, when should the system memory instance be restored by > > reading the data back from the video memory instance (slow)? > > i think it should be done when software functions are used because > subsequent software functions will not cause system memory to be restored. > the video memory should be restored when hardware functions are used. this > way worse performance will occur when alternating between hardware and > software functions. The alternating would happen if software writes to a surface and blits from it using hardware afterwards. This is a common case for displaying videos. > my current work around is to create 2 surfaces, one for blit and one for > stretchblit. If you are not blitting/drawing/writing TO these surfaces at any time the problem shouldn't occur. > side note: i would like to submit a patch for the savage driver and i was > wondering what options to diff do you guys use/prefer ? cvs diff -pu -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.