On 9/9/14 1:59 PM, Nathan Kidd wrote: > You'll notice that glReadPixels() comments out the emulateColorIndex() > check. When glReadPixels() is called by VirtualDrawable::readPixels() > the current context is the *temp* context, so glxCurrentContext()-based > lookups fail. This means that up to now an attempt to glReadPixels() on > a remote overlay (if that even works?) would have failed (since > overlayCurrent() would never be true). If the format is GL_COLOR_INDEX > then we'll get GL_INVALID_OPERATION unless the current context/drawable > is CI. Bottom line: to make glReadPixels() work for overlays we'd need > a way to query the apps current context (which the the temp current > context has replaced).
I don't follow your explanation. VirtualDrawable::readPixels() will never be called for an overlay, because overlay rendering is passed through to the 2D X server (and thus is really only useful with the VGL Transport and a 3D adapter on the client, so it somewhat defeats the purpose of VGL anyhow.) Overlay support was, incidentally, implemented back in the Sun days because a particular oil & gas customer demanded it, on account of one app they had that still required it. The idea was that, even though they still needed Exceed 3D on the client, switching to server-side rendering at least prevented all of the 3D data/commands (except the ones used to draw the overlay) from being transmitted over the network every time the frame was rendered. I have no doubt that whatever app that was has since been rewritten or retired, and it would likely be a safe move to discontinue overlay support in VirtualGL-- but it's one of those things that, as long as it doesn't get in the way of anything else, I don't have a problem with keeping it around. So when glReadPixels() is called internally, from one of the Virtual* classes, then overlayCurrent() will always be false, but per above, it's irrelevant in that case. We only care about overlays if glReadPixels() is called by the application and an overlay is current, in which case we need to pass through the call. So the existing logic works in that case. Now the question becomes how to handle the case in which an RGB context is current but the app calls glReadPixels(format==GL_COLOR_INDEX). It is unclear what is actually supposed to happen in that case, but VGL currently hands back the red channel of the Pbuffer, and actually that's what the nVidia driver does as well. So I think that the logic for glReadPixels() is fine as-is. Same goes for glDrawPixels(). In both of those calls, it isn't relevant whether the current context is color index or not. It's just relevant whether the app is requesting color index pixels. Note that fakerut tests for all of this. I strongly encourage using the "servertest" script, which attempts to perform various faker regression tests using fakerut, including color index rendering tests. Let me know if you encounter any problems with those tests. I made some modifications to your patch and added a check in fakerut to test for the condition (i.e. a test that will fail without the patch.) Everything is checked into trunk and seems to work. Please re-test it with MSC Mentat when you get a chance. ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
