Re: cario and shmget problems

[David Chisnall]

Ah, that makes sense.  They haven't removed XShm, only the part that allows 
sharing something that is blitted directly to the frame buffer (which hasn't 
made sense on a modern GPU architecture for over a decade) and discouraged the 
use of SHM in general (for a similar reason).  

If GNUstep is using XShmPixmap, then it will break but, looking at the code, we 
correctly test for SHM pixmap availability, and only use it if it's there (we 
probably shouldn't use it at all, because it's a horrible design that doesn't 
make sense on any graphics card that is much more complicated than a simple 
framebuffer, but I digress).

The error that Riccardo got is complaining that shmget() can't allocate memory, 
which sounds more like a resource leak.  This actually has nothing to do with 
X11 - the error message is generated in response to a system call failing, not 
in response to an X11 event.  The most likely cause of this is that we are 
allocating a lot of shared memory segments and leaking them.  Shared memory is 
generally a more scarce resource than local memory.  On FreeBSD, for example, 
the default only allows 128 shared memory objects per process and 8192 pages of 
shared memory.  If we're leaking shared memory, it's very easy to go over this 
limit.  

In fact, the use of shared memory with the Cairo back end is currently 
completely wrong - it may work, but it's a design that will give absolutely the 
worst possible performance possible from Cairo, because we're implicitly 
telling Cairo not to use hardware acceleration for drawing and then telling the 
X server to perform a redundant copy if it wants to do hardware acceleration.  
This is something that Opal will fix by not trying to make Cairo look like 
libart, so I'm not sure if it's worth bothering chasing a short-term fix.

David

On 9 Jul 2010, at 10:42, address@hidden wrote:

> Hi!
> 
> I really do not know what Xshm has to do with the drivers, but X and all it's 
> accelerating APIs are a mess I am not able to understand.  See the following 
> thread.
> 
> http://www.mail-archive.com/address@hidden/msg56985.html
> 
> After upgrading my NVIDIA drivers to a version above 18x.xx I got the same 
> message regarding Xshm as Riccardo got.
> 
> TOM
> 
> Zitat von David Chisnall <address@hidden>:
> 
>> On 9 Jul 2010, at 09:32, address@hidden wrote:
>> 
>>> NVIDIA dropped XShm support in their 19x.xx drivers.
>> 
>> How?  XShm doesn't have anything to do with the drivers, it's purely for 
>> transporting large amounts of data between the client and X server 
>> efficiently, and happens long before the driver is invoked.  Removing XShm 
>> would have a serious negative impact on performance, so I can't imagine 
>> nVidia would do this even if it were possible to do at the driver layer.
>> 
>> Or, as they say in Wikipedia-land: [citation needed]
>> 
>> David
>> 
>> -- Sent from my Cray X1
>> 
>> 
> 
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev


-- Sent from my Cray X1