Re: Jogl Using Wrong (Generic) Graphics Adapter
Posted by Sven Gothel on Nov 27, 2014; 8:43pm
URL: https://forum.jogamp.org/Jogl-Using-Wrong-Generic-Graphics-Adapter-tp4033216p4033660.html
On 11/27/2014 04:09 PM, Tobi Delbruck [via jogamp] wrote:
> We are having what could be a related problem. It could be that we are doing
> something wrong.
>
> We have a Swing-based application that sometimes has this problem of dropping
> back to 1.1 software rendering (is this GDI?).
>
> The problem occurs when more than one GLCanvas is created, which runs in a
> different thread and possibly different OpenGL context. I am not too clear on
> OpenGL contexts, profiles, capabilities etc so we could easily be doing
> something wrong. But this is a problem that did not occur in the past and only
> started after we went to JOGL 2.x; it did not occur when we were using JOGL
> 1.1.1.
>
> In our headless main method, we now create a dummy window and then in each
> slave we assign this shared context to the new GLCanvas. But still, after a
> random number of new windows are opened (which is machine dependent) we get
> the exception occurring.I remember another user had this issue as well
and it was related to either exhausted GL context and/or GPU memory.
Then the ICD GL driver switched to the GDI 1.1 software renderer.
This is not a JOGL issue.
AFAIK the issue was resolved either by updating the driver,
or even by avoiding the number of GL context or GPU memory utilization.
~2000 context count, is what I remember .. hmm, not so sure.
The exception then is caused due to requesting a higher profile
than the ARB context creation method can serve (see above).
Even though, the returned context is only 1.1. It would throw an
exception later anyway, due to non-compliant context.
To test the above resource restriction, you can sample some heuristics
while creating context until catching the exception.
Please share your results - thank you!
~Sven
URL: https://forum.jogamp.org/Jogl-Using-Wrong-Generic-Graphics-Adapter-tp4033216p4033660.html
On 11/27/2014 04:09 PM, Tobi Delbruck [via jogamp] wrote:
> We are having what could be a related problem. It could be that we are doing
> something wrong.
>
> We have a Swing-based application that sometimes has this problem of dropping
> back to 1.1 software rendering (is this GDI?).
>
> The problem occurs when more than one GLCanvas is created, which runs in a
> different thread and possibly different OpenGL context. I am not too clear on
> OpenGL contexts, profiles, capabilities etc so we could easily be doing
> something wrong. But this is a problem that did not occur in the past and only
> started after we went to JOGL 2.x; it did not occur when we were using JOGL
> 1.1.1.
>
> In our headless main method, we now create a dummy window and then in each
> slave we assign this shared context to the new GLCanvas. But still, after a
> random number of new windows are opened (which is machine dependent) we get
> the exception occurring.
and it was related to either exhausted GL context and/or GPU memory.
Then the ICD GL driver switched to the GDI 1.1 software renderer.
This is not a JOGL issue.
AFAIK the issue was resolved either by updating the driver,
or even by avoiding the number of GL context or GPU memory utilization.
~2000 context count, is what I remember .. hmm, not so sure.
The exception then is caused due to requesting a higher profile
than the ARB context creation method can serve (see above).
Even though, the returned context is only 1.1. It would throw an
exception later anyway, due to non-compliant context.
To test the above resource restriction, you can sample some heuristics
while creating context until catching the exception.
Please share your results - thank you!
~Sven
signature.asc (828 bytes) | Free forum by Nabble | Edit this page |