Sorry for the delay. I think in the spirit of keeping things simple,
and not letting the perfect become the enemy of the good, going with a
VGL_DEFAULTCONFIGATTRIBS={syntax}
style patch is the best approach. The name is long, but it helpfully
describes what's going on, and is the kind of thing that gets scripted
anyway.
For {syntax}, I propose to implement just groking the word "stencil" to
indicate stencil required. Full word for same reasoning as env var name.
As you noted, such an approach can later be expanded to grok any amount
of attribs, and even values for them, within the same framework.
If this is cool with you I will work on a patch and try to get it out
this week. If I don't get it to you before you want to tag 2.3 don't
worry about it for OpenText's sake; we roll our own builds anyway.
-Nathan
On 11-11-21 07:25 PM, DRC wrote:
> Glad to hear that you're doing better, and I apologize for the delay in
> responding to this (been in and out of the office the past couple of
> weeks.) I guess my main concern is still that I don't want VirtualGL to
> have to rely on any aspect of the 2D X server in order to work properly.
> That means that it can't assume that there are multiple visuals
> available. Unless there is a way to allow the app to do the "right
> thing" when there is only one visual available, my preference would be
> to just implement the VGL_CONFIGWITHSTENCIL environment variable. We
> could maybe get smarter about this and change it to a more generic
> environment variable that had a symbolic code representing the
> attributes that were desired (such as "s" for stencil, etc.) It
> wouldn't be the first time that it was necessary to set a particular
> environment variable to make a particular app work. The typical
> progression of these things is that we'll implement some sort of hack
> like this and document it in the App Recipes section, then we'll often
> come up with a better solution in a future release that doesn't require
> a recipe for that app anymore.
>
> I start to wonder whether it wouldn't be worth it to just fake
> XGetVisualInfo() and XMatchVisualInfo() and maintain our own internal
> list of visuals in VirtualGL. Am I correct in asserting that those
> would be the only two X11 functions that we'd have to fake to make that
> happen? Something in the deep recesses of my memory is saying that I
> broached that subject before and found it unappealing for some reason,
> but now I can't remember why. Seems like we could just take a "real"
> visual from the 2D X server and wrap multiple XVisualInfo structures
> around it, all with different VisualID's, and internally these could
> correspond to the available FB configs that have appropriate attributes
> for VirtualGL. It would hopefully allow us to get rid of the visual
> matching stuff, which I've always found to be somewhat hackish.
>
> At any rate, that solution would be post-2.3 for sure, since we're
> already in beta, but the VGL_CONFIGWITHSTENCIL hack is non-disruptive
> and could be included in 2.3, along with a recipe for Abaqus 6.10.
>
>
> On Nov 10, 2011, at 7:19 PM, Nathan Kidd<nathan...@spicycrypto.ca> wrote:
>> Hi Darrell,
>>
>> After several months I'm thankful to be starting a slow functional
>> comeback. It was pleasant to read all you've been up to since June.
>>
>> On 11-07-15 04:48 AM, DRC wrote:
>>> I was able to actually reproduce this, completely by accident. I use a
>> ...
>>> so I had to add GLX_DEPTH_SIZE, 1 as well.
>>
>> Many months ago Nathan Kidd wrote, regarding your patch (in r4417):
>>>>> I'm waiting to hear back on this test but hopefully will get a result
>>>>> soon.
>>
>> I never was able to get that tested with HFSS. It seems the folks with
>> HFSS were so busy that as soon as my original patch worked they were on
>> to something else. However, since you ended up reproducing that same
>> weird StaticGrey behaviour I'm confident HFSS will work also.
>>
>> Many months ago Nathan Kidd wrote:
>>>> if somebody comes
>>>> along in the future with an app that manually chooses its visual via
>>>> glXGetConfig and requires say, a stencil buffer, we could always
>>>> introduce a "VGL_DEFAULTCONFIGWITHSTENCIL" option to modify the attrib
>>
>> Here we are in the future and it turns out Abaqus 6.10 CAE is exactly
>> one such app; wrong drawing because it needs a stencil buffer, wants to
>> do manual visual selection via glXGetConfig(), and we return the same
>> set of (stencil-less) attribs for every config.
>>
>> Now, I can produce the same kind of patch as r4417 but adding a
>> GLX_STENCIL_SIZE attrib and a fallback to disable that attrib if no
>> configs found, which would be only a couple lines of code changed.
>> I don't really like this approach since (in my limited understanding of
>> GL driver internals) the app will use more memory with the stencil
>> buffer, and may be somewhat slower too.
>>
>> I could create a patch that introduces the before-theorized
>> VGL_CONFIGWITHSTENCIL (or similar) to enable the above behaviour only
>> when set. This forces the end user to know about what the app does
>> internally and to manually set the right flag. Not very pretty when the
>> app could do the right choosing if given a chance.
>>
>> I know you weren't too keen on the last patch I proposed to provide a
>> full variety of visuals by default. One of the factors was that the
>> patch wasn't helpful for servers (e.g. VNC) that only export one visual.
>> Another factor I think was just the size the patch. If I were to
>> rework that idea to be fewer lines, and possibly add in some
>> VGL_CONFIGWITH(DEPTHSIZE|STENCILSIZE|AUXBUFFERS) environment variables
>> for the case where only one visual is available, would you consider such
>> a patch?
>>
>> As time goes on I can see apps that want aux buffers, multisample, etc.
>> and so I still like the idea of the last approach. However, as much as
>> I don't like the game of whack-a-mole for every app that is broken from
>> the same underlying issue, I also want to provide a patch that will get
>> accepted, thus I'm trying to feel out an approach you like too.
>>
>> Take care,
>>
>> -Nathan
>>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
