Niels, thanks for the explanation and the tip ;) That's what I observed too, but I didn't understand why...
Regards, -- Lionel Landwerlin On Fri, Feb 19, 2010 at 6:50 PM, Niels Roest <ni...@directfb.org> wrote: > oic, now that makes sense. > > I did a test on fbdev and I got the same response as you. > only on the "Lock" will DirectFB assign memory, and since you get a > C-pointer this is CPU-accessible memory. > then after Unlock, the FillRectangles wants GPU memory. > In principle the GPU memory is mmap'd as well, so you need only one > allocation - however, the first access (CPU only) leads to DirectFB taking > the approach of requesting SYSTEM or SHARED memory, and only the HW accel > option afterwards changes this to memory from the FBDEV pool, leading to a > buffer transfer (in other words, the allocation is copied to the new > location, it is not a flip). > The slightly non-intuitive VIDEO_ONLY at surface creating will alleviate > this for this case in particular. > > > Greets > Niels > > Lionel Landwerlin wrote: > >> Hello Niels, >> >> >> >> On Wed, Feb 17, 2010 at 9:00 PM, Niels Roest <ni...@directfb.org <mailto: >> ni...@directfb.org>> wrote: >> >> Strange. >> >> Rewriting your tests a bit towards C, I do not experience this >> behaviour... >> >> >> I only have the behavior if the FillRectangle operation is accelerated. >> Do you try that in this setup ? >> >> >> ptr before == ptr after, and after a flip, it changes. >> Note that it is not imposed that the ptr's are always equal; >> DirectFB reserves the right to move non-locked memory areas, but I >> suspect that this is not the case here. >> >> Greets >> Niels >> >> Lionel Landwerlin wrote: >> >> Hello everyone, >> >> I'm using surface locks for some custom graphical engine >> tests, and don't understand the following behavior of directfb : >> >> layer->CreateSurface(&surface, DOUBLE_BUFFERED) >> surface->Lock (&ptr, CPU_READ|CPU_WRITE); >> >> Here directfb return a ptr = 0x42424242 for example. >> Then I execute the following steps : >> >> surface->Unlock() >> surface->FillRectangle(0, 0, 42, 42); >> surface->Lock(&ptr, CPU_READ|CPU_WRITE); >> >> Here ptr has changed from its previous value. >> Why ? I didn't require a Flip. >> >> Should I own the lock all the time ? >> >> Thanks for answers. >> >> -- >> Lionel Landwerlin >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> directfb-dev mailing list >> directfb-dev@directfb.org <mailto:directfb-dev@directfb.org> >> >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >> >> >> >> -- >> .------------------------------------------. >> | DirectFB - Hardware accelerated graphics | >> | http://www.directfb.org/ | >> "------------------------------------------" >> >> >> > > -- > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" >
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
