Syphon Virtual Screen (again!)

Home Forums Syphon Syphon Implementations – User Syphon Virtual Screen (again!)

This topic contains 50 replies, has 13 voices, and was last updated by  scratchpole 3 years, 3 months ago.

Viewing 20 posts - 1 through 20 (of 51 total)
  • Author
    Posts
  • #6169

    Andrea Cremaschi
    Participant

    Hi,

    I just baked a new version of Syphon Virtual Screen (build 5), hope that someone find it useful. This corrects a bug that prevented SVS to work on MBPs with dual GPU (thanks anome for the bugfix!).

    https://rapidshare.com/files/3951236161/SyphonVirtualScreen.pkg

    So, what is SVS?

    “Syphon Virtual screen is a tool to share video output in applications that can go full-screen but are not yet Syphon-enabled (I use it with QLab, waiting for Qlab 3!)

    The framebuffer it draws on is developed by Enno Welbers (here on GitHub: https://github.com/mkernel/EWProxyFramebuffer Thanks Enno!). It resides in CPU memory, so maybe it could not be the best solution for heavy video processing: every frame has to be uploaded to the GPU RAM to be published on a syphon server, and this is a (relatively) slow operation. The best would be having native Syphon support in the application you target of course, but if you’re here it means you can go that way.. But still it can be helpful to hijack an application video output that is not Syphon-enabled. As for now, this is the only solution with QLab, while we wait for a real support in the application. SVS has been reported to work flawless on a 2048×768 texture.”

    All the code can be find here:
    https://github.com/andreacremaschi/Syphon-virtual-screen

    #6172

    vade
    Keymaster

    This is great work. Thank you so much for your support of Syphon and its ecosystem!

    #6173

    Anome
    Participant

    Great Andrea. Thanx Enno also, that helps me to find OpenGL direct instructions 🙂
    It’s really using less CPU than my app test !

    Now, time for me to prepare my tutorial QLab-to-Millumin !

    #6174

    Andrea Cremaschi
    Participant

    Thanks vade and anome!

    Actually, anome bugfix broke the banks: the code has been improved again (thx fernLightning!) and CPU usage is under 4% on my machine. I think it’s the best we can hope to have for non-Syphon enabled applications for now.

    https://rapidshare.com/files/3975409114/SyphonVirtualScreen.pkg

    (link above is broken)

    Happy video-output hijacking!

    #6175

    vade
    Keymaster

    Hey Andrea, there may be some faster ways to make this truly OpenGL accelerated. In 10.8, there is a new display capture API (CGDIsplayStream), and in preparation for 10.8, I’ve written a very fast screen capture plugin for Quartz Composer. I wonder if you can use the proxy frame buffer, but then grab the frames off of the GPU (if they ever get there? Im unsure?)

    Anyway, its worth looking at:

    https://github.com/v002/v002-Media-Tools/blob/master/v002%20Media%20Tools/v002_Screen_CapturePlugIn.m

    #6176

    Anome
    Participant

    Hello !

    Installation is now ok for me (Snow Leopard and Lion).
    Works great, almost no CPU use, but GPU is working. Anyway, something has to do the job 😉

    Thanx Andrea, Vade and Bangnoise, because now it’s so easy to make QLab talks to other app.
    Syphon Virtual Screen is so light and efficient !

    @_Vade : the extension used by Andrea (EWProxyFramebuffer) is not using the GPU/OpenGL, rather the CPU to emulate the display, and copy the pixels. As far as I know …

    #6177

    vade
    Keymaster

    Yes, I understand that 🙂

    However, the OS may be already making a surface out of it, and the new API is used for GPU to GPU screen capturing. What I am saying is this new API may be a faster path. Or not.

    #6178

    Andrea Cremaschi
    Participant

    @vade: thanks for the hint about CGDisplayStream, is there any reference about that? It may be worth trying. Even though handling with CoreGraphics brought me issues in the past, since I haven’t find a proper way to get the CGDisplayID of a given framebuffer/physical device.

    #6179

    baby-rabbit
    Participant

    These new APIs of 10.8 are well hidden.

    #6184

    baby-rabbit
    Participant

    Andrea – try the following:

    CGDirectDisplayID display[32];
    uint32_t displayCount = 0;
    CGGetActiveDisplayList(32, display, &displayCount);
    for(int i = 0; i < displayCount; i++) {
    io_service_t service = CGDisplayIOServicePort(display[i]);
    CFStringRef nameRef = IORegistryEntryCreateCFProperty(service, CFSTR("CFBundleIdentifier"), kCFAllocatorDefault, 0);
    if(CFStringCompare(nameRef, CFSTR("info.ennowelbers.framebuffer"), 0)==0) {
    // success! - display[i] is the display using the proxy framebuffer
    }
    }

    #6187

    Andrea Cremaschi
    Participant

    Yes, that will do, thank you! Too bad I can’t switch to 10.8 on my mac, or I’d be glad to test CGDisplayStream function myself: feel free to fork the project on github!

    #6198

    baby-rabbit
    Participant

    CGDisplayStream does indeed work very well, however on the virtual screen the performance is about the same as mapping the memory of the ewproxyframebuffer.

    Driver monitor says that on this display (and the virtual display only) that the driver is busy uploading bytes to the IOSurface when using CGDisplayStream.  Furthermore, probing the display with CGLQueryRendererInfo() shows that only the software renderer is available.

    So this is as Anome said earlier – the virtual display is not using the GPU directly – which  suggests that whatever API is used to access it to build IOSurfaces, is going to result in GPU/CPU bus traffic.

     

    #6200

    vade
    Keymaster

    Cool. My thought process was that potentially, the window server manages uploading that software screen to an offline GPU, thus the IOSurface backing would be on the GPU, not CPU.

    Worth trying…

    • This reply was modified 5 years, 6 months ago by  vade.
    #6205

    Andrea Cremaschi
    Participant

    Ok so the next step further would be to write a real virtual screen simulator (not a virtual frame buffer as ewproxyfb is), that would make the GPU driver allocate a GPU memory front-buffer. But this is far beyond my reaches, and driver documentation is really poor, and I’m sooo satisfied with this last version of SVS 🙂
    thx fernlightning, again!

    #6217

    baby-rabbit
    Participant

    The only similar osx project I’m aware of is http://code.google.com/p/ioproxyvideofamily/, but it looks like the same approach as ewproxyfb.

    #6218

    Anome
    Participant

    Hello.

    I post this tutorial for QLab and Millumin, using Syphon Virtual Screen.
    —> Videomapping, QLab and Millumin

    Thank for your great job. Philippe

    #15081

    eugenyo
    Participant

    Hi Andrea! Thanks a lot for the SVS, it´s geat! I´ve used it to connect Q-lab with Madmapper, and it worked on the first attempt! Now a question about it! I nead to send an big image to madmapper to send it to 2 projectors over a Dualhead. Is there some posibillity to  use different resolution than the listed in the menu? I nead 2800 x 1050 for two SXGA+ projectors. Thanks a lot

    Eugenio

    #15134

    Andrea Cremaschi
    Participant

    Hi Eugenio,
    yes, it is possible to use a custom virtual screen size without even recompiling the framebuffer, but you have to edit the kext configuration.

    Just do this:
    – open the Terminal
    – type “sudo su”, enter, type your password
    – type “cd /System/Library/Extensions/EWSyphonProxyFramebuffer.kext/Contents/”
    – type “nano Info.plist”
    – search this section:
    MaxResolution

    height
    1024
    width
    1280

    and replace max height and width as you need to

    – a little above this section you’ll find a list of available resolutions. Add yours:

    height
    2048
    name
    2048×768
    width
    768

    – type “Ctrl+X” to save your editing

    – now, back in terminal, you have to repair permissions for the driver you’ve just modified. Type:
    “sudo chmod -R 755 /System/Library/Extensions/EWSyphonProxyFramebuffer.kext”
    “sudo chown -R root:wheel /System/Library/Extensions/EWSyphonProxyFramebuffer.kext”

    – delete the kext cache (“rmdir -R /System/Library/Caches/com.apple.kext.caches/Startup”);

    – reboot

    Let me know if everything went ok,
    a.

    #15135

    eugenyo
    Participant

    Hi Andreas! Thanks a lot for the fast answer!!

    My OS is in Spanish, so i asume it is cd /Sistema/Librería/Extensions…. but anyway there´s no folder or file called EWSyphonProxyFramebuffer.kext

    There is one called EWProxyFramebuffer.kext but it tell me no such a file found. So i can not go further than the second line in the terminal! Any suggestion?

    Thanks again!

    Eugenio

    #15136

    eugenyo
    Participant

    I kept trying and i´ve noticed that it is the same if you put the route in English. Then i edited the EWProxyFramebuffer.kext and there is no resolution information, so definitivle theres not the right folder!

    Thanks

    E

     

Viewing 20 posts - 1 through 20 (of 51 total)

You must be logged in to reply to this topic.