On Fri, Apr 17, 2015 at 5:53 AM, Aaron Plattner <aplatt...@nvidia.com> wrote: > SHM pixmaps are only allowed if the driver enables them. It's the > application's job to check before trying to create one. In NVIDIA's case, > we disabled them because they can't be accelerated by the GPU and are > generally terrible for performance. > > You can query it with "xdpyinfo -ext MIT-SHM"
Ah, SHM QueryVersion will do this programatically. Thanks. > I'm not sure why you're using shared memory to begin with. Especially if > you're just doing alpha blending, you're almost certainly much better off > using OpenGL or the X11 RENDER extension to let the GPU do the graphics > work. Yes, I want to use Render. I also want to avoid copying millions of pixels between X client and X server processes via the kernel, so I want to use SHM too. > At least for NVIDIA, you're going to need to copy the pixels into video RAM > at some point anyway. If you can upload the pixels to the GPU once and then > leave them there, that's your best bet. Ah, so what ended up working for me is to create a new (regular, non-SHM) Pixmap, call SHM PutImage to copy the pixels to the Pixmap, then use Render with that Pixmap as source. For NVIDIA, does a (server-side) Pixmap always mean video RAM and not general purpose RAM? Either way, it works for me, but it'd help my mental model of what actually happens on the other side of the X connection. > Generally, you only want to use the 32-bit visual if you expect the alpha > channel of your window to be used by a composite manager to blend your > window with whatever's below it. If you're just doing alpha blending > yourself in order to produce opaque pixels to present in a window, you > should use a 24-bit visual and do your rendering using OpenGL or an > offscreen 32-bit pixmap. Yeah, I eventually got it working without any Bad Match errors. My window contents needed its own (depth-24) Visual (i.e. the Screen's RootVisual), GContext and Pictformat, and my source pixels (an offscreen pixmap that may or may not be a SHM pixmap) separately needed its own (depth-32) Visual, GContext, Pictformat and Colormap. I'm not sure if there's a better method, but I also made an unmapped 1x1 depth-32 Window just get that GContext. It all makes sense, in hindsight. It just wasn't obvious to me in foresight. I'd like to avoid using OpenGL if possible. I'm using the Go programming language, and can write a pure Go (no C) program that uses the equivalent of XCB. IIUC, using OpenGL requires using Xlib instead of XCB (or an equivalent of XCB), and I'd prefer to avoid depending on Xlib and any potential issues with mixing goroutines (Go green threads, roughly speaking) and OpenGL and Xlib's threading model. _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s