winfaker

2008-09-30
2013-11-26
  • andy onions

    andy onions - 2008-09-30

    I'm working with Jeremy Barnsley on a project using VirtualGL and have been researching the Windows version of the project. Looking at your winfaker code, I've come up against a few issues. I had a bit of a problem getting it running initially as it was bombing out without logging, which I eventually tracked down to an exception being thrown by unimplemented Windows mutex functionality, which you've since updated. I should have got the logging going earlier:-)

    vglrun wglspheres works fine executed on a local machine with VirtualGL compatible hardware. I get the full hardware acceleration as expected and my own timings suggest that about half the time is spent rendering and reading back pbuffer and the other half the time is spent reinverting the image and redrawing it to the on screen window. I just assumed that running this through a Terminal Services session would work, with the virtualized Windows stuff being redirected over RDP usings its bulk compression, but it doesn't...

    My issues are:-

    1) Running wglreadtest directly on a server worked fine, but gave an error when invoked with vglrun. Basically, it throws an exception in faker.cpp

    if(!pf) _throw("Current pixel format was not obtained using ChoosePixelFormat().  I'm stymied.");

    which I track down to directly created pixelbuffers not being hashed like the indirectly created buffers (in faker) and the de-hash function not finding them. If I replace the line with

    if(!pf) return __wglCreateContext(hdc);

    wglreadtest works directly AND through vglrun (although, not knowing enough about Windows, this may not be a good solution)! Faker isn't doing a great deal here:-)

    2) Attempting to run wglreadtest or wglspheres through a terminal services (RDP) session from a client, I get various errors.

    i) wglspheres (directly) works fine, but obviously, I get no virtualGL, so get slow software rendering. This of course goes nowhere near Pbuffers:-)

    ii) wglreadtest (directly) gives errors (I've added additional logging so line numbers are no use)

    WGLREADTEST_loadsymbols: Creating temporary context ........
    WGLREADTEST_loadsymbols: Finding ARB functions
    135: Could not load symbol wglCreatePbufferARB

    iii) vglrun wglspheres gives similar errors (they're a bit more detailed)

    FAKER___vgl_loadsymbols: Creating context with hdc=........
    FAKER___vgl_loadsymbols: calling wglGetProcAddress(wglChoosePixelFormat)
    FAKER___vgl_loadsymbols: error=127, wglProcAddress=00000000

    ii) and iii) taken together point alarmingly to the ARB (Pbuffer) extensions to OpenGL not being available to a virtualized windows client session from the server.

    I initially considered that the problem had to do with unimplemented functions for some pixel formats and made sure that the client was executing in a 24bit video mode as opposed to the original 16 bit mode (the server is running in a 32 bit mode), but this hasn't helped.

    My questions are:-
    Does a TS session support the ARB extensions (for server with VirtualGL hardware functionality)?
    Does windows substitute the OpenGL driver for a TS version of same - I assume this is actually the case since the software rendering for case i) has to come from somewhere?
    Or is there some other problem?
    Should winfaker work over a TS session?

    You'll have to excuse my lack of knowledge on some (many:-) )aspects of this stuff...

    Your comments would be greatly appreciated,

    Andy Onions

     
    • DRC

      DRC - 2008-09-30

      (1) is definitely on my plate to look at, because someone on our team discovered it as well.  He was having trouble using WinFaker with GLUT applications, and I think his problem is due to the same cause.  Your solution looks sound, but I'll double check it and put it back into the code if everything looks good.  I'm working on a code freeze for VirtualGL 2.1.1/TurboVNC 0.5 this week but should have time to look at the WinFaker issue more closely within the next couple of weeks.

      As far as (2), unfortunately you hit the nail on the head -- TS substitutes its own version of OpenGL, a software-only version.  We have tried many many ways to get hardware acceleration in a WTS session, but unfortunately (and this has been confirmed by those who know a lot more about its architecture than I do) this is impossible to do on XP.  There is some indication that MS is working on the capability for Vista, but for XP, you're stuck with software only, and the software implementation is somewhat backrevved (possibly OGL 1.1?) and lacks a lot of the extensions.

      The way we use WinFaker is with TurboVNC.  It's non-ideal, but it works pretty well (especially if you have a multi-core CPU and a recent PCI-Express graphics card.)

       
    • andy onions

      andy onions - 2008-09-30

      Thanks DCommander and a big THANK YOU to Microsoft:-)

      Jez is familiar with the TurboVNC stuff and we're adequately covered on the hardware front too:-)

      Thoughts are turning to other ways round this problem. We want the seamless windows integration that TS gives us, but it's evident that we have to get the hardware acceleration by some means too... Some form of VirtualGL should figure somewhere, even in a TS solution!

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks