On Tue, Mar 27, 2012 at 3:27 PM, Jakob Bornecrantz <ja...@vmware.com> wrote: >> + >> + struct gbm_surface *(*surface_create)(struct gbm_device *gbm, >> + uint32_t width, uint32_t height, >> + uint32_t format); >> + struct gbm_bo *(*surface_lock_front_buffer)(struct gbm_surface *surface); >> + void (*surface_release_buffer)(struct gbm_surface *surface, >> + struct gbm_bo *bo); >> + int (*surface_has_free_buffers)(struct gbm_surface *surface); >> + void (*surface_destroy)(struct gbm_surface *surface); > > > Surface map and unmap needs a pipe_context for gallium, > and as such dri_context. I don't know what the best way to solve > that in gbm, either via a hidden dri_context[1] or via a > new gbm_context.
Maybe the lock/release names are confusing, but this isn't about cpu access, it's about getting a gbm bo that corresponds to the frame just rendered. We've talked about adding map/unmap to gbm bos, but that's not what this series is about. Kristian > Cheers, Jakob. > > [1] which I don't like since we can't get to it if with > fences since if we actually want to support better command > scheduling then what we currently have. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
