|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): > 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? ---- 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 ---- So the question is, when should the system memory instance be restored by reading the data back from the video memory instance (slow)? -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.