VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1816 - 1818 of 16363)

Ticket Resolution Summary Owner Reporter
#7125 worksforme glsl in linux guest os does not work Marten van der Honing
Description

glsl in linux guest os (ubuntu 9.10) does not work when run on the host the glsl application works. under windows xp guest it also does work both use the same host linux os (ubuntu 10.04) with ati binary driver if needed i can supply additional detailed info on request

#11905 fixed glXChooseFBConfig Fails for Choosing Depth Buffering (0xc) (Linux Guest) Geometrian
Description

In some OpenGL programs on Linux guests, glXChooseFBConfig will fail:

OpenGL Warning: glXChooseFBConfig returning NULL, due to attrib=0xc, next=0x18

Attribute 0xc is "GLX_DEPTH_SIZE", and removing this record from the list of attributes passed to glXChooseFBConfig alleviates that problem, but of course does not allow one to choose a depth buffer.

Searches revealed that this problem occurs in conjunction with VirtualBox, though I seem to be first to notice the correlation. My test environment is a Windows 7 Professional x86-64 hosting a Ubuntu 12.04 x86-64 guest. The host has updated graphics drivers. The guest does not report any proprietary drivers, but the guest additions are installed and 3D acceleration is enabled.

#10894 fixed glXBindTexImageEXT is not compliant -> fixed as of 1 Oct 2012 (4.2 and later) smspillaz
Description

glXBindTexImageEXT opens a new X connection on the first time it is invoked when the client may have a server grab. This is not compliant with the specification:

http://developer.download.nvidia.com/opengl/specs/GLX_EXT_texture_from_pixmap.txt

  1. Should users be required to re-bind the drawable to a texture after

the drawable has been rendered to?

It is difficult to define what the contents of the texture would be if we don't require this. Also, requiring this would allow implementations to perform an implicit copy at this point if they could not support texturing directly out of renderable memory.

The problem with defining the contents of the texture after rendering has occured to the associated drawable is that there is no way to synchronize the use of the buffer as a source and as a destination. Direct OpenGL rendering is not necessarily done in the same command stream as X rendering. At the time the pixmap is used as the source for a texturing operation, it could be in a state halfway through a copyarea operation in which half of it is say, white, and half is the result of the copyarea operation. How is this defined? Worse, some other OpenGL application could be halfway through a frame of rendering when the composite manager sources from it. The buffer might just contain the results of a "glClear" operation at that point.

To gurantee tear-free rendering, a composite manager would run as follows:

-receive request for compositing: XGrabServer() glXWaitX() or XSync() glXBindTexImageEXT()

<Do rendering/compositing>

glXReleaseTexImageEXT() XUngrabServer()

This results in a deadlock on startup with recent versions of compiz.

A patch to fix this is attached.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy