[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg
Subject: Re: combining Render's Composite + SHM's PutImage
From: Aaron Plattner <aplattner () nvidia ! com>
Date: 2015-04-20 15:11:21
Message-ID: 55351719.9030708 () nvidia ! com
[Download RAW message or body]
On 04/16/2015 06:56 PM, Nigel Tao wrote:
> On Fri, Apr 17, 2015 at 5:53 AM, Aaron Plattner <aplattner@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.
Yes, that sounds like the right approach to me.
> 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.
It's not always the case, but that's a good mental model. The driver
will kick pixmaps out of video RAM and into system RAM for a variety of
reasons, but it'll generally move it back to video RAM if you try to use it.
>> 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.
You should be able to create a GC for a Pixmap directly, rather than
using a dummy window. Or am I misunderstanding what your dummy window is
for?
It might make sense to do your rendering code using a library like Cairo
that can take care of the behind-the scenes X11 work for you.
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic