On 11-11-29 07:25 PM, DRC wrote:
> This is now implemented in trunk. Setting
See, this is why I wanted to send a patch with my reply; otherwise I end
up spending my *whole* day looking at trace files instead of getting to
a bit of code. :)
> VGL_DEFAULTFBCONFIG=GLX_STENCIL_SIZE,8
>
> should produce the desired behavior with Abaqus.
My quick look at the code diff makes me I think we need to append a
terminating "None" attribute, but otherwise it looks capable.
> Please test and let me
> know. If it fixes the app, then I'll document the feature and add the
> app recipe. Also, can you provide more details about how it is drawing
> incorrectly whenever it doesn't have a stencil buffer?
I haven't even built it yet, but will try tomorrow. Unfortunately
Abaqus is one of those "somebody else has the app" situations. I'll
check in the morning if we have a screenshot of what goes wrong, but it
may not be quick to get a confirmation of the fix.
> Note that you can also specify other GLX attribs in a comma-separated
> list, but the only ones that seem to have any effect are GLX_ALPHA_SIZE,
> GLX_STENCIL_SIZE, GLX_SAMPLES, and GLX_SAMPLE_BUFFERS.
>
> Also, I notice that there are already two app recipes for Abaqus v6.
> Did you implement those recipes in your configuration, or are they even
> necessary anymore?
I'll see what I can find out; again timeframes are out of my control.
There doesn't seem to be an eval for Abaqus.
-Nathan
> On 11/29/11 4:38 PM, Nathan Kidd wrote:
>>
>> 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<[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
