Menu
▾
▴
chromium-dev
|
From: Mike H. <mho...@gr...> - 2005-01-28 22:21:48
|
The changes to visbits seem to have broken all sort-last rendering. As a simple example, try readback.conf with atlantis or psubmit_last.conf. We seem to complain that we can't get the necessary visual for anything... Backing off to before the large stack of changes to the visbits gets everything working happy again. Can someone else please verify this behavior before we start trying to track this down? Thanks, -Mike |
|
From: Brian P. <bri...@tu...> - 2005-01-29 12:55:28
|
Mike Houston wrote: > The changes to visbits seem to have broken all sort-last rendering. As > a simple example, try readback.conf with atlantis or psubmit_last.conf. > We seem to complain that we can't get the necessary visual for > anything... Backing off to before the large stack of changes to the > visbits gets everything working happy again. > > Can someone else please verify this behavior before we start trying to > track this down? Hmmm. Both those demos work for me. And my recent visBits changes have overall solved several problems for me, so they can't be totally wrong. Could I see all the debug output from the app/server nodes? Is this on Linux or Windows? Which cards/drivers? -Brian PS: I found a one-line check-in mistake in renderspu_glx.c that'll I'll fix, but it doesn't change anything here. |
|
From: Mike H. <mho...@gr...> - 2005-01-29 18:28:22
|
This is on Linux, on ATI hardware with 3.14.6 as well as the newest release. When I get back in on Monday, I'll take a deeper look and send you the output. It is bailing out as soon as the default context is being created. It's trying for visual 0x27 (RGBA, double, Z) and can't get it. Sort-first apps work just fine as well as the sort last apps running locally. -Mike Brian Paul wrote: > Mike Houston wrote: > >> The changes to visbits seem to have broken all sort-last rendering. >> As a simple example, try readback.conf with atlantis or >> psubmit_last.conf. We seem to complain that we can't get the >> necessary visual for anything... Backing off to before the large >> stack of changes to the visbits gets everything working happy again. >> >> Can someone else please verify this behavior before we start trying >> to track this down? > > > > Hmmm. Both those demos work for me. And my recent visBits changes > have overall solved several problems for me, so they can't be totally > wrong. > > Could I see all the debug output from the app/server nodes? > > Is this on Linux or Windows? > > Which cards/drivers? > > -Brian > > PS: I found a one-line check-in mistake in renderspu_glx.c that'll > I'll fix, but it doesn't change anything here. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev |
|
From: Brian P. <bri...@tu...> - 2005-01-29 20:00:24
|
Mike, on the readback SPU, try spu.Conf('use_glxchoosevisual', 0)
This tells the Render SPU to not call glXChooseVisual. For some
reason, the call doesn't get resolved to the ATI libGL routine, but
instead, to the faker's glXChooseVisual. (Of course, this only
happens when the render/readback SPU is hosted by the app node.)
I think the problem is ATI's libGL wasn't linked with the -Bsymbolic
option. But that doesn't explain why glXGetConfig works. Strange.
The code path for use_glxchoosevisual = 0 was previously the default
in the Render SPU, but it was causing problems with the NVIDIA drivers
in particular configurations. So, the bug work-around is now chosen
with the config option.
I hope that fixes things for you.
-Brian
Mike Houston wrote:
> This is on Linux, on ATI hardware with 3.14.6 as well as the newest
> release. When I get back in on Monday, I'll take a deeper look and send
> you the output. It is bailing out as soon as the default context is
> being created. It's trying for visual 0x27 (RGBA, double, Z) and can't
> get it. Sort-first apps work just fine as well as the sort last apps
> running locally.
>
> -Mike
>
> Brian Paul wrote:
>
>> Mike Houston wrote:
>>
>>> The changes to visbits seem to have broken all sort-last rendering.
>>> As a simple example, try readback.conf with atlantis or
>>> psubmit_last.conf. We seem to complain that we can't get the
>>> necessary visual for anything... Backing off to before the large
>>> stack of changes to the visbits gets everything working happy again.
>>>
>>> Can someone else please verify this behavior before we start trying
>>> to track this down?
>>
>>
>>
>>
>> Hmmm. Both those demos work for me. And my recent visBits changes
>> have overall solved several problems for me, so they can't be totally
>> wrong.
>>
>> Could I see all the debug output from the app/server nodes?
>>
>> Is this on Linux or Windows?
>>
>> Which cards/drivers?
>>
>> -Brian
>>
>> PS: I found a one-line check-in mistake in renderspu_glx.c that'll
>> I'll fix, but it doesn't change anything here.
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>> Tool for open source databases. Create drag-&-drop reports. Save time
>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>
|
|
From: Mike H. <mho...@gr...> - 2005-01-31 19:29:32
|
That fixes readback.conf, but now crut programs are borked. For example, crut_fan.conf. When crserver tries to bind to the crutserver window, I now get this on the crserver side: CR Debug(spire:19914): Looking for the system's OpenGL library... CR Debug(spire:19914): Found it in default path. CR Debug(spire:19914): Render SPU: Creating default window (visBits=0x25, id=0) CR Debug(spire:19914): Render SPU: Opening display :0.0 CR Debug(spire:19914): Render SPU: Looks like we have GLX CR Debug(spire:19914): Render SPU: Chose visual id=0x29: RGBA=(8,8,8,8) Z=24 ste ncil=0 double=1 stereo=0 accum=(0,0,0,0) CR Debug(spire:19914): Render SPU: Created window 0x3600001 on display :0.0, Xvi sual 0x29 CR Debug(spire:19914): Render SPU: actual window x, y, width, height: 500, 500, 400, 400 CR Debug(spire:19914): Render SPU: WindowCreate returned 0 (0=normal) CR Debug(spire:19914): Render SPU: Creating default context, visBits=0x25 CR Debug(spire:19914): Render SPU: Created DIRECT context (0) on display :0.0, X visual 0x29 CR Warning(spire:19914): Couldn't find the CRMOTHERSHIP environment variable, de faulting to localhost CR Debug(spire:19914): In crNetConnectToServer( "localhost", port=10000, mtu=809 6, broker=0 ) CR Debug(spire:19914): Connecting to server spire.stanford.edu on port 10000, wi th protocol tcpip CR Debug(spire:19914): Done connecting to server localhost (swapping=0) CR Debug(spire:19914): Render SPU: using CRUT drawable: 0x3200001 CR Warning(spire:19914): Render SPU: Can't bind context 0 to CRUT/native window 0x3200001 because of different X visuals (0x27 != 0x29)! CR Debug(spire:19914): Render SPU: GL_VENDOR: (null) CR Debug(spire:19914): Render SPU: GL_RENDERER: (null) CR Debug(spire:19914): Render SPU: GL_VERSION: (null) CR Debug(spire:19914): Render SPU: ---------- End of Init ------------- CR Debug(spire:19914): CRServer: my clients: 1 tcpip 2 CR Debug(spire:19914): In crNetAcceptClient( protocol="tcpip" port=7000 mtu=1048 576 ) CR Warning(spire:19914): Couldn't find the CRMOTHERSHIP environment variable, de faulting to localhost CR Debug(spire:19914): In crNetConnectToServer( "localhost", port=10000, mtu=809 6, broker=0 ) CR Debug(spire:19914): Connecting to server spire.stanford.edu on port 10000, wi th protocol tcpip CR Debug(spire:19914): Done connecting to server localhost (swapping=0) CR Debug(spire:19914): Accepted connection from "spire". CR Debug(spire:19914): No tiling information for server! CR Info(spire:19914): Total output dimensions = (0, 0) CR Debug(spire:19914): Adding to the run queue: client=0x8290d18 number=0 count=1 CR Debug(spire:19914): Buffer pool 0x811d910 was empty; allocated new 1048596 byte buffer. Segmentation fault (core dumped) This visuals are now unhappy. I've tried setting several default visuals for the renderspu on the server side, but no luck just yet. I'll play this things a little bit more. -Mike Brian Paul wrote: > > Mike, on the readback SPU, try spu.Conf('use_glxchoosevisual', 0) > > This tells the Render SPU to not call glXChooseVisual. For some > reason, the call doesn't get resolved to the ATI libGL routine, but > instead, to the faker's glXChooseVisual. (Of course, this only > happens when the render/readback SPU is hosted by the app node.) > > I think the problem is ATI's libGL wasn't linked with the -Bsymbolic > option. But that doesn't explain why glXGetConfig works. Strange. > > The code path for use_glxchoosevisual = 0 was previously the default > in the Render SPU, but it was causing problems with the NVIDIA drivers > in particular configurations. So, the bug work-around is now chosen > with the config option. > > I hope that fixes things for you. > > -Brian > > > > > Mike Houston wrote: > >> This is on Linux, on ATI hardware with 3.14.6 as well as the newest >> release. When I get back in on Monday, I'll take a deeper look and >> send you the output. It is bailing out as soon as the default >> context is being created. It's trying for visual 0x27 (RGBA, double, >> Z) and can't get it. Sort-first apps work just fine as well as the >> sort last apps running locally. >> >> -Mike >> >> Brian Paul wrote: >> >>> Mike Houston wrote: >>> >>>> The changes to visbits seem to have broken all sort-last >>>> rendering. As a simple example, try readback.conf with atlantis or >>>> psubmit_last.conf. We seem to complain that we can't get the >>>> necessary visual for anything... Backing off to before the large >>>> stack of changes to the visbits gets everything working happy again. >>>> >>>> Can someone else please verify this behavior before we start trying >>>> to track this down? >>> >>> >>> >>> >>> >>> Hmmm. Both those demos work for me. And my recent visBits changes >>> have overall solved several problems for me, so they can't be >>> totally wrong. >>> >>> Could I see all the debug output from the app/server nodes? >>> >>> Is this on Linux or Windows? >>> >>> Which cards/drivers? >>> >>> -Brian >>> >>> PS: I found a one-line check-in mistake in renderspu_glx.c that'll >>> I'll fix, but it doesn't change anything here. >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>> Tool for open source databases. Create drag-&-drop reports. Save time >>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>> _______________________________________________ >>> Chromium-dev mailing list >>> Chr...@li... >>> https://lists.sourceforge.net/lists/listinfo/chromium-dev >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> Chromium-dev mailing list >> Chr...@li... >> https://lists.sourceforge.net/lists/listinfo/chromium-dev >> > |
|
From: Brian P. <bri...@tu...> - 2005-01-31 21:38:07
|
Mike Houston wrote: > That fixes readback.conf, but now crut programs are borked. For > example, crut_fan.conf. When crserver tries to bind to the crutserver > window, I now get this on the crserver side: > > CR Debug(spire:19914): Looking for the system's OpenGL library... > CR Debug(spire:19914): Found it in default path. > CR Debug(spire:19914): Render SPU: Creating default window > (visBits=0x25, id=0) > CR Debug(spire:19914): Render SPU: Opening display :0.0 > CR Debug(spire:19914): Render SPU: Looks like we have GLX > CR Debug(spire:19914): Render SPU: Chose visual id=0x29: RGBA=(8,8,8,8) > Z=24 ste ncil=0 double=1 stereo=0 accum=(0,0,0,0) > CR Debug(spire:19914): Render SPU: Created window 0x3600001 on display > :0.0, Xvi sual 0x29 > CR Debug(spire:19914): Render SPU: actual window x, y, width, height: > 500, 500, 400, 400 > CR Debug(spire:19914): Render SPU: WindowCreate returned 0 (0=normal) > CR Debug(spire:19914): Render SPU: Creating default context, visBits=0x25 > CR Debug(spire:19914): Render SPU: Created DIRECT context (0) on display > :0.0, X visual 0x29 > CR Warning(spire:19914): Couldn't find the CRMOTHERSHIP environment > variable, de faulting to localhost > CR Debug(spire:19914): In crNetConnectToServer( "localhost", port=10000, > mtu=809 6, broker=0 ) > CR Debug(spire:19914): Connecting to server spire.stanford.edu on port > 10000, wi th protocol tcpip > CR Debug(spire:19914): Done connecting to server localhost (swapping=0) > CR Debug(spire:19914): Render SPU: using CRUT drawable: 0x3200001 > CR Warning(spire:19914): Render SPU: Can't bind context 0 to CRUT/native > window 0x3200001 because of different X visuals (0x27 != 0x29)! This basically means that GLUT chose visual 0x27 for the window it created, given the flags passed to glutInitDisplayMode() while Chromium's render SPU choose visual 0x29 for its GLX rendering context, given the spu's default visual flags. The thing is, that's a recoverable situation. Note that this is happening when the default window/context is being created. Later, when crMakeCurrent() is called in psubmit_crut.c, the context should have a visual which matches the GLUT window. I think I may have something: look at psubmit_crut.c, line 92: static int visual = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT; But in crutserver/main.c line 316 we're asking for stencil: glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | GLUT_STENCIL); Could you try adding CR_STENCIL_BIT to the visual initialization? > CR Debug(spire:19914): Render SPU: GL_VENDOR: (null) > CR Debug(spire:19914): Render SPU: GL_RENDERER: (null) > CR Debug(spire:19914): Render SPU: GL_VERSION: (null) > CR Debug(spire:19914): Render SPU: ---------- End of Init ------------- > CR Debug(spire:19914): CRServer: my clients: 1 tcpip 2 > CR Debug(spire:19914): In crNetAcceptClient( protocol="tcpip" port=7000 > mtu=1048 576 ) > CR Warning(spire:19914): Couldn't find the CRMOTHERSHIP environment > variable, de faulting to localhost > CR Debug(spire:19914): In crNetConnectToServer( "localhost", port=10000, > mtu=809 6, broker=0 ) > CR Debug(spire:19914): Connecting to server spire.stanford.edu on port > 10000, wi th protocol tcpip > CR Debug(spire:19914): Done connecting to server localhost (swapping=0) > CR Debug(spire:19914): Accepted connection from "spire". > CR Debug(spire:19914): No tiling information for server! > CR Info(spire:19914): Total output dimensions = (0, 0) > CR Debug(spire:19914): Adding to the run queue: client=0x8290d18 > number=0 count=1 > CR Debug(spire:19914): Buffer pool 0x811d910 was empty; allocated new > 1048596 byte buffer. > Segmentation fault (core dumped) Can you determine where this crash is coming from? > This visuals are now unhappy. I've tried setting several default > visuals for the renderspu on the server side, but no luck just yet. > I'll play this things a little bit more. > > -Mike -Brian > Brian Paul wrote: > >> >> Mike, on the readback SPU, try spu.Conf('use_glxchoosevisual', 0) >> >> This tells the Render SPU to not call glXChooseVisual. For some >> reason, the call doesn't get resolved to the ATI libGL routine, but >> instead, to the faker's glXChooseVisual. (Of course, this only >> happens when the render/readback SPU is hosted by the app node.) >> >> I think the problem is ATI's libGL wasn't linked with the -Bsymbolic >> option. But that doesn't explain why glXGetConfig works. Strange. >> >> The code path for use_glxchoosevisual = 0 was previously the default >> in the Render SPU, but it was causing problems with the NVIDIA drivers >> in particular configurations. So, the bug work-around is now chosen >> with the config option. >> >> I hope that fixes things for you. >> >> -Brian >> >> >> >> >> Mike Houston wrote: >> >>> This is on Linux, on ATI hardware with 3.14.6 as well as the newest >>> release. When I get back in on Monday, I'll take a deeper look and >>> send you the output. It is bailing out as soon as the default >>> context is being created. It's trying for visual 0x27 (RGBA, double, >>> Z) and can't get it. Sort-first apps work just fine as well as the >>> sort last apps running locally. >>> >>> -Mike >>> >>> Brian Paul wrote: >>> >>>> Mike Houston wrote: >>>> >>>>> The changes to visbits seem to have broken all sort-last >>>>> rendering. As a simple example, try readback.conf with atlantis or >>>>> psubmit_last.conf. We seem to complain that we can't get the >>>>> necessary visual for anything... Backing off to before the large >>>>> stack of changes to the visbits gets everything working happy again. >>>>> >>>>> Can someone else please verify this behavior before we start trying >>>>> to track this down? >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hmmm. Both those demos work for me. And my recent visBits changes >>>> have overall solved several problems for me, so they can't be >>>> totally wrong. >>>> >>>> Could I see all the debug output from the app/server nodes? >>>> >>>> Is this on Linux or Windows? >>>> >>>> Which cards/drivers? >>>> >>>> -Brian >>>> >>>> PS: I found a one-line check-in mistake in renderspu_glx.c that'll >>>> I'll fix, but it doesn't change anything here. >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>>> Tool for open source databases. Create drag-&-drop reports. Save time >>>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>>> _______________________________________________ >>>> Chromium-dev mailing list >>>> Chr...@li... >>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>> Tool for open source databases. Create drag-&-drop reports. Save time >>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>> _______________________________________________ >>> Chromium-dev mailing list >>> Chr...@li... >>> https://lists.sourceforge.net/lists/listinfo/chromium-dev >>> >> > |
|
From: Mike H. <mho...@gr...> - 2005-01-31 22:27:39
|
Brian Paul wrote: > > This basically means that GLUT chose visual 0x27 for the window it > created, given the flags passed to glutInitDisplayMode() while > Chromium's render SPU choose visual 0x29 for its GLX rendering > context, given the spu's default visual flags. > > The thing is, that's a recoverable situation. Note that this is > happening when the default window/context is being created. Later, > when crMakeCurrent() is called in psubmit_crut.c, the context should > have a visual which matches the GLUT window. > > I think I may have something: look at psubmit_crut.c, line 92: > > static int visual = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT; > > But in crutserver/main.c line 316 we're asking for stencil: > > glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | > GLUT_STENCIL); > > > Could you try adding CR_STENCIL_BIT to the visual initialization? > > Still no love. The visuals still didn't change on the server side. The change to psubmit_crut modifies the application side's visbits, but the error I'm seeing is on the cr/crutserver side. > > >> CR Debug(spire:19914): Render SPU: GL_VENDOR: (null) >> CR Debug(spire:19914): Render SPU: GL_RENDERER: (null) >> CR Debug(spire:19914): Render SPU: GL_VERSION: (null) >> CR Debug(spire:19914): Render SPU: ---------- End of Init ------------- >> CR Debug(spire:19914): CRServer: my clients: 1 tcpip 2 >> CR Debug(spire:19914): In crNetAcceptClient( protocol="tcpip" >> port=7000 mtu=1048 576 ) >> CR Warning(spire:19914): Couldn't find the CRMOTHERSHIP environment >> variable, de faulting to localhost >> CR Debug(spire:19914): In crNetConnectToServer( "localhost", >> port=10000, mtu=809 6, broker=0 ) >> CR Debug(spire:19914): Connecting to server spire.stanford.edu on >> port 10000, wi th protocol tcpip >> CR Debug(spire:19914): Done connecting to server localhost (swapping=0) >> CR Debug(spire:19914): Accepted connection from "spire". >> CR Debug(spire:19914): No tiling information for server! >> CR Info(spire:19914): Total output dimensions = (0, 0) >> CR Debug(spire:19914): Adding to the run queue: client=0x8290d18 >> number=0 count=1 >> CR Debug(spire:19914): Buffer pool 0x811d910 was empty; allocated new >> 1048596 byte buffer. >> Segmentation fault (core dumped) > > > Can you determine where this crash is coming from? > There is a stack smash, so I'm not sure the trace is actually valid: #0 0x00000000 in ?? () #1 0x4300c6f3 in glBindBufferARB () from /usr/lib/libGL.so #2 0x0806585d in crStateBufferObjectSwitch (bb=0x80cfab0, bitID=0xaee7d00c, fromCtx=0xb7dfc008, toCtx=0xaee7d008) at state_bufferobject.c:702 #3 0x080a0643 in crStateSwitchContext (from=0xb7dfc008, to=0xaee7d008) at state_diff.c:162 #4 0x0807a2c9 in crStateMakeCurrent (ctx=0xaee7d008) at state_init.c:299 #5 0x08055948 in crServerSerializeRemoteStreams () at server_stream.c:307 #6 0x0804a3bb in CRServerMain (argc=1, argv=0xbfffd8c4) at server_main.c:223 #7 0x08049ee2 in main (argc=1, argv=0xbfffd8c4) at main.c:22 What's odd is that running with crutserver, when we can't bind the context, we get a completely bogus link into libgl, hence: CR Warning(spire:25274): Render SPU: Can't bind context 0 to CRUT/native window 0x3600001 because of different X visuals (0x27 != 0x29)! CR Debug(spire:25274): Render SPU: GL_VENDOR: (null) CR Debug(spire:25274): Render SPU: GL_RENDERER: (null) CR Debug(spire:25274): Render SPU: GL_VERSION: (null) CR Debug(spire:25274): Render SPU: ---------- End of Init ------------- I'll try setting a default visual for the renderspu that matches the crutserver init. -Mike |
|
From: Mike H. <mho...@gr...> - 2005-01-31 22:40:19
|
Okay, if I explicitly setup the default visuals everywhere to match the crutserver, I can get crut_fan.conf to work. After the changes to visbits and getting psubmit to create it's own window, we now get an app window and a render spu window. If I set render_to_app_window for the applications, everything gets routed to the crutwindow and I get trash rendered. What happens on Nvidia when running crut_fan? Things used to work perfectly before for me before the last round of changes. Now on ATI, I have to set use_glxchoosevisual to 0 (probably ATI's fault, but I'm not convinced just yet) and define the default visual for *every* render spu (or derived spu) to match the final render spu. There has to be a better way to handle this. We should be able to detect a difference in visuals and adapt... I'm just trying to get things running again so I can go back to the MPI layer next week. -Mike Mike Houston wrote: > > > Brian Paul wrote: > >> >> This basically means that GLUT chose visual 0x27 for the window it >> created, given the flags passed to glutInitDisplayMode() while >> Chromium's render SPU choose visual 0x29 for its GLX rendering >> context, given the spu's default visual flags. >> >> The thing is, that's a recoverable situation. Note that this is >> happening when the default window/context is being created. Later, >> when crMakeCurrent() is called in psubmit_crut.c, the context should >> have a visual which matches the GLUT window. >> >> I think I may have something: look at psubmit_crut.c, line 92: >> >> static int visual = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT; >> >> But in crutserver/main.c line 316 we're asking for stencil: >> >> glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | >> GLUT_STENCIL); >> >> >> Could you try adding CR_STENCIL_BIT to the visual initialization? >> >> > Still no love. The visuals still didn't change on the server side. > The change to psubmit_crut modifies the application side's visbits, > but the error I'm seeing is on the cr/crutserver side. > >> >> >>> CR Debug(spire:19914): Render SPU: GL_VENDOR: (null) >>> CR Debug(spire:19914): Render SPU: GL_RENDERER: (null) >>> CR Debug(spire:19914): Render SPU: GL_VERSION: (null) >>> CR Debug(spire:19914): Render SPU: ---------- End of Init ------------- >>> CR Debug(spire:19914): CRServer: my clients: 1 tcpip 2 >>> CR Debug(spire:19914): In crNetAcceptClient( protocol="tcpip" >>> port=7000 mtu=1048 576 ) >>> CR Warning(spire:19914): Couldn't find the CRMOTHERSHIP environment >>> variable, de faulting to localhost >>> CR Debug(spire:19914): In crNetConnectToServer( "localhost", >>> port=10000, mtu=809 6, broker=0 ) >>> CR Debug(spire:19914): Connecting to server spire.stanford.edu on >>> port 10000, wi th protocol tcpip >>> CR Debug(spire:19914): Done connecting to server localhost (swapping=0) >>> CR Debug(spire:19914): Accepted connection from "spire". >>> CR Debug(spire:19914): No tiling information for server! >>> CR Info(spire:19914): Total output dimensions = (0, 0) >>> CR Debug(spire:19914): Adding to the run queue: client=0x8290d18 >>> number=0 count=1 >>> CR Debug(spire:19914): Buffer pool 0x811d910 was empty; allocated >>> new 1048596 byte buffer. >>> Segmentation fault (core dumped) >> >> >> >> Can you determine where this crash is coming from? >> > There is a stack smash, so I'm not sure the trace is actually valid: > > #0 0x00000000 in ?? () > #1 0x4300c6f3 in glBindBufferARB () from /usr/lib/libGL.so > #2 0x0806585d in crStateBufferObjectSwitch (bb=0x80cfab0, > bitID=0xaee7d00c, > fromCtx=0xb7dfc008, toCtx=0xaee7d008) at state_bufferobject.c:702 > #3 0x080a0643 in crStateSwitchContext (from=0xb7dfc008, to=0xaee7d008) > at state_diff.c:162 > #4 0x0807a2c9 in crStateMakeCurrent (ctx=0xaee7d008) at state_init.c:299 > #5 0x08055948 in crServerSerializeRemoteStreams () at > server_stream.c:307 > #6 0x0804a3bb in CRServerMain (argc=1, argv=0xbfffd8c4) at > server_main.c:223 > #7 0x08049ee2 in main (argc=1, argv=0xbfffd8c4) at main.c:22 > > What's odd is that running with crutserver, when we can't bind the > context, we get a completely bogus link into libgl, hence: > > CR Warning(spire:25274): Render SPU: Can't bind context 0 to > CRUT/native window 0x3600001 because of different X visuals (0x27 != > 0x29)! > CR Debug(spire:25274): Render SPU: GL_VENDOR: (null) > CR Debug(spire:25274): Render SPU: GL_RENDERER: (null) > CR Debug(spire:25274): Render SPU: GL_VERSION: (null) > CR Debug(spire:25274): Render SPU: ---------- End of Init ------------- > > I'll try setting a default visual for the renderspu that matches the > crutserver init. > > -Mike > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev |
|
From: Brian P. <bri...@tu...> - 2005-01-31 23:12:12
Attachments:
glx.patch
|
Mike Houston wrote: > Okay, if I explicitly setup the default visuals everywhere to match the > crutserver, I can get crut_fan.conf to work. After the changes to > visbits and getting psubmit to create it's own window, we now get an app > window and a render spu window. If I set render_to_app_window for the > applications, everything gets routed to the crutwindow and I get trash > rendered. I'm not sure I understand. Could I see your .conf file? > What happens on Nvidia when running crut_fan? It just works. > Things used to work > perfectly before for me before the last round of changes. Now on ATI, I > have to set use_glxchoosevisual to 0 (probably ATI's fault, but I'm not > convinced just yet) and define the default visual for *every* render spu > (or derived spu) to match the final render spu. There has to be a > better way to handle this. We should be able to detect a difference in > visuals and adapt... Perhaps we should try to recreate the GLX context with a new visual if the initial context's visual doesn't match the CRUT window's visual. I think that might work. I'll look into it. > I'm just trying to get things running again so I > can go back to the MPI layer next week. Try the attached patch to renderspu_glx.c. It might fix the segfault that happens after trying to issue GL commands after a failed MakeCurrent. Though, OpenGL should not crash if there's no current context. -Brian > -Mike > > Mike Houston wrote: > >> >> >> Brian Paul wrote: >> >>> >>> This basically means that GLUT chose visual 0x27 for the window it >>> created, given the flags passed to glutInitDisplayMode() while >>> Chromium's render SPU choose visual 0x29 for its GLX rendering >>> context, given the spu's default visual flags. >>> >>> The thing is, that's a recoverable situation. Note that this is >>> happening when the default window/context is being created. Later, >>> when crMakeCurrent() is called in psubmit_crut.c, the context should >>> have a visual which matches the GLUT window. >>> >>> I think I may have something: look at psubmit_crut.c, line 92: >>> >>> static int visual = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT; >>> >>> But in crutserver/main.c line 316 we're asking for stencil: >>> >>> glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | >>> GLUT_STENCIL); >>> >>> >>> Could you try adding CR_STENCIL_BIT to the visual initialization? >>> >>> >> Still no love. The visuals still didn't change on the server side. >> The change to psubmit_crut modifies the application side's visbits, >> but the error I'm seeing is on the cr/crutserver side. >> >>> >>> >>>> CR Debug(spire:19914): Render SPU: GL_VENDOR: (null) >>>> CR Debug(spire:19914): Render SPU: GL_RENDERER: (null) >>>> CR Debug(spire:19914): Render SPU: GL_VERSION: (null) >>>> CR Debug(spire:19914): Render SPU: ---------- End of Init ------------- >>>> CR Debug(spire:19914): CRServer: my clients: 1 tcpip 2 >>>> CR Debug(spire:19914): In crNetAcceptClient( protocol="tcpip" >>>> port=7000 mtu=1048 576 ) >>>> CR Warning(spire:19914): Couldn't find the CRMOTHERSHIP environment >>>> variable, de faulting to localhost >>>> CR Debug(spire:19914): In crNetConnectToServer( "localhost", >>>> port=10000, mtu=809 6, broker=0 ) >>>> CR Debug(spire:19914): Connecting to server spire.stanford.edu on >>>> port 10000, wi th protocol tcpip >>>> CR Debug(spire:19914): Done connecting to server localhost (swapping=0) >>>> CR Debug(spire:19914): Accepted connection from "spire". >>>> CR Debug(spire:19914): No tiling information for server! >>>> CR Info(spire:19914): Total output dimensions = (0, 0) >>>> CR Debug(spire:19914): Adding to the run queue: client=0x8290d18 >>>> number=0 count=1 >>>> CR Debug(spire:19914): Buffer pool 0x811d910 was empty; allocated >>>> new 1048596 byte buffer. >>>> Segmentation fault (core dumped) >>> >>> >>> >>> >>> Can you determine where this crash is coming from? >>> >> There is a stack smash, so I'm not sure the trace is actually valid: >> >> #0 0x00000000 in ?? () >> #1 0x4300c6f3 in glBindBufferARB () from /usr/lib/libGL.so >> #2 0x0806585d in crStateBufferObjectSwitch (bb=0x80cfab0, >> bitID=0xaee7d00c, >> fromCtx=0xb7dfc008, toCtx=0xaee7d008) at state_bufferobject.c:702 >> #3 0x080a0643 in crStateSwitchContext (from=0xb7dfc008, to=0xaee7d008) >> at state_diff.c:162 >> #4 0x0807a2c9 in crStateMakeCurrent (ctx=0xaee7d008) at state_init.c:299 >> #5 0x08055948 in crServerSerializeRemoteStreams () at >> server_stream.c:307 >> #6 0x0804a3bb in CRServerMain (argc=1, argv=0xbfffd8c4) at >> server_main.c:223 >> #7 0x08049ee2 in main (argc=1, argv=0xbfffd8c4) at main.c:22 >> >> What's odd is that running with crutserver, when we can't bind the >> context, we get a completely bogus link into libgl, hence: >> >> CR Warning(spire:25274): Render SPU: Can't bind context 0 to >> CRUT/native window 0x3600001 because of different X visuals (0x27 != >> 0x29)! >> CR Debug(spire:25274): Render SPU: GL_VENDOR: (null) >> CR Debug(spire:25274): Render SPU: GL_RENDERER: (null) >> CR Debug(spire:25274): Render SPU: GL_VERSION: (null) >> CR Debug(spire:25274): Render SPU: ---------- End of Init ------------- >> >> I'll try setting a default visual for the renderspu that matches the >> crutserver init. >> >> -Mike >> |
|
From: Brian P. <bri...@tu...> - 2005-01-31 23:25:46
Attachments:
glx2.patch
|
Brian Paul wrote: > Mike Houston wrote: > Perhaps we should try to recreate the GLX context with a new visual if > the initial context's visual doesn't match the CRUT window's visual. I > think that might work. I'll look into it. OK, here's a patch to do that. Apply after the previous patch. -Brian |
|
From: Mike H. <mho...@gr...> - 2005-01-31 23:45:57
|
Brian Paul wrote:
> Mike Houston wrote:
>
>> Okay, if I explicitly setup the default visuals everywhere to match
>> the crutserver, I can get crut_fan.conf to work. After the changes
>> to visbits and getting psubmit to create it's own window, we now get
>> an app window and a render spu window. If I set render_to_app_window
>> for the applications, everything gets routed to the crutwindow and I
>> get trash rendered.
>
>
> I'm not sure I understand. Could I see your .conf file?
import sys
sys.path.append( "../server" )
from mothership import *
Demo = 'psubmit_crut'
Demo = os.path.join(crbindir, Demo)
# Can render/readback windows by dynamically resized?
resizable = '1'
# Set up the server node
servernode1 = CRNetworkNode( )
# Note: each client has the -swap flag and we tell the server to only
# do one SwapBuffers here.
servernode1.Conf( 'only_swap_once', 1 )
servernode1.Conf( 'shared_windows', 1 )
renderspu = SPU( 'render' )
renderspu.Conf( 'window_geometry', [500, 500, 400, 400] )
renderspu.Conf('resizable', resizable)
renderspu.Conf('render_to_app_window', 1 )
renderspu.Conf('render_to_crut_window', 1 )
renderspu.Conf('default_visual', 'rgb, double, depth, stencil')
# only specifying visual to work-around ATI FireGL problem
servernode1.AddSPU( renderspu )
#create a crutserver
crutserver = CRUTServerNode( )
crutserver.Conf('window_geometry', [100, 100, 400, 400] )
# Set up first app/client node
appnode1 = CRApplicationNode( )
appnode1.SetApplication( '%s -rank 0 -size 2 -clear -swap' % Demo )
appnode1.StartDir( crbindir )
spu = SPU('readback')
spu.Conf('window_geometry', [0, 0, 400, 400])
spu.Conf('use_glxchoosevisual', 0)
spu.Conf('extract_depth', '1')
spu.Conf('resizable', resizable)
spu.Conf('render_to_app_window', 1)
spu.Conf('default_visual', 'rgb, double, depth, stencil')
appnode1.AddSPU( spu )
spu = SPU('pack')
appnode1.AddSPU( spu )
spu.AddServer( servernode1, 'tcpip' )
#let's define a CRUTserver as anything that will feed us events
#this way we can create either a ring or a fan configuration
appnode1.AddCRUTServer( crutserver , protocol='tcpip', port=9000 )
# Set up second app/client node
appnode2 = CRApplicationNode( )
appnode2.SetApplication( '%s -rank 1 -size 2 -clear -swap' % Demo )
appnode2.StartDir( crbindir )
spu = SPU('readback')
spu.Conf('window_geometry', [420, 0, 400, 400])
spu.Conf('use_glxchoosevisual', 0)
spu.Conf('extract_depth', '1')
spu.Conf('resizable', resizable)
spu.Conf('default_visual', 'rgb, double, depth, stencil')
spu.Conf( 'render_to_app_window', 1 )
appnode2.AddSPU( spu )
spu = SPU('pack')
appnode2.AddSPU( spu )
spu.AddServer( servernode1, 'tcpip' )
appnode2.AddCRUTServer( crutserver, protocol='tcpip', port=9000 )
cr = CR()
cr.MTU( 10*1024*1024 )
# Note: adding nodes in the order in which they must be started!
cr.AddNode( appnode1 )
cr.AddNode( appnode2 )
cr.AddNode( crutserver )
cr.AddNode( servernode1 )
cr.Go()
|
×
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