On Sat, Jan 16, 2010 at 10:10:17AM +0000, Jakob Bornecrantz wrote: > On 16 jan 2010, at 09.47, Chia-I Wu wrote: > >On Sat, Jan 16, 2010 at 05:49:44AM +0000, Jakob Bornecrantz wrote: > >>Here comes a quick review, lot of the things in here are out of date > >>due to discussions over email so I tried to only comment on bits. > >>A general note is that you seem to have removed a lot of comments. > >>Could you please base the a newer version on the st_api.h I sent > >>out. > >I am willing to rebase on your version. I think we should maintain > >st_api.h and a DESIGN document on a git repo on > >fdo/~<username>/st_api.git. It will give us something we can base our > >discussion on. What do you think? Do you want to do it or should I? > Thanks! Go ahead and start a repo, I'll create a repo at fdo/ > ~wallbraker/st_api.git if I want to push something out. I am out with some friends tonight. I can do it tomorrow (Taipei time). > >I think the state trackers (libGL.so, libOpenVG.so, ...) are > >distributed > >separately from state tracker managers (libEGL.so). Shouldn't we need > >them? > Both yes and no. The Linux GL ABI specifies exactly what libGL can > contain (glx implementation + gl dispatch table) the rest needs to > be inside the DRI driver (mesa and st). There is no such standard > for libEGL.so/libOpenVG.so so we currently have the state trackers > in those and I'm fine with leaving it that way for the time being. > The disadvantage is that you need to upgrade libOpenVG along side > you driver if you want it to work (New dri drivers work perfectly > fine with old libGL's how ever). One way to solve that would be to > put the all the state trackers in the driver binaries, but that > gives very large binaries. So something needs to be sorted out, but > its beyond the scope of this discussion. A simple major/minor versioning helps avoid mysterious crashing. The st manager and st will refuse to load each other. But I am fine either way. Your preference? > >By the way, a state tracker is able to implement both st_public.h and > >st_api.h at the same time. It gives a mild migration path. > That be really great if you could do that, at least for st/mesa, > there isn't much need for that on for example OpenVG. > >>>+ * Note that if this funcion is called multiple times with > >>>different sets of > >>>+ * attachments, those not listed in the latest call might be > >>>destroyed. > >>>+ * This behavior might change in the future. > >>The pipe textures are referenced counted and as long as the > >>rendering API has references to them they will stay around and it > >>must be possible to render to them. However they might be the wrong > >>buffers to render to. That is invalidated. > >The comment describes the behavior of DRI2GetBuffers. Even the > >texture > >are reference counted by the state tracker, becase DRI2CopyRegion is > >called when flushing front buffer or swapping buffers, it causes > >BadDrawable X errors if the state tracker is not cautious. > Yeah you are correct. > >But, a big BUT, I want to change the semantics of "validate" and > >remove > >the comment. That is, one can ask front & back buffers, and then ask > >only the front buffer. The back buffer won't not be destroyed. > Sounds good, is this for keeping the contents of the backbuffer > alive? There are several points when the specs allow the contents to > be come undefined using that could allow us to save on memory. Yes. I think the memory saving can be done entirely inside st manager and the internal behaviour needs not be exposed in the interface. But I guess I won't change it right away until I am more sure. > >>>+ /** > >>>+ * Ask the st context to re-validate the binding surfaces. > >>>+ */ > >>>+ void (*update_surfaces)(struct st_context *stctx); > >>Can you please use the name as given my version, it really is a > >>notify event since on certain platforms this call might originate > >>from another thread then the one that the context is current in and > >>as such needs to be thread safe. And by having it just as a > >>notification we don't need any locking in the rendering api. However > >Ok. > >>if validate as you suggest is a lightweight operation this function > >>is probably not needed. > >validate will be cheap on X only after there is a notification > >mechanism > >allowing the state tracker manager to cache the textures and avoid the > >round trip. > > Right... > > >>>+ > >>>+ /** > >>>+ * Return the render buffer of the context. > >>>+ */ > >>>+ enum sm_render_buffer (*get_render_buffer)(struct st_context > >>>*stctx); > >>For now lets wait with introducing this function. There must be ways > >>around it. > >Yeah, I will leave it out. > > Thanks. > > Cheers Jakob.
-- Regards, olv ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
