On 4/5/11 11:53 AM, Nathan Kidd wrote: >>> d) M7 destroys the GLXPixmap before calling XCopyArea on the associated >> > Pixmap; a questionable practice probably left over from the days when >> > you could do 2D X drawing over a GLX drawable without problem. This is >> > worked around by deferring GLXPixmap deletion till Pixmap deletion. (My >> > NVIDIA driver + X.org gives a race when trying to do the XCopyArea, a >> > race that M7 always seems to win when run on the console but my test app >> > can occasionally loose, and VGL always seems to lose.) > > You probably understand this better than me; do we risk "leaking" video > memory with this approach? If the app calls glXDestroyPixmap but never > calls XFreePixmap how will libGL know the pbuffer isn't needed any more? > Of course we could just say "Bad app, don't do that", but I can imagine > this case being common because the app really isn't that bad; the Pixmap > will be implicitly freed when you close the X connection (but we can't > hook that implicit free).
I don't understand the question. The Pbuffer gets destroyed in the body of the glXDestroyPixmap() function. > Sorry, by "push GLXPixmaps to the 2D X server" I mean push the rendered > pixels, just like we do for a GLX Window. In other words _doGLreadback > won't just check winh.findpb(drawable, pbw) but also check if the > current drawable is a GLXPixmap. This requires a few modifications to > pbwin and to fbx which currently only know how to push a window to the > desktop, but I believe the code change will be smaller and introduce > less risk than the current bunch of patches. > > My real question is what was the rationale behind the decision to not > push GLXPixmaps to the 2D X server? Is there more than the idea "hey, > they can only be seen by XCopyArea/XCopyPlane, if we hook those > functions we don't need to bother doing readback on them?". > > What I mean about "it should be generally faster" is if GLXPixmap pixels > get pushed via the pbwin readback path then the pixels will be pushed > efficiently for every transport type. A direct PutImage is only > efficient for X Proxies that compress PutImage anyway (e.g. VGL > transport will be slower with PutImage). I see several issues. The first is synchronicity (great album, BTW.) When an application is transferring pixels into a Pixmap, the expectation is that the pixels will be immediately available for use by other X11 functions. Theoretically, applications are well within their rights to expect the same thing when they transfer pixels into a Window, but in practice, applications almost never do expect that, which is why VirtualGL is able to get away with doing an asynchronous pixel transfer when XCopyArea() is called with a Window destination. In short, I don't think we could get away with transferring the pixels into an X11 Pixmap using any method other than a synchronous one, which means we're limited to using XPutImage(). Secondly, I don't understand how making pbwin/fbx aware of Pixmaps would eliminate the need to hook XCopyArea(). Apps are still going to try using XCopyArea() to copy from GLX drawables to 2D drawables (?), so we have to intercept that (?) Also, I don't think we can assume that the app will always call glFinish() before calling XCopyArea(), so we have to ensure that the GLX and 2D Pixmaps are synchronized within the body of XCopyArea(). If we're forced to use a synchronous XPutImage() to do that, it's problematic to do that in the body of glFinish(), because if an app calls glFinish() then XCopyArea(), the expensive XPutImage() operation gets executed twice. However, that is not to say that we can't greatly simplify XCopyArea() by encapsulating the relationship between GLX Pixmap and X11 Pixmap into a new class. I just think that we're ultimately not eliminating XCopyArea() but just moving its code elsewhere. At the end of the day, the disconnect between 2D and 3D means that we won't ever be able to develop a fully conformant implementation of Pixmap rendering. Let's take the case of copying from a Pixmap to a Window. The way we currently do it is to copy from the Pbuffer backing the Pixmap to the Pbuffer backing the Window, then allow VirtualGL to transfer the pixels to the Window asynchronously (the latter can be made synchronous if VGL_SYNC=1.) Now, another way to do it would be to copy from the Pbuffer backing the Pixmap to the actual Pixmap, then allow the "real" XCopyArea() function to transfer from Pixmap to Window. However, then the Pbuffer backing the Window never receives the updated pixels, and if the app is doing front buffer rendering, this could be a problem. I see the latter problem as less likely in the case of copying from a GLX Pixmap to an X11 Pixmap, because the assumption there is that, if someone wanted to perform OpenGL operations on the X11 Pixmap, they would have created a GLX Pixmap instead. However, I think the "right" thing to do might be that, if both source and destination of XCopyArea() are backed by Pbuffers, glCopyPixels() between the Pbuffers and let VGL transfer the pixels to the 2D drawable, either asynchronously (in the case of a Window destination) or synchronously (in the case of a Pixmap destination.) Otherwise, if the destination is not backed by a Pbuffer and the source is, VGL should synchronize the pixels between the source Pbuffer and the source 2D drawable (using XPutImage()) and then pass the 2D drawable handles to the "real" XCopyArea(). The third issue is one of philosophy, which is this: When transmitting the rendered 3D pixels from a Pbuffer to a window, VirtualGL allows these pixels to be modified in several ways: potentially subsampled or compressed using lossy algorithms, optionally gamma corrected, etc. IMHO, if an application is going to the trouble of rendering to a Pixmap, the app is expecting those pixels to arrive at the X server verbatim, so it would be incorrect to gamma correct or apply any other modifications that pbwin currently applies. I think that, minimally, pbwin would have to be modified to form a new class (pbpm). Perhaps the two could be subclassed around a base class (pbdrawable), allowing them to share some common code and interfaces, but I'm not sure how much code they could realistically share, so it almost makes more sense to leave them completely independent. Thus, if I'm understanding the picture correctly, this would produce the following XCopyArea() behavior: (1) GLX Pixmap -> X11 Window If the Window is backed by a Pbuffer, then use glCopyPixels() to transfer from the Pixmap's Pbuffer into the Window's Pbuffer and then let VGL handle transferring the pixels from the Window's Pbuffer to the actual Window (this is what XCopyArea() currently does.) If the destination Window isn't backed by a Pbuffer, then synchronize pixels between the GLX Pixmap and the corresponding X11 Pixmap and then let the "real" XCopyArea() do the job. (2) - (4) GLX Pixmap/Window <-> GLX Pixmap/Window XCopyArea() looks up the corresponding Pbuffer for both drawables and does a glCopyPixels(). (5) - (6) X11 Pixmap/Window -> GLX Pixmap Not handled unless we can find an app that actually does this. The "right" way to do it would be to extend the proposed pbpm class with an additional method that uses XGetImage(), but I really don't want to go there unless we have to. (7) GLX Pixmap -> X11 Pixmap Synchronize GLX Pixmap to X11 Pixmap, then call the "real" XCopyArea(). Apart from making it cleaner by the addition of a new class, I don't see how any of this is much different from what you've already done. > Sorry, I meant *my changes* to rrfakerut were half-baked. Mathematica 7 > is available as an eval if you ask, but tied to a specific machine. I'll > try to finish up unit tests for each of these issues. I was able to find a Mathematica 8 eval, but they don't seem to offer 7 anymore. Also, can you post a procedure for reproducing the issue? ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
