Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Thread Tools
Old 01-27-09, 08:24 AM   #1
Registered User
Join Date: Dec 2008
Posts: 23
Default OpenGL shared context performance


I have an interesting performance issues that's cropped up on Linux with the latest nVidia driver (although I have no indication that it's a problem with the driver.)

I have a process with quite a few threads, I share an OpenGL context between two of those threads (the initial reason was to be able to load texture data from a different thread to the main display loop, but also helps with my VDPAU implementation.)

On OSX everything is fine, it all works as expected.

On Linux as soon as I make a call to glxMakeCurrent I seem to have a performance issue in that my CPU goes to 100% (this is a dual-core machine so it looks like only one thread has the issue), the program actually functions quite normally, just one of the cores pegged at 100%.

If I don't issue the glxMakeCurrent call, everything is fine.

I discovered this whilst trying to work out the a performance comparison of using vdpau and non-accelerated ffmpeg ... so I can't compare them at the moment, I'm especially interested since I have to drag the data back from vdpau so I can load it into a texture.

At the moment I'm using the same drawable for both threads and I have found a reference that implies using the same drawable is a problem ... I'm going to create a new drawable for the second thread to see if that fixes it, but any other help would be appreciated.


essele is offline   Reply With Quote
Old 01-27-09, 08:45 AM   #2
Registered User
Join Date: Dec 2008
Posts: 23
Default Re: OpenGL shared context performance

Ok, problem solved .. creating a Pbuffer and using that as the drawable instead of using the main one seems to fix the problem.

On my somewhat aged system, using standard DVB MPEG2 media, using non-accelerated ffmpeg, I used around 27% of a single core.

Using VDPAU it seems to jump around a bit but looks to average about 25% ... I'm quite suprised it's this high, but I'm assuming dragging the decoded data back from the GPU and then sending it all back again is fairly CPU intensive.

This doesn't include any deinterlacing, so this should improve the relative figures and obviously when I start looking at H264 this should get more interesting.

essele is offline   Reply With Quote
Old 01-28-09, 04:10 PM   #3
Registered User
Join Date: Jan 2009
Posts: 27
Default Re: OpenGL shared context performance

Hi Lee,

Interesting stuff. I'm working on something similar (I guess!), and wondered how you're going about pulling the decoded data off the GPU. I'm passing an X11 pixmap to vdp_presentation_queue_target_create_x11, and ultimately I'm able to pull data off this pixmap using XGetImage - but its terribly slow.

Edit - just found VdpOutputSurfaceGetBitsNative, do you read from the output surface with this?
motd2k is offline   Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Verizon's shared data plans won't save solo users much money News Archived News Items 0 06-12-12 10:40 AM
Unity 5.12 Fixes Ubuntu OpenGL Performance Problems News Archived News Items 0 06-11-12 01:20 PM
My UT2003 Tweak Guide DXnfiniteFX Gaming Central 48 10-30-02 11:59 PM
Major WineX prob... I think it has to do with the vidcard... Linewbie NVIDIA Linux 20 10-09-02 09:58 PM
Low OpenGL Performance Instinct NVIDIA Linux 10 08-08-02 03:56 PM

All times are GMT -5. The time now is 11:12 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.