Menu
▾
▴
virtualgl-devel
|
From: Nathan K. <nat...@sp...> - 2011-11-11 02:18:18
|
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 |
|
From: DRC <dco...@us...> - 2011-11-22 00:25:33
|
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 <nat...@sp...> 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 > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > VirtualGL-Devel mailing list > Vir...@li... > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel |
|
From: Nathan K. <nat...@sp...> - 2011-11-29 22:40:24
|
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<nat...@sp...> 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
>>
|
|
From: DRC <dco...@us...> - 2011-11-29 22:47:51
|
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.
I'm fine with implementing the patch. Just mainly wanted your feedback
on it. What do you think of the more long-term proposal to fake
XGet/MatchVisualInfo()?
|
|
From: DRC <dco...@us...> - 2011-11-30 00:25:11
|
This is now implemented in trunk. Setting
VGL_DEFAULTFBCONFIG=GLX_STENCIL_SIZE,8
should produce the desired behavior with Abaqus. 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?
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?
The only ones that seem to have any effect are GLX_ALPHA_SIZE,
GLX_STENCIL_SIZE
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<nat...@sp...> 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
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
|
|
From: Nathan K. <nat...@sp...> - 2011-12-01 04:19:54
|
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<nat...@sp...> 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
|
|
From: DRC <dco...@us...> - 2011-12-01 05:06:19
|
On 11/30/11 10:16 PM, Nathan Kidd wrote: > My quick look at the code diff makes me I think we need to append a > terminating "None" attribute, but otherwise it looks capable. Why would it need that? Stripping the tokens from the environment variable automatically produces a terminated list. |
|
From: Nathan K. <nat...@sp...> - 2011-12-05 20:56:53
|
On 11-12-01 12:06 AM, DRC wrote: > On 11/30/11 10:16 PM, Nathan Kidd wrote: >> My quick look at the code diff makes me I think we need to append a >> terminating "None" attribute, but otherwise it looks capable. > > Why would it need that? Stripping the tokens from the environment > variable automatically produces a terminated list. Sorry, I meant to terminate the attrib list, but my late-night brain had missed the memset(0). I compiled and tested the code and it works fine for my simple test app. I'm still working to get confirmation with actual Abaqus. The Abaqus screenshots I got show a solid band blocking a large part of the model, which happens when the user applies the function “ViewCut”. The plain GLX trace (no VGL) shows the app selecting a visual with Stencil and using glStencilMask(). With a VGL patched to include stencil in the default visual (_MatchConfig) the app is reported to draw correctly. -Nathan |
|
From: DRC <dco...@us...> - 2011-12-05 21:51:42
|
On 12/5/11 2:54 PM, Nathan Kidd wrote: > Sorry, I meant to terminate the attrib list, but my late-night brain had > missed the memset(0). > > I compiled and tested the code and it works fine for my simple test app. > I'm still working to get confirmation with actual Abaqus. Cool. As soon as we can confirm this, I'll add the recipe and put out 2.3. Do you have any further insight as to whether this issue is specific to Abaqus 6.10? Seems like others have successfully used VGL with 6.9, since (per my previous comments) we already had some recipes for that version. |
|
From: Nathan K. <nat...@sp...> - 2011-12-06 02:53:34
|
On 11-12-05 04:51 PM, DRC wrote: > Do you have any further insight as to whether this issue is > specific to Abaqus 6.10? Seems like others have successfully used VGL > with 6.9, since (per my previous comments) we already had some recipes > for that version. I haven't had any report of anyone needing those two work-arounds. There may be a few causes: - Exceed onDemand supports transparent overlays. This could explain not needing the emulate overlays trick. Or maybe it was used but I wasn't told. - The 'vglrun'-type script in Exceed onDemand is something I wrote from scratch that relies on LD_LIBRARY_PATH. Last I looked the standard VGL package puts the libs into a system library path (/usr/lib) and thus doesn't use LD_LIBRARY_PATH. This could potentially explain the -nodl difference. - Or maybe Abaqus 6.10 is a completely different beast compared to 6.9. The stencil issue seems to be only with one specific function; perhaps it isn't commonly used and thus not previously reported. Unfortunately I think we're all in the same boat, that one never hears of what anyone is using except when there's a problem, and as soon as the problem is solved it is hard to get more details. -Nathan |
|
From: DRC <dco...@us...> - 2011-12-13 12:13:44
|
Actually, as I look more closely, the overlay issues were reported with both Abaqus 6.9 and 6.10: https://sourceforge.net/projects/virtualgl/forums/forum/401860/topic/4098980 However, the issue requiring the use of -nodl was reported only with 6.9, so it may not exist in 6.10. I guess that the overlay issues occur only if the X server doesn't support overlay visuals. One would think the app would be smart enough to automatically set ABAQUS_EMULATE_OVERLAYS to 1 if it detected that that was the case. Guess not. I'm going to go ahead and release 2.3, since it's overdue and we're reasonably confident that the VGL_DEFAULTFBCONFIG feature will fix Abaqus. On 12/5/11 8:51 PM, Nathan Kidd wrote: > I haven't had any report of anyone needing those two work-arounds. > There may be a few causes: > - Exceed onDemand supports transparent overlays. This could explain not > needing the emulate overlays trick. Or maybe it was used but I wasn't told. > > - The 'vglrun'-type script in Exceed onDemand is something I wrote from > scratch that relies on LD_LIBRARY_PATH. Last I looked the standard VGL > package puts the libs into a system library path (/usr/lib) and thus > doesn't use LD_LIBRARY_PATH. This could potentially explain the -nodl > difference. > > - Or maybe Abaqus 6.10 is a completely different beast compared to 6.9. > > The stencil issue seems to be only with one specific function; perhaps > it isn't commonly used and thus not previously reported. > > Unfortunately I think we're all in the same boat, that one never hears > of what anyone is using except when there's a problem, and as soon as > the problem is solved it is hard to get more details. |
|
From: Nathan K. <nat...@sp...> - 2011-12-22 20:12:09
|
On 11-12-13 07:12 AM, DRC wrote: > I'm going to go ahead and release 2.3, since it's overdue and we're > reasonably confident that the VGL_DEFAULTFBCONFIG feature will fix Abaqus. I just heard back today about testing with GLX_STENCIL_SIZE,8. The patch is it is working fine, but bad news is, they can't reproduce the problem any more. I have seen at a remote GLX trace where Abaqus does explicitly choose and use a stencil buffer. Previously a beta VGL that simply forced stencil on all the time did solve the problem. Knowing German thoroughness I believe the best explanation is not user confusion but that something is tickling Abaqus so sometimes it tries to use stencil and sometimes not. Thus, I think the app recipe is still useful, but should be qualified by "may require". The Abaqus Scripting Reference Manual (found by Google) doesn't mention any configuration setting for stencil (non)use. :( -Nathan |
|
From: DRC <dco...@us...> - 2011-12-22 22:14:20
|
On 12/22/11 2:10 PM, Nathan Kidd wrote: > On 11-12-13 07:12 AM, DRC wrote: >> I'm going to go ahead and release 2.3, since it's overdue and we're >> reasonably confident that the VGL_DEFAULTFBCONFIG feature will fix Abaqus. > > I just heard back today about testing with GLX_STENCIL_SIZE,8. The > patch is it is working fine, but bad news is, they can't reproduce the > problem any more. > > I have seen at a remote GLX trace where Abaqus does explicitly choose > and use a stencil buffer. Previously a beta VGL that simply forced > stencil on all the time did solve the problem. Knowing German > thoroughness I believe the best explanation is not user confusion but > that something is tickling Abaqus so sometimes it tries to use stencil > and sometimes not. Thus, I think the app recipe is still useful, but > should be qualified by "may require". > > The Abaqus Scripting Reference Manual (found by Google) doesn't mention > any configuration setting for stencil (non)use. > > :( Well, that is sort of what was happening with whatever other app it was that prompted this thread to begin with. It was only sometimes choosing a StaticGray FBConfig. There's also a reported issue with Avizo that I can't reproduce but which seems to be the same sort of issue, only with multisampling rather than the stencil buffer (that user hasn't yet replied back as to whether VGL_DEFAULTFBCONFIG fixes it.) Whereas multisampling isn't really something we can choose for the user, I don't see any downside to always enabling a stencil buffer with the default FB config and allowing the user to override that with VGL_DEFAULTFBCONFIG=GLX_STENCIL,0. The overriding goal in VirtualGL is to eliminate app recipes, so being able to eliminate the Abaqus one would be a plus, even if we're eliminating it in a less than elegant way. |
|
From: Nathan K. <nat...@sp...> - 2011-12-01 04:31:47
|
On 11-11-29 05:47 PM, DRC wrote: > I'm fine with implementing the patch. Just mainly wanted your feedback > on it. What do you think of the more long-term proposal to fake > XGet/MatchVisualInfo()? I haven't thought too far through this, but to make an app that uses glXGetConfig to choose its own visual do the right thing we must make the app see a variety of visuals. If the server only has one visual, then, as I understand your direction of thought, we fake the XGet/MatchVisualInfo to list as many visuals as we want, and populate them with the local opengl attribs. To do this we need to make up fake visual IDs. The moment we give a fake visid to the app we have no control what it does with it. This ID will get used in the whole Xlib api. Any call that sends the visid must be hooked to do the translation to a real visid, and any reply back must also be hooked, again for translation. I didn't look exaustively, but I think that's a whole lot of APIs to hook. If we consider going down the road XCB will likely need to be supported I think it will only get more complex. Now, I haven't done my grepping to get hard numbers on how many places need hooks; maybe it isn't as bad as I'm imagining, but that's my initial reaction. -Nathan |
|
From: DRC <dco...@us...> - 2011-12-01 05:04:06
|
On 11/30/11 10:29 PM, Nathan Kidd wrote: > I haven't thought too far through this, but to make an app that uses > glXGetConfig to choose its own visual do the right thing we must make > the app see a variety of visuals. If the server only has one visual, > then, as I understand your direction of thought, we fake the > XGet/MatchVisualInfo to list as many visuals as we want, and populate > them with the local opengl attribs. To do this we need to make up fake > visual IDs. The moment we give a fake visid to the app we have no > control what it does with it. This ID will get used in the whole Xlib > api. Any call that sends the visid must be hooked to do the translation > to a real visid, and any reply back must also be hooked, again for > translation. I didn't look exaustively, but I think that's a whole lot > of APIs to hook. If we consider going down the road XCB will likely > need to be supported I think it will only get more complex. > > Now, I haven't done my grepping to get hard numbers on how many places > need hooks; maybe it isn't as bad as I'm imagining, but that's my > initial reaction. That jogged my memory as to why I thought it was a bad idea previously. I had forgotten that Visual ID's are used internally by Xlib as well as exposed to the application. Oh well. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X