chromium-users — Mailing list for all users of the Chromuim rendering system

Re: [Chromium-users] Windows: Modifying app_faker.c to handle .manifests and private dlls

[Thomas C. <tho...@gm...>]

Our practice is to copy the crfaker.dll into the application directory and
rename it to opengl32.dll. Thus we didn't had to modify our application.
I am not sure it is a clean way but it works fine!

Regards,
Thomas


2008/4/25, David L. Page <pa...@gm...>:
>
> Yes, I believe this snippet might be what you are refering to. The
> documentation has the following note:
>
> *Windows*: You will also need to install the cygwin tools<http://cygwin.com/>to build Chromium. If you're building from the Windows shell (as opposed to
> the cygwin bash implementation), you will need to set the environment
> variable MAKE_MODE to the string "unix". This lets gmake use bash as its
> subshell instead of the Windows shell, which is required. Shared libraries
> on Windows get put in cr-X.Y/bin/WIN_NT, which (since it's on your path,
> right?) will be searched automatically, so there's no LD_LIBRARY_PATHsilliness.
>
> However, if I load an app.exe with crappfaker.exe and the dir where the
> app.exe is located is not in my path, then the dlls are not found. More
> specifically, the app.exe.manifest file is not properly located. It's my
> understanding (I maybe wrong) that app.exe.manifest needs to be in the same
> directory where app.exe is spawned. The kludge that I have put together in
> app_faker.c moves not only app.exe to the tmp directory but additionally
> moves app.exe.manifest. This solution seems to do the trick.
>
> Is it a bad idea to copy not only app.exe but also app.exe.manifest (and
> perhaps private dlls) to the tmp directory
>
> --Dave
>
>
>
>
> On Fri, Apr 25, 2008 at 3:59 PM, Greg Humphreys <hu...@gm...> wrote:
>
>>  You can specify that the app faker start in another directory, so the
>> app can find private dlls, data files,  and the like.
>>
>> I done remember the exact command, but surely it is documented :)
>>
>> -- Greg
>>
>> On Apr 25, 2008, at 3:49 PM, "David L. Page" <pa...@gm...> wrote:
>>
>>
>> I'm not really a developer, but this post should probably go there.
>>
>> In regards to a previous post, I noted that Windows manifest files were
>> causing problems on my system for executing the OpenGL demos, specially
>> atlantis.exe.
>>
>> I previously posted a kludge to embed the manifests in the exe files, but
>> this approach would seem to go against the Chromium philosophy of not
>> requiring mods to an existing OpenGL app.
>>
>> So, I dug into it a bit more and the problem seems to occur from the fact
>> that crappfaker.exe copies atlantis.exe (for example) to a temporary
>> directory and then copies crfaker.dll to that same tmp directory with the
>> name opengl32.dll. In this manner, atlantis.exe (or whatever app) is fooled
>> into thinking that crfaker.dll is the OpenGL library.
>>
>> BUT! The big problem here is that that file atlantis.exe.manifest doesn't
>> get copied by crappfaker.exe, and thus Windows is unable to load the
>> msvcr80d.dll.
>>
>> I am speculating, but I think this particular behavior would also cause
>> problems for private dlls as well where a private dll is one that is located
>> in the directory where an app exe is located AND that directory is not in
>> the load path of Windows. So, a private dll would also not be copied to the
>> tmp directory and thus would not be linked. A similar issue would seem to
>> arise with .local files (i.e. app.exe.local). I don't have a good
>> understanding of these, but I think they also would need to be copied to the
>> tmp directory.
>>
>> That's what I've figured out so far. I have a modified version of
>> app_faker.c working on my system. This mod avoids the need for mt.exe
>> embedding of manifests into an app exe, i.e. no need to modify an OpenGL
>> app.
>>
>> My coding practice is very much a hack job. Is there a developer out there
>> that might have an interest is cleaning my mess up and including it in the
>> development of Chromium?
>>
>> --Dave
>>
>>
>> --
>> David L. Page, PhD
>> <dav...@ie...>dav...@ie...
>> 865.607.8192
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save $100.
>> Use priority code J8TL2D2.
>>
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>
>>  _______________________________________________
>> Chromium-users mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-users
>>
>>
>
>
> --
> David L. Page, PhD
> dav...@ie...
> 865.607.8192
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users
>
>

Re: [Chromium-users] Windows: Modifying app_faker.c to handle .manifests and private dlls

[David L. P. <pa...@gm...>]

Yes, I believe this snippet might be what you are refering to. The
documentation has the following note:

*Windows*: You will also need to install the cygwin
tools<http://cygwin.com/>to build Chromium. If you're building from
the Windows shell (as opposed to
the cygwin bash implementation), you will need to set the environment
variable MAKE_MODE to the string "unix". This lets gmake use bash as its
subshell instead of the Windows shell, which is required. Shared libraries
on Windows get put in cr-X.Y/bin/WIN_NT, which (since it's on your path,
right?) will be searched automatically, so there's no LD_LIBRARY_PATHsilliness.

However, if I load an app.exe with crappfaker.exe and the dir where the
app.exe is located is not in my path, then the dlls are not found. More
specifically, the app.exe.manifest file is not properly located. It's my
understanding (I maybe wrong) that app.exe.manifest needs to be in the same
directory where app.exe is spawned. The kludge that I have put together in
app_faker.c moves not only app.exe to the tmp directory but additionally
moves app.exe.manifest. This solution seems to do the trick.

Is it a bad idea to copy not only app.exe but also app.exe.manifest (and
perhaps private dlls) to the tmp directory

--Dave




On Fri, Apr 25, 2008 at 3:59 PM, Greg Humphreys <hu...@gm...> wrote:

>  You can specify that the app faker start in another directory, so the app
> can find private dlls, data files,  and the like.
>
> I done remember the exact command, but surely it is documented :)
>
> -- Greg
>
> On Apr 25, 2008, at 3:49 PM, "David L. Page" <pa...@gm...> wrote:
>
>
> I'm not really a developer, but this post should probably go there.
>
> In regards to a previous post, I noted that Windows manifest files were
> causing problems on my system for executing the OpenGL demos, specially
> atlantis.exe.
>
> I previously posted a kludge to embed the manifests in the exe files, but
> this approach would seem to go against the Chromium philosophy of not
> requiring mods to an existing OpenGL app.
>
> So, I dug into it a bit more and the problem seems to occur from the fact
> that crappfaker.exe copies atlantis.exe (for example) to a temporary
> directory and then copies crfaker.dll to that same tmp directory with the
> name opengl32.dll. In this manner, atlantis.exe (or whatever app) is fooled
> into thinking that crfaker.dll is the OpenGL library.
>
> BUT! The big problem here is that that file atlantis.exe.manifest doesn't
> get copied by crappfaker.exe, and thus Windows is unable to load the
> msvcr80d.dll.
>
> I am speculating, but I think this particular behavior would also cause
> problems for private dlls as well where a private dll is one that is located
> in the directory where an app exe is located AND that directory is not in
> the load path of Windows. So, a private dll would also not be copied to the
> tmp directory and thus would not be linked. A similar issue would seem to
> arise with .local files (i.e. app.exe.local). I don't have a good
> understanding of these, but I think they also would need to be copied to the
> tmp directory.
>
> That's what I've figured out so far. I have a modified version of
> app_faker.c working on my system. This mod avoids the need for mt.exe
> embedding of manifests into an app exe, i.e. no need to modify an OpenGL
> app.
>
> My coding practice is very much a hack job. Is there a developer out there
> that might have an interest is cleaning my mess up and including it in the
> development of Chromium?
>
> --Dave
>
>
> --
> David L. Page, PhD
> dav...@ie...
> 865.607.8192
>
>  -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>
>  _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users
>
>


-- 
David L. Page, PhD
dav...@ie...
865.607.8192

[Chromium-users] Windows: Modifying app_faker.c to handle .manifests and private dlls

[David L. P. <pa...@gm...>]

I'm not really a developer, but this post should probably go there.

In regards to a previous post, I noted that Windows manifest files were
causing problems on my system for executing the OpenGL demos, specially
atlantis.exe.

I previously posted a kludge to embed the manifests in the exe files, but
this approach would seem to go against the Chromium philosophy of not
requiring mods to an existing OpenGL app.

So, I dug into it a bit more and the problem seems to occur from the fact
that crappfaker.exe copies atlantis.exe (for example) to a temporary
directory and then copies crfaker.dll to that same tmp directory with the
name opengl32.dll. In this manner, atlantis.exe (or whatever app) is fooled
into thinking that crfaker.dll is the OpenGL library.

BUT! The big problem here is that that file atlantis.exe.manifest doesn't
get copied by crappfaker.exe, and thus Windows is unable to load the
msvcr80d.dll.

I am speculating, but I think this particular behavior would also cause
problems for private dlls as well where a private dll is one that is located
in the directory where an app exe is located AND that directory is not in
the load path of Windows. So, a private dll would also not be copied to the
tmp directory and thus would not be linked. A similar issue would seem to
arise with .local files (i.e. app.exe.local). I don't have a good
understanding of these, but I think they also would need to be copied to the
tmp directory.

That's what I've figured out so far. I have a modified version of
app_faker.c working on my system. This mod avoids the need for mt.exe
embedding of manifests into an app exe, i.e. no need to modify an OpenGL
app.

My coding practice is very much a hack job. Is there a developer out there
that might have an interest is cleaning my mess up and including it in the
development of Chromium?

--Dave


-- 
David L. Page, PhD
dav...@ie...
865.607.8192

Re: [Chromium-users] Solution: Chromium on Windows: MSVCR80D.dll file not found

[Brian P. <bri...@tu...>]

David L. Page wrote:
> 
> I have finally solved the issue with using Chromium on MSVC8 (at least 
> with my platform). The main problem seems to be with manifests and dlls. 
> I am not fully familiar with Microsoft manifests, but it seems that when 
> the app faker trys to spawn a process, not all dlls are found (i.e. 
> atlantis.exe is unable to link with MSVCR80D.dll).
>  
> The solution that I have found to work is to embedded the manifest 
> information into the atlantis.exe (or any opengl app that app faker 
> spawns). Here's the DOS command line that I used for atlantis.exe.
>  
> C:\cr-1.0\bin\WIN_NT>mt.exe -manifest atlantis.exe.manifest 
> -outputresource:atlantis.exe;1
>  
> The following MSDN link is probably more useful:
>  
> http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx
>  
> I'm not sure how to force embedding manifests during compile/link, but 
> it would seem to be the obvious next step.

If you could boil this info down into some patches for the Chromium 
docs, I'll commit them to CVS.

-Brian

[Chromium-users] Solution: Chromium on Windows: MSVCR80D.dll file not found

[David L. P. <pa...@gm...>]

I have finally solved the issue with using Chromium on MSVC8 (at least with
my platform). The main problem seems to be with manifests and dlls. I am not
fully familiar with Microsoft manifests, but it seems that when the app
faker trys to spawn a process, not all dlls are found (i.e. atlantis.exe is
unable to link with MSVCR80D.dll).

The solution that I have found to work is to embedded the manifest
information into the atlantis.exe (or any opengl app that app faker spawns).
Here's the DOS command line that I used for atlantis.exe.

C:\cr-1.0\bin\WIN_NT>mt.exe -manifest atlantis.exe.manifest
-outputresource:atlantis.exe;1

The following MSDN link is probably more useful:

http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx

I'm not sure how to force embedding manifests during compile/link, but it
would seem to be the obvious next step.

--Dave


-- 
David L. Page
dav...@ie...
865.607.8192

[Chromium-users] Chromium on Windows: MSVCR80D.dll file not found

[David L. P. <pa...@gm...>]

I am slowly narrowing down the issues on getting CR running on my Windows
machine.

I have now narrowed the problem down to not finding a dll file
(MSVCR80D.dll). It seems that when I just run atlantis.exe at the command
prompt, everything is kosher. Likewise, with crserver.exe and
crappfaker.exer.

However, when altantis.exe is kicked off via Chromium, it seems to have
trouble finding the dll, MSVCR80D.dll). After reading through several MSVC
newsgroups, it seems that manifest files and MSVCR80D.dll are an issue that
one has to be careful with in MSVC8.

I haven't been able to resolve this issue. Does anyone have a suggestion?

I am thinking about going back to an old compiler, perhaps 7 or even 6. Any
recommendations as to which compiler might be most suitable with Chromium?

Best regards,

--Dave

-- 
David L. Page
dav...@ie...
865.607.8192

[Chromium-users] New User: Chromium on Windows (next problem, no blank or fish window)

[David L. P. <pa...@gm...>]

I am a new user to Chromium and I have corrected the problem from my
previous post to this newsgroup by following the FAQ. My apologies for not
reading it closer.

I am following the "Chromium for beginners" part of the documentation with
regard to Windows based system. I am now able to successfully run the
initial demo except that the windows do not open. Here's the sequence of
steps suggested in the documentation:

>> 1: % cd mothership/configs
>> 2: % python crdemo.conf atlantis &
>> 3: % crserver &
>> 4: % crappfaker

>> You should get two windows, one blank, one with fish. Congratulations,
you've run your first Chromium network! Everything else is downhill from
here.

Unfortunately, I am unable to get the two windows. To test the OpenGL side
of things, I am able to run 'atlantis' within the cygwin bash shell. It does
open a window and redner the atlantis scene.

I have turned on all the debug options that I can find (RELEASE=0 during
compile, DebugLevel = 2 in mothership.py) and here's the result below.

==== BEGIN ====

Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ python crdemo.conf atlantis &
[1] 5856
Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ This is Chromium, Version 1.9
Start a crappfaker on Old_Laphroaig.x.x.net
Start a crserver on Old_Laphroaig.x.x.net

Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ crserver &
[2] 3428
Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ CR Warning(Old_Laphroaig:0): crGetPID not implemented on Windows yet!
CR Warning(Old_Laphroaig:0): Couldn't find the CRMOTHERSHIP environment
variable, defaulting to localhost
CR Debug(Old_Laphroaig:0): In crNetConnectToServer( "localhost", port=10000,
mtu=8096, broker=0 )
CR Debug(Old_Laphroaig:0): Connecting to Old_Laphroaig on port 10000, with
protocol tcpip
CR Debug(Old_Laphroaig:0): Done connecting to localhost (swapping=0)
Processing mothership request: "server Old_Laphroaig"
Replying (200): "1 0 render"
CR Debug(Old_Laphroaig:0): CRServer: my SPU chain: 1 0 render
CR Debug(Old_Laphroaig:0): SPU 1/1: (0) "render"
Processing mothership request: "serverparam spu_dir"
Replying (404): "Server doesn't have param spu_dir"
Processing mothership request: "rank"
Replying (404): "Node didn't say what it's rank is."
Processing mothership request: "getparam low_context"
Replying (200): "32"
Processing mothership request: "getparam high_context"
Replying (200): "35"
Processing mothership request: "getparam low_node"
Replying (200): "iam0"
Processing mothership request: "getparam high_node"
Replying (200): "iamvis20"
Processing mothership request: "getparam comm_key"
Replying (200): "[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]"
Processing mothership request: "serverparam port"
Replying (200): "7000"
Processing mothership request: "serverparam optimize_bucket"
Replying (404): "Server doesn't have param optimize_bucket"
Processing mothership request: "serverparam local_tile_spec"
Replying (404): "Server doesn't have param local_tile_spec"
Processing mothership request: "serverparam lightning2"
Replying (404): "Server doesn't have param lightning2"
Processing mothership request: "serverparam ignore_papi"
Replying (404): "Server doesn't have param ignore_papi"
Processing mothership request: "serverparam overlap_blending"
Replying (404): "Server doesn't have param overlap_blending"
Processing mothership request: "serverparam overlap_levels"
Replying (404): "Server doesn't have param overlap_levels"
Processing mothership request: "serverparam only_swap_once"
Replying (404): "Server doesn't have param only_swap_once"
Processing mothership request: "serverparam debug_barriers"
Replying (404): "Server doesn't have param debug_barriers"
Processing mothership request: "serverparam shared_display_lists"
Replying (404): "Server doesn't have param shared_display_lists"
Processing mothership request: "serverparam shared_texture_objects"
Replying (404): "Server doesn't have param shared_texture_objects"
Processing mothership request: "serverparam shared_programs"
Replying (404): "Server doesn't have param shared_programs"
Processing mothership request: "serverparam shared_windows"
Replying (404): "Server doesn't have param shared_windows"
Processing mothership request: "serverparam unique_window_ids"
Replying (404): "Server doesn't have param unique_window_ids"
Processing mothership request: "serverparam use_dmx"
Replying (404): "Server doesn't have param use_dmx"
Processing mothership request: "serverparam vertprog_projection_param"
Replying (404): "Server doesn't have param vertprog_projection_param"
Processing mothership request: "serverparam stereo_view"
Replying (404): "Server doesn't have param stereo_view"
Processing mothership request: "serverparam view_matrix"
Replying (404): "Server doesn't have param view_matrix"
Processing mothership request: "serverparam right_view_matrix"
Replying (404): "Server doesn't have param right_view_matrix"
Processing mothership request: "serverparam projection_matrix"
Replying (404): "Server doesn't have param projection_matrix"
Processing mothership request: "serverparam right_projection_matrix"
Replying (404): "Server doesn't have param right_projection_matrix"
CR Debug(Old_Laphroaig:0): CRServer: my port number is 7000
CR Debug(Old_Laphroaig:0): Initializing error SPU
CR Debug(Old_Laphroaig:0): Initializing render SPU
CR Warning(Old_Laphroaig:0): Couldn't find the CRMOTHERSHIP environment
variable, defaulting to localhost
CR Debug(Old_Laphroaig:0): In crNetConnectToServer( "localhost", port=10000,
mtu=8096, broker=0 )
CR Debug(Old_Laphroaig:0): Connecting to Old_Laphroaig on port 10000, with
protocol tcpip
CR Debug(Old_Laphroaig:0): Done connecting to localhost (swapping=0)
Processing mothership request: "spu 0"
Replying (200): "Hello, render SPU!"
Processing mothership request: "spuparam title"
Replying (404): "SPU 0 (render) doesn't have param title"
Processing mothership request: "spuparam window_geometry"
responding with args = [100, 100, 500, 500]
Replying (200): "[100, 100, 500, 500]"
Processing mothership request: "spuparam fullscreen"
Replying (404): "SPU 0 (render) doesn't have param fullscreen"
Processing mothership request: "spuparam resizable"
Replying (404): "SPU 0 (render) doesn't have param resizable"
Processing mothership request: "spuparam on_top"
Replying (404): "SPU 0 (render) doesn't have param on_top"
Processing mothership request: "spuparam borderless"
Replying (404): "SPU 0 (render) doesn't have param borderless"
Processing mothership request: "spuparam default_visual"
Replying (404): "SPU 0 (render) doesn't have param default_visual"
Processing mothership request: "spuparam render_to_app_window"
Replying (404): "SPU 0 (render) doesn't have param render_to_app_window"
Processing mothership request: "spuparam render_to_crut_window"
Replying (404): "SPU 0 (render) doesn't have param render_to_crut_window"
Processing mothership request: "spuparam show_cursor"
Replying (404): "SPU 0 (render) doesn't have param show_cursor"
Processing mothership request: "spuparam system_gl_path"
Replying (404): "SPU 0 (render) doesn't have param system_gl_path"
Processing mothership request: "spuparam display_string"
Replying (404): "SPU 0 (render) doesn't have param display_string"
Processing mothership request: "spuparam gather_url"
Replying (404): "SPU 0 (render) doesn't have param gather_url"
Processing mothership request: "spuparam gather_userbuf_size"
Replying (404): "SPU 0 (render) doesn't have param gather_userbuf_size"
Processing mothership request: "spuparam lut8"
Replying (404): "SPU 0 (render) doesn't have param lut8"
Processing mothership request: "spuparam swap_master_url"
responding with args = ''
Replying (200): ""
Processing mothership request: "spuparam is_swap_master"
Replying (404): "SPU 0 (render) doesn't have param is_swap_master"
Processing mothership request: "spuparam num_swap_clients"
Replying (404): "SPU 0 (render) doesn't have param num_swap_clients"
Processing mothership request: "spuparam use_osmesa"
Replying (404): "SPU 0 (render) doesn't have param use_osmesa"
Processing mothership request: "spuparam nv_swap_group"
Replying (404): "SPU 0 (render) doesn't have param nv_swap_group"
Processing mothership request: "spuparam ignore_papi"
Replying (404): "SPU 0 (render) doesn't have param ignore_papi"
Processing mothership request: "spuparam ignore_window_moves"
Replying (404): "SPU 0 (render) doesn't have param ignore_window_moves"
Processing mothership request: "spuparam pbuffer_size"
Replying (404): "SPU 0 (render) doesn't have param pbuffer_size"
Processing mothership request: "spuparam use_glxchoosevisual"
Replying (404): "SPU 0 (render) doesn't have param use_glxchoosevisual"
Processing mothership request: "spuparam draw_bbox"
Replying (404): "SPU 0 (render) doesn't have param draw_bbox"
Processing mothership request: "getparam MTU"
Replying (200): "1048576"
Processing mothership request: "disconnect"
Replying (200): "Bye"
CR Debug(Old_Laphroaig:0): Looking for the system's OpenGL library...
CR Debug(Old_Laphroaig:0): Found it in default path.
CR Debug(Old_Laphroaig:0): Render SPU: Creating default window
(visBits=0x25, id=0)
CR Debug(Old_Laphroaig:0): Render SPU: Got the module handle: 0x400000
CR Debug(Old_Laphroaig:0): Render SPU: Got the desktop: 0x768
CR Debug(Old_Laphroaig:0): Render SPU: Set the thread desktop -- this might
have failed.
CR Debug(Old_Laphroaig:0): Render SPU: Registered the class
CR Debug(Old_Laphroaig:0): Render SPU: Got the class information
CR Debug(Old_Laphroaig:0): Render SPU: Fullscreen: no
CR Debug(Old_Laphroaig:0): Render SPU: Got the X fixed frame
CR Debug(Old_Laphroaig:0): Render SPU: Got the Y fixed frame
CR Debug(Old_Laphroaig:0): Render SPU: Got the Caption
CR Debug(Old_Laphroaig:0): Render SPU: Creating the window: (100,100),
(506,532)
CR Debug(Old_Laphroaig:0): Render SPU: Got the DC: 0xf60114d7
CR Warning(Old_Laphroaig:0): Render SPU: WGL wants these visual
capabilities: RGB, Doublebuffer, Z
CR Warning(Old_Laphroaig:0): Render SPU: WGL chose these visual
capabilities: RGB, Doublebuffer, Z, Accum
CR Debug(Old_Laphroaig:0): Render SPU: WindowCreate returned 0 (0=normal)
CR Debug(Old_Laphroaig:0): Render SPU: Creating default context,
visBits=0x25
CR Debug(Old_Laphroaig:0): Render SPU: Using the DC: 0xf60114d7
CR Debug(Old_Laphroaig:0): Render SPU: GL_VENDOR:   NVIDIA Corporation
CR Debug(Old_Laphroaig:0): Render SPU: GL_RENDERER: GeForce 8800 GT/PCI/SSE2
CR Debug(Old_Laphroaig:0): Render SPU: GL_VERSION:  2.1.2
CR Debug(Old_Laphroaig:0): WGL - found wglGetExtensionsStringEXT
CR Debug(Old_Laphroaig:0): WGL - found wglChoosePixelFormatEXT
CR Debug(Old_Laphroaig:0): Render SPU: ---------- End of Init -------------
Processing mothership request: "getparam MTU"
Replying (200): "1048576"
Processing mothership request: "clients"
Replying (200): "1 tcpip 1"
CR Debug(Old_Laphroaig:0): CRServer: my clients: 1 tcpip 1
CR Debug(Old_Laphroaig:0): In crNetAcceptClient( protocol="tcpip" port=7000
mtu=1048576 )
CR Warning(Old_Laphroaig:0): Couldn't find the CRMOTHERSHIP environment
variable, defaulting to localhost
CR Debug(Old_Laphroaig:0): In crNetConnectToServer( "localhost", port=10000,
mtu=8096, broker=0 )
CR Debug(Old_Laphroaig:0): Connecting to Old_Laphroaig on port 10000, with
protocol tcpip
CR Debug(Old_Laphroaig:0): Done connecting to localhost (swapping=0)
Processing mothership request: "acceptrequest tcpip Old_Laphroaig 7000 0"
tcpip_connect_wait
tcpip_connect_wait

Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ crappfaker
CR Warning(Old_Laphroaig:0): crGetPID not implemented on Windows yet!
CR Warning(Old_Laphroaig:0): Couldn't find the CRMOTHERSHIP environment
variable, defaulting to localhost
CR Debug(Old_Laphroaig:0): In crNetConnectToServer( "localhost", port=10000,
mtu=8096, broker=0 )
CR Debug(Old_Laphroaig:0): Connecting to Old_Laphroaig on port 10000, with
protocol tcpip
CR Debug(Old_Laphroaig:0): Done connecting to localhost (swapping=0)
Processing mothership request: "faker Old_Laphroaig"
Replying (200): "0 atlantis"
Processing mothership request: "fakerparam start_dir"
Replying (200): "e:\cr-1.9/bin/WIN_NT"
Processing mothership request: "exit"

Thank you for using Chromium!
CR Debug(Old_Laphroaig:0): Dead connection (sock=1920, host=Old_Laphroaig),
removing from pool
CR Debug(Old_Laphroaig:0): Dead connection (sock=1732, host=Old_Laphroaig),
removing from pool
CR Error(Old_Laphroaig:0): Mothership didn't like my accept request
CR Debug(Old_Laphroaig:0): Cleaning up SPU render
CR Debug(Old_Laphroaig:0): Cleaning up SPU error
[1]-  Done                    python crdemo.conf atlantis
Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$
[2]+  Done                    crserver
Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$


==== END ====

Does anyone have any insight as to what my next step should be? Thanks in
advance.

--Dave


-- 
David L. Page
dav...@ie...
865.607.8192

Re: [Chromium-users] SDP warning messages

[Dan B. P. <ph...@cs...>]

looks like the conn->buffer_size is set by the MTU.  try increasing the 
MTU on your network drivers.


Gee Bum Koo wrote:
>  Hi all, 
>
>  I managed to run Chromium with Infiniband + SDP. However, when I run
> mplayer with tilesort SPU, I get tons of "Sending as BIG, the
> performance is going to tank!!!.  You need larger buffers!!!" warnings. 
>
>  How can I get rid of this warning message ?
>
>  Regards,
>  Gee Bum.
>
> ===================
>  Here is my configuration file :
>
> #
> # Import modules
> #
> import os
> os.environ['CR_SDP_SUFFIX'] = '-ib'
> import sys
> sys.path.append( "../server" )
>
> # Import Chromium module
> from mothership import *
>
>
>
> # System configuration
> SHELL      = "/usr/bin/ssh"
> ENV        = "CRMOTHERSHIP=master01 CR_SDP_SUFFIX='-ib'
> LD_LIBRARY_PATH=/usr/local/CR/lib/Linux"
> CRSERVER   = "/usr/local/CR/bin/Linux/crserver -mothership master01
>   
>> & /dev/null"
>>     
> CRAPPFAKER = "/usr/local/CR/bin/Linux/crappfaker -mothership master01"
> CRLIBDIR   = "/usr/local/CR/lib/Linux/"
>
>
>
> # Definition of global constant numbers
> TILE_ROWS = 2
> TILE_COLS = 4
> TILE_WIDTH = 2048       # Width of a tile
> TILE_HEIGHT = 1080      # Height of a tile
>
>
> # Global configuration
> cr = CR()
>
>
> # List of nodes
> TILES = [('display01',    0, 1036), ('display02', 2048, 1036),
>          ('display03',    0,    0), ('display04', 2048,    0),
>          ('display09', 3212, 1036), ('display10', 5260, 1036),
>          ('display11', 3212,    0), ('display12', 5260,    0)]
>
>
>
>
> # Creation of tilesort SPU
> tileSortSPU = SPU('tilesort')
> tileSortSPU.Conf('bucket_mode', 'Broadcast')
> tileSortSPU.Conf('retile_on_resize', 0)
> tileSortSPU.Conf('display_string', 'localhost:0.0')
> #tileSortSPU.Conf('render_to_crut_window', '1')
>
>
>
> # Client node : where application begins
> clientNode = CRApplicationNode('master01')
> clientNode.SPUDir('/usr/local/CR/lib/Linux')
> clientNode.SetApplication(sys.argv[1])
> clientNode.AddSPU(SPU('array'))
> clientNode.AddSPU(tileSortSPU)
> clientNode.AutoStart([SHELL, \
>                       "master01", \
>                       "/bin/sh -c '" + ENV + " " + CRAPPFAKER + "'"])
>
>
>
> for (hostname, x, y) in TILES:
>     # Creation of a new node (display)
>     node = CRNetworkNode(hostname)
>     node.AddTile(x, y, TILE_WIDTH, TILE_HEIGHT)
>     node.Conf('optimize_bucket', 0)
>     # Create a render SPU & register it to the new node
>     renderSPU = SPU('render')
>     renderSPU.Conf('fullscreen', '1')
>     renderSPU.Conf('display_string', 'localhost:0.0')
>     renderSPU.Conf('borderless', '1')
>     renderSPU.Conf('show_cursor', '1')
>
> #    if hostname == 'display01':
> #        renderSPU.Conf('is_swap_master', '1')
> #        renderSPU.Conf('num_swap_clients', '15') 
>     node.AddSPU(renderSPU)
>     node.SPUDir('/usr/local/CR/lib/Linux')
>     node.AutoStart([SHELL, \
>                     hostname, \
>                     "/bin/sh -c '" + ENV + " " + CRSERVER + "'"])
>
>     # Add node to mothership configuration 
>     cr.AddNode(node)
>
>     # Connect nodes ... (?)
>     tileSortSPU.AddServer(node, protocol='sdp')
>
>
>
> #
> # Let's party !!!
> #
> cr.AddNode(clientNode)
> cr.Go()
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Chromium-users mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-users
>   

[Chromium-users] SDP warning messages

[Gee B. K. <vo...@ki...>]

 Hi all, 

 I managed to run Chromium with Infiniband + SDP. However, when I run
mplayer with tilesort SPU, I get tons of "Sending as BIG, the
performance is going to tank!!!.  You need larger buffers!!!" warnings. 

 How can I get rid of this warning message ?

 Regards,
 Gee Bum.

===================
 Here is my configuration file :

#
# Import modules
#
import os
os.environ['CR_SDP_SUFFIX'] = '-ib'
import sys
sys.path.append( "../server" )

# Import Chromium module
from mothership import *



# System configuration
SHELL      = "/usr/bin/ssh"
ENV        = "CRMOTHERSHIP=master01 CR_SDP_SUFFIX='-ib'
LD_LIBRARY_PATH=/usr/local/CR/lib/Linux"
CRSERVER   = "/usr/local/CR/bin/Linux/crserver -mothership master01
>& /dev/null"
CRAPPFAKER = "/usr/local/CR/bin/Linux/crappfaker -mothership master01"
CRLIBDIR   = "/usr/local/CR/lib/Linux/"



# Definition of global constant numbers
TILE_ROWS = 2
TILE_COLS = 4
TILE_WIDTH = 2048       # Width of a tile
TILE_HEIGHT = 1080      # Height of a tile


# Global configuration
cr = CR()


# List of nodes
TILES = [('display01',    0, 1036), ('display02', 2048, 1036),
         ('display03',    0,    0), ('display04', 2048,    0),
         ('display09', 3212, 1036), ('display10', 5260, 1036),
         ('display11', 3212,    0), ('display12', 5260,    0)]




# Creation of tilesort SPU
tileSortSPU = SPU('tilesort')
tileSortSPU.Conf('bucket_mode', 'Broadcast')
tileSortSPU.Conf('retile_on_resize', 0)
tileSortSPU.Conf('display_string', 'localhost:0.0')
#tileSortSPU.Conf('render_to_crut_window', '1')



# Client node : where application begins
clientNode = CRApplicationNode('master01')
clientNode.SPUDir('/usr/local/CR/lib/Linux')
clientNode.SetApplication(sys.argv[1])
clientNode.AddSPU(SPU('array'))
clientNode.AddSPU(tileSortSPU)
clientNode.AutoStart([SHELL, \
                      "master01", \
                      "/bin/sh -c '" + ENV + " " + CRAPPFAKER + "'"])



for (hostname, x, y) in TILES:
    # Creation of a new node (display)
    node = CRNetworkNode(hostname)
    node.AddTile(x, y, TILE_WIDTH, TILE_HEIGHT)
    node.Conf('optimize_bucket', 0)
    # Create a render SPU & register it to the new node
    renderSPU = SPU('render')
    renderSPU.Conf('fullscreen', '1')
    renderSPU.Conf('display_string', 'localhost:0.0')
    renderSPU.Conf('borderless', '1')
    renderSPU.Conf('show_cursor', '1')

#    if hostname == 'display01':
#        renderSPU.Conf('is_swap_master', '1')
#        renderSPU.Conf('num_swap_clients', '15') 
    node.AddSPU(renderSPU)
    node.SPUDir('/usr/local/CR/lib/Linux')
    node.AutoStart([SHELL, \
                    hostname, \
                    "/bin/sh -c '" + ENV + " " + CRSERVER + "'"])

    # Add node to mothership configuration 
    cr.AddNode(node)

    # Connect nodes ... (?)
    tileSortSPU.AddServer(node, protocol='sdp')



#
# Let's party !!!
#
cr.AddNode(clientNode)
cr.Go()

[Chromium-users] Frame rate measurement/ply or vrml format file

[Aleksander S. <edw...@op...>]

Hello,

i have to simple question:


1. Is there any API in OpenSG that supports frame rate measurement?

2. Is it possible to read model in VRML or PLY format file?



Aleksander

[Chromium-users] New User Question: Windows and Chromium: Problem with first demo atlantis

[David L. P. P. <pa...@gm...>]

I have installed Chromium on Windows system. I have compiled Chromium and I
am attempting to run the initial demos.

I am following the Chromium documentation and running the atlantis demo
first. The documentation lists the following four steps:

1: % cd mothership/configs
2: % python crdemo.conf atlantis &
3: % crserver &
4: % crappfaker

My question is do I perform these four steps on the same machine (i.e.
Chromium okay with 127.0.0.1 loopbacks?). Or should I run #1 and #2 on one
machine, #3 on a second machine, and #4 on a third machine, all networked
together?

I only have one maching at the moment. I've attempted to run the four steps
under Cygwin on one machine. Here's a cut-n-paste of my results. I get an
error at step #3. I've added my computer's name into the
C:/Windows/system32/drivers/etc/hosts file (i.e. Cygwin, /etc/hosts) as a
loopback entry (127.0.0.1  Old_Laphroaig).


=== Begin log file ===

Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ python crdemo.conf atlantis &
[1] 4648
Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ This is Chromium, Version 1.9
Start a crappfaker on Old_Laphroaig.um1.comcast.net.
Start a crserver on Old_Laphroaig.um1.comcast.net.

Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ crserver &
[2] 5412
Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$ CR Warning(Old_Laphroaig:0): crGetPID not implemented on Windows yet!
CR Warning(Old_Laphroaig:0): Couldn't find the CRMOTHERSHIP environment
variable, defaulting to localhost
CR Warning(Old_Laphroaig:0): Couldn't find the CRMOTHERSHIP environment
variable, defaulting to localhost
CR Warning(Old_Laphroaig:0): Render SPU: WGL wants these visual
capabilities: RGB, Doublebuffer, Z
CR Warning(Old_Laphroaig:0): Render SPU: WGL chose these visual
capabilities: RGB, Doublebuffer, Z, Accum
CR Warning(Old_Laphroaig:0): Couldn't find the CRMOTHERSHIP environment
variable, defaulting to localhost
Mothership error: could not qualify hostname 'Old_Laphroaig' - check
/etc/hosts

MOTHERSHIP EXCEPTION!  TERRIBLE!
Traceback (most recent call last):
  File "../server/mothership.py", line 1062, in Go
    self.ProcessRequest( self.wrappers[sock] )
  File "../server/mothership.py", line 2215, in ProcessRequest
    fn( sock_wrapper, arguments)
  File "../server/mothership.py", line 1419, in do_acceptrequest
    self.AcceptTCPIP(sock, accept_info)
  File "../server/mothership.py", line 1277, in AcceptTCPIP
    Fatal( "Mothership error: could not qualify hostname '%s' - check
/etc/hosts" % hostname)
  File "../server/mothership.py", line 102, in Fatal
    sys.exit(-1)
SystemExit: -1
CR Error(Old_Laphroaig:0): Mothership didn't like my accept request
[1]-  Done                    python crdemo.conf atlantis
[2]+  Done                    crserver
Dave@Old_Laphroaig /cygdrive/e/cr-1.9/mothership/configs
$

=== End log file ===


Any insight would be greatly appreciated. Thank you.

--Dave

Re: [Chromium-users] JOGL+Chromium

[Brian P. <bri...@tu...>]

Jean-Christophe Ducom wrote:
> Thanks Brian. It helps
> That was an easy fix that I should have tried...
> Can I leave that line commented safely for future?

Yes, I'll remove it in CVS too.

-Brian

Re: [Chromium-users] JOGL+Chromium

[Jean-Christophe D. <jc_...@nd...>]

Thanks Brian. It helps
That was an easy fix that I should have tried...
Can I leave that line commented safely for future?
Thanks again
JC


Brian Paul wrote:
> Jean-Christophe Ducom wrote:
>> All-
>> One of my users applications uses JavaOpengL( 
>> https://jogl.dev.java.net/) His application runs fine on a single 
>> display.
>> When it runs on DMX+Chromium, it returns the error message:
>> ----
>> CR Error(node01:4318): Assertion failed: usage == GL_STATIC_DRAW_ARB, 
>> file unpack_bufferobject.c, line 40
>> ----
>> CR-1.9 was recompiled from source.
>> The system is running FC7, with Geforce8800GTS
>> Any info/insight will be appreciated
> 
> I think the assertion is bogus and could probably be removed.  Can you 
> try that?
> 
> -Brian
> 
> 

Re: [Chromium-users] JOGL+Chromium

[Brian P. <bri...@tu...>]

Jean-Christophe Ducom wrote:
> All-
> One of my users applications uses JavaOpengL( 
> https://jogl.dev.java.net/) His application runs fine on a single display.
> When it runs on DMX+Chromium, it returns the error message:
> ----
> CR Error(node01:4318): Assertion failed: usage == GL_STATIC_DRAW_ARB, 
> file unpack_bufferobject.c, line 40
> ----
> CR-1.9 was recompiled from source.
> The system is running FC7, with Geforce8800GTS
> Any info/insight will be appreciated

I think the assertion is bogus and could probably be removed.  Can you 
try that?

-Brian

[Chromium-users] JOGL+Chromium

[Jean-Christophe D. <jc_...@nd...>]

All-
One of my users applications uses JavaOpengL( 
https://jogl.dev.java.net/) His application runs fine on a single display.
When it runs on DMX+Chromium, it returns the error message:
----
CR Error(node01:4318): Assertion failed: usage == GL_STATIC_DRAW_ARB, 
file unpack_bufferobject.c, line 40
----
CR-1.9 was recompiled from source.
The system is running FC7, with Geforce8800GTS
Any info/insight will be appreciated
Thanks
JC

[Chromium-users] DMX question

[Jean-Christophe D. <jc_...@nd...>]

All-
I believe it's more a DMX-related question than Chromium but the list 
appears to me a little more alive than the DMX one.

I am trying to get the binaries VisIt1.8.0  to work on our wall display 5x3.
Each node runs FC7 and CR-1.9 (recompiled from sources). The video card 
is GeForce 8800 GT with NVIDIA driver 171.05 (see attached glxinfo)
# rpm -qa | grep dmx
libdmx-1.0.2-3.1
xorg-x11-server-Xdmx-1.3.0.0-16.fc7

When VisIt is started on the wall display , the GUI Main window is not 
displayed, only one viz window show sup.
The problem occurs whether or not Chromium is used, which makes me think 
that there is a problem with DMX libs (?)
Command to start Xdmx:
/usr/bin/Xdmx :1 +xinerama -configfile /etc/wall/noloss -ac -br &
Error when VisIt is started:
(**) dmx: dmxErrorHandler: BadDrawable (invalid Pixmap or Window parameter)
(**) dmx:                  Major opcode: 62 (X_CopyArea)
(**) dmx:                  ResourceID:   0x601073
(**) dmx:                  Failed serial number:  24723
(**) dmx:                  Current serial number: 24750
Everything works fine on individual nodes (bot window are display 
GUI+viz window)

Any insight why it doesn't work? Do I need to recompile dmx from source 
and if so, what host.def did you use?
Thank you for any insight/pointers/contact.

JC

-----------------
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
     GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,
     GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control,
     GLX_EXT_texture_from_pixmap, GLX_ARB_multisample, GLX_NV_float_buffer,
     GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4

client glx version string: 1.4
client glx extensions:
     GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info,
     GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync,
     GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer,
     GLX_SGI_swap_control, GLX_NV_float_buffer, GLX_ARB_fbconfig_float,
     GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap,
     GLX_EXT_framebuffer_sRGB
GLX version: 1.3
GLX extensions:
     GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,
     GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control,
     GLX_EXT_texture_from_pixmap, GLX_ARB_multisample, GLX_NV_float_buffer,
     GLX_ARB_fbconfig_float, GLX_EXT_framebuffer_sRGB,
     GLX_ARB_get_proc_address
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 8800 GT/PCI/SSE2
OpenGL version string: 2.1.2 NVIDIA 171.05
OpenGL extensions:
     GL_ARB_color_buffer_float, GL_ARB_depth_texture, GL_ARB_draw_buffers,
     GL_ARB_fragment_program, GL_ARB_fragment_program_shadow,
     GL_ARB_fragment_shader, GL_ARB_half_float_pixel, GL_ARB_imaging,
     GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,
     GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, 
GL_ARB_point_sprite,
     GL_ARB_shadow, GL_ARB_shader_objects, GL_ARB_shading_language_100,
     GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
     GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
     GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, 
GL_ARB_texture_float,
     GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,
     GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,
     GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, 
GL_ARB_vertex_shader,
     GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float,
     GL_ATI_texture_mirror_once, GL_S3_s3tc, GL_EXT_texture_env_add,
     GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
     GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
     GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
GL_EXT_compiled_vertex_array,
     GL_EXT_Cg_shader, GL_EXT_bindable_uniform, GL_EXT_depth_bounds_test,
     GL_EXT_draw_buffers2, GL_EXT_draw_instanced, 
GL_EXT_draw_range_elements,
     GL_EXT_fog_coord, GL_EXT_framebuffer_blit, 
GL_EXT_framebuffer_multisample,
     GL_EXT_framebuffer_object, GL_EXTX_framebuffer_mixed_formats,
     GL_EXT_framebuffer_sRGB, GL_EXT_geometry_shader4,
     GL_EXT_gpu_program_parameters, GL_EXT_gpu_shader4,
     GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,
     GL_EXT_packed_float, GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object,
     GL_EXT_point_parameters, GL_EXT_rescale_normal, 
GL_EXT_secondary_color,
     GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
     GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D,
     GL_EXT_texture_array, GL_EXT_texture_buffer_object,
     GL_EXT_texture_compression_latc, GL_EXT_texture_compression_rgtc,
     GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
     GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine,
     GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
     GL_EXT_texture_integer, GL_EXT_texture_lod, GL_EXT_texture_lod_bias,
     GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, 
GL_EXT_texture_sRGB,
     GL_EXT_texture_shared_exponent, GL_EXT_timer_query, 
GL_EXT_vertex_array,
     GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat,
     GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_copy_depth_to_color,
     GL_NV_depth_buffer_float, GL_NV_conditional_render, GL_NV_depth_clamp,
     GL_NV_fence, GL_NV_float_buffer, GL_NV_fog_distance,
     GL_NV_fragment_program, GL_NV_fragment_program_option,
     GL_NV_fragment_program2, GL_NV_framebuffer_multisample_coverage,
     GL_NV_geometry_shader4, GL_NV_gpu_program4, GL_NV_half_float,
     GL_NV_light_max_exponent, GL_NV_multisample_coverage,
     GL_NV_multisample_filter_hint, GL_NV_occlusion_query,
     GL_NV_packed_depth_stencil, GL_NV_parameter_buffer_object,
     GL_NV_pixel_data_range, GL_NV_point_sprite, GL_NV_primitive_restart,
     GL_NV_register_combiners, GL_NV_register_combiners2,
     GL_NV_texgen_reflection, GL_NV_texture_compression_vtc,
     GL_NV_texture_env_combine4, GL_NV_texture_expand_normal,
     GL_NV_texture_rectangle, GL_NV_texture_shader, GL_NV_texture_shader2,
     GL_NV_texture_shader3, GL_NV_transform_feedback, 
GL_NV_vertex_array_range,
     GL_NV_vertex_array_range2, GL_NV_vertex_program, 
GL_NV_vertex_program1_1,
     GL_NV_vertex_program2, GL_NV_vertex_program2_option,
     GL_NV_vertex_program3, GL_NVX_conditional_render, 
GL_SGIS_generate_mipmap,
     GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow,
     GL_SUN_slice_accum

Re: [Chromium-users] Crash with DMX and Alpha

[Brian T. <bri...@gm...>]

Figured it out finally.  Didn't catch that libGL was not properly linked to
the chromium libraries.  Thanks for the help.

On Thu, Mar 27, 2008 at 7:23 PM, Brian Paul <bri...@tu...>
wrote:

> Brian Thomas wrote:
> > We are running chromium on a display wall using DMX.  It seems to be
> > working well except for when we try to get a display mode with an alpha
> > channel.  For example, using GLUT_ALPHA.  One example program crashes
> > with the following message:
> >
> > X Error of failed request:  BadMatch (invalid parameter attributes)
> >   Major opcode of failed request:  144 (GLX)
> >   Minor opcode of failed request:  5 (X_GLXMakeCurrent)
> >   Serial number of failed request:  19
> >   Current serial number in output stream:  19
> >
> > Removing GLUT_ALPHA causes it to run without error.  We have had this
> > problem for several months now and would appreciate any suggestions.
>
> In your config file, try setting the 'default_visual' option for your
> render SPUs.  For example:
>
> renderspu.Conf('default_visual', 'rgb, double, depth, stencil, alpha')
>
>
> Otherwise, the problem is likely that the Cr version of
> glXChooseVisual() in opengl_stub/glx.c is returning a different GLX
> visual ID than what's being chosen in spu/render/renderspu_glx.c
>
> You might try instrumenting the crChooseVisual() function in
> spu_loader/choosevisual.c to print the incoming attribute list and
> returned visual ID.  That might give a clue.
>
> -Brian
>
>


-- 
****************************
Brian Thomas
bj...@ms...
****************************

Re: [Chromium-users] Crash with DMX and Alpha

[Brian T. <bri...@gm...>]

I guess also important is that the same error occurs without using chromium
as well.  So I'm not sure if it is a chromium issue or a dmx issue.
However, if I run it using DISPLAY=:0, it works just fine.

Thanks!

On Thu, Mar 27, 2008 at 7:23 PM, Brian Paul <bri...@tu...>
wrote:

> Brian Thomas wrote:
> > We are running chromium on a display wall using DMX.  It seems to be
> > working well except for when we try to get a display mode with an alpha
> > channel.  For example, using GLUT_ALPHA.  One example program crashes
> > with the following message:
> >
> > X Error of failed request:  BadMatch (invalid parameter attributes)
> >   Major opcode of failed request:  144 (GLX)
> >   Minor opcode of failed request:  5 (X_GLXMakeCurrent)
> >   Serial number of failed request:  19
> >   Current serial number in output stream:  19
> >
> > Removing GLUT_ALPHA causes it to run without error.  We have had this
> > problem for several months now and would appreciate any suggestions.
>
> In your config file, try setting the 'default_visual' option for your
> render SPUs.  For example:
>
> renderspu.Conf('default_visual', 'rgb, double, depth, stencil, alpha')
>
>
> Otherwise, the problem is likely that the Cr version of
> glXChooseVisual() in opengl_stub/glx.c is returning a different GLX
> visual ID than what's being chosen in spu/render/renderspu_glx.c
>
> You might try instrumenting the crChooseVisual() function in
> spu_loader/choosevisual.c to print the incoming attribute list and
> returned visual ID.  That might give a clue.
>
> -Brian
>
>


-- 
****************************
Brian Thomas
bj...@ms...
****************************

Re: [Chromium-users] Crash with DMX and Alpha

[Brian P. <bri...@tu...>]

Brian Thomas wrote:
> We are running chromium on a display wall using DMX.  It seems to be 
> working well except for when we try to get a display mode with an alpha 
> channel.  For example, using GLUT_ALPHA.  One example program crashes 
> with the following message:
> 
> X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  144 (GLX)
>   Minor opcode of failed request:  5 (X_GLXMakeCurrent)
>   Serial number of failed request:  19
>   Current serial number in output stream:  19
> 
> Removing GLUT_ALPHA causes it to run without error.  We have had this 
> problem for several months now and would appreciate any suggestions.

In your config file, try setting the 'default_visual' option for your 
render SPUs.  For example:

renderspu.Conf('default_visual', 'rgb, double, depth, stencil, alpha')


Otherwise, the problem is likely that the Cr version of 
glXChooseVisual() in opengl_stub/glx.c is returning a different GLX 
visual ID than what's being chosen in spu/render/renderspu_glx.c

You might try instrumenting the crChooseVisual() function in 
spu_loader/choosevisual.c to print the incoming attribute list and 
returned visual ID.  That might give a clue.

-Brian

[Chromium-users] Crash with DMX and Alpha

[Brian T. <bri...@gm...>]

We are running chromium on a display wall using DMX.  It seems to be working
well except for when we try to get a display mode with an alpha channel.
For example, using GLUT_ALPHA.  One example program crashes with the
following message:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  144 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  19
  Current serial number in output stream:  19

Removing GLUT_ALPHA causes it to run without error.  We have had this
problem for several months now and would appreciate any suggestions.

Thanks!

-Brian Thomas

-- 
****************************
Brian Thomas
bj...@ms...
****************************

Re: [Chromium-users] using chromium and glew?

[Alan H. <al...@tu...>]

On Mon, 2008-03-10 at 14:10 +0100, IOhannes m zmoelnig wrote:
> Alan Hourihane wrote:
> > 
> > In the opengl_stub/getprocaddress.py code we never return any glX*() 
> > functions for glXGetProcAddress() which actually translates into
> > crGetProcAddress().
> > 
> > It's should just be a matter of adding glX*() functions to this so 
> > that Chromium can return the appropriate address.
> 
> a thanks for the hint.
> 
> so what is the best way for me to proceed?
> i just added all of the glX functions to opengl_stub/getprocaddress.c, 
> just to discover (when i was about to send a diff) that getprocaddress.c 
> is generated by getprocaddress.py (yea, now i know that i should have 
> read the boilerplate of getprocaddress.c!), which uses 
> glapi_parser/APIspec.txt to know what to generate.
> 
> should i put glX directly into getprocaddress.py, or should i create 
> definitions in glapi_parser/APIspec.txt.

I'd probably add the glX functions directly to getprocaddress.py, and
ignore APIspec.txt

Alan.

Re: [Chromium-users] using chromium and glew?

[IOhannes m z. <zmo...@ie...>]

Alan Hourihane wrote:
> 
> In the opengl_stub/getprocaddress.py code we never return any glX*() 
> functions for glXGetProcAddress() which actually translates into
> crGetProcAddress().
> 
> It's should just be a matter of adding glX*() functions to this so 
> that Chromium can return the appropriate address.

a thanks for the hint.

so what is the best way for me to proceed?
i just added all of the glX functions to opengl_stub/getprocaddress.c, 
just to discover (when i was about to send a diff) that getprocaddress.c 
is generated by getprocaddress.py (yea, now i know that i should have 
read the boilerplate of getprocaddress.c!), which uses 
glapi_parser/APIspec.txt to know what to generate.

should i put glX directly into getprocaddress.py, or should i create 
definitions in glapi_parser/APIspec.txt.

or is this totally the wrong way to do it? (e.g. because there are no 
plans in chromium for what i would like to have)


mfg.adsr
IOhannes

PS: adding the glX-functions to the getprocaddress indeed did the trick 
and everything went smoothly...

Re: [Chromium-users] using chromium and glew?

[Alan H. <al...@tu...>]

On Mon, 2008-03-10 at 12:16 +0100, IOhannes m zmoelnig wrote:
> IOhannes m zmoelnig wrote:
> > Alan Hourihane wrote:
> 
> > that is why i try to find out why glewInit() claims to fail (read: not 
> > being able to determine which extensions are/openGL version is supported)
> 
> ok, i was able to narrow the problem down.
> 
> the problem is in some glx-initialisation routine.
> glew tries to get the pointer to glXGetCurrentDisplay() by issuing
>     glXGetProcAddressARB((const GLubyte*)"glXGetCurrentDisplay")
> 
> on my normal system (without chromium) this returns the address of the 
> function call.
> when running chromium, this calls returns 0
> 
> 
> luckily (for me) i currently don't use the glx extension wrangler of 
> GLEW, so i have no _real_ problems.
> 
> nevertheless i am wondering, why i don't get the correct address when 
> using chromium (i guess it will turn into a problem, once somebody wants 
> to use glew for glx extension checking in combination with chromium)
> 
> any hints?

In the opengl_stub/getprocaddress.py code we never return any glX*() 
functions for glXGetProcAddress() which actually translates into
crGetProcAddress().

It's should just be a matter of adding glX*() functions to this so 
that Chromium can return the appropriate address.

Alan.

Re: [Chromium-users] using chromium and glew?

[IOhannes m z. <zmo...@ie...>]

IOhannes m zmoelnig wrote:
> Alan Hourihane wrote:

> that is why i try to find out why glewInit() claims to fail (read: not 
> being able to determine which extensions are/openGL version is supported)

ok, i was able to narrow the problem down.

the problem is in some glx-initialisation routine.
glew tries to get the pointer to glXGetCurrentDisplay() by issuing
    glXGetProcAddressARB((const GLubyte*)"glXGetCurrentDisplay")

on my normal system (without chromium) this returns the address of the 
function call.
when running chromium, this calls returns 0


luckily (for me) i currently don't use the glx extension wrangler of 
GLEW, so i have no _real_ problems.

nevertheless i am wondering, why i don't get the correct address when 
using chromium (i guess it will turn into a problem, once somebody wants 
to use glew for glx extension checking in combination with chromium)

any hints?


fgamsdr
IOhannes

Re: [Chromium-users] using chromium and glew?

[IOhannes m z. <zmo...@ie...>]

Alan Hourihane wrote:

> Chromium doesn't support OpenGL 2.x at this time.

yes, i thought so.
however, this is not what bothers me. i am using glew exactly for this: 
to support backends that do not have specific extensions (e.g. 
openGL-2.x) without having to worry to much on my side.

that is why i try to find out why glewInit() claims to fail (read: not 
being able to determine which extensions are/openGL version is supported)

fmgasd.r
IOhannes