Pages: [1]
  Print  
Author Topic: Netbook not running OA via XDMCP [SOLVED]  (Read 7838 times)
josephg
Ok i've posted twice!


Cakes 0
Posts: 2


« on: December 10, 2009, 10:45:18 PM »

Hello all.

I want to play OA in Local Network with my computer (which can easily run OA) and my brother's netbook ( which can't run OA locally. Tried, but start with FPS=1 ). Both have ArchLinux, mine 64bits and his 32bits.

Due to lack of processing capacity of his netbook, I decided to try XDMCP, having my computer as server, processing all stuff, and his as client, only receiving data via network. But it didn't work. XDMCP works fine, but OpenArean fails.  I don't know if I miss some information about how XDMCP works or misconfigured something... Can you take a look at the outputs ?

Thanks in advance!

My computer (normal output / it works)
Code:
$ openarena
ioq3+oa 1.35 linux-x86_64 Nov  3 2009
----- FS_Startup -----
Current search path:
/home/user/.openarena/baseoa/mkexp.pk3 (85 files)
/home/user/.openarena/baseoa/ermap3.pk3 (33 files)
/home/user/.openarena/baseoa
/usr/share/openarena/baseoa/pak6-misc.pk3 (229 files)
/usr/share/openarena/baseoa/pak5-TA.pk3 (139 files)
/usr/share/openarena/baseoa/pak4-textures.pk3 (1753 files)
/usr/share/openarena/baseoa/pak2-players.pk3 (669 files)
/usr/share/openarena/baseoa/pak2-players-mature.pk3 (231 files)
/usr/share/openarena/baseoa/pak1-maps.pk3 (100 files)
/usr/share/openarena/baseoa/pak0.pk3 (1042 files)
/usr/share/openarena/baseoa

----------------------
4281 files in pk3 files
execing default.cfg
execing q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
----- Client Initialization -----
----- Initializing Renderer ----
-------------------------------
QKEY found.
----- Client Initialization Complete -----
----- R_Init -----
SDL using driver "x11"
Initializing OpenGL display
Estimated display aspect: 3.200
...setting mode -1: 1280 1024
Using 8/8/8 Color bits, 24 depth, 0 stencil display.
Available modes: '3360x1050'
GL_RENDERER: GeForce 8800 GS/PCI/SSE2
Initializing OpenGL extensions
...ignoring GL_EXT_texture_compression_s3tc
...ignoring GL_S3_s3tc
...using GL_EXT_texture_env_add
...using GL_ARB_multitexture
...using GL_EXT_compiled_vertex_array
...ignoring GL_EXT_texture_filter_anisotropic

GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce 8800 GS/PCI/SSE2
GL_VERSION: 3.2.0 NVIDIA 190.42
GL_EXTENSIONS: GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_coord_conventions GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_map_buffer_range 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_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object 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_bindable_uniform 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_depth_bounds_test GL_EXT_direct_state_access 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_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_object 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_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_shader_objects 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_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_depth_clamp GL_NV_explicit_multisample 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_parameter_buffer_object2 GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_shader_buffer_load GL_NV_texgen_reflection GL_NV_texture_barrier 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_buffer_unified_memory GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NVGL_MAX_TEXTURE_SIZE: 8192
GL_MAX_TEXTURE_UNITS_ARB: 4

PIXELFORMAT: color(24-bits) Z(24-bit) stencil(0-bits)
MODE: -1, 1280 x 1024 windowed hz:N/A
GAMMA: hardware w/ 0 overbright bits
rendering primitives: single glDrawElements
texturemode: GL_LINEAR_MIPMAP_NEAREST
dipstick: 2
texture bits: 0
multitexture: enabled
compiled vertex arrays: enabled
texenv add: enabled
compressed textures: disabled
Initializing Shaders
----- finished R_Init -----
------ Initializing Sound ------
Loading "libopenal.so.0"...
Failed to load library: "libopenal.so.0".
SDL_Init( SDL_INIT_AUDIO )... OK
SDL audio driver is "alsa".
SDL_AudioSpec:
  Format:   AUDIO_S16LSB
  Freq:     22050
  Samples:  705
  Channels: 2
Starting SDL audio callback...
SDL audio initialized.
----- Sound Info -----
    1 stereo
16384 samples
   16 samplebits
    1 submission_chunk
22050 speed
0x39f5d40 dma buffer
No background file.
----------------------
Sound initialization successful.
--------------------------------
Sound memory manager started
Loading vm file vm/ui.qvm...
...which has vmMagic VM_MAGIC_VER2
Loading 1349 jump table targets
total 0, hsize 1021, zero 1021, min 0, max 0
total 8436, hsize 1021, zero 2, min 0, max 32
VM file ui compiled to 2768467 bytes of code (0x7f88733a5000 - 0x7f8873648e53)
compilation took 1.086778 seconds
ui loaded in 1398048 bytes on the hunk
43 arenas parsed
24 bots parsed
--- Common Initialization Complete ---
IP: 127.0.0.1
IP: 192.168.0.10
IP6: ::1
IP6: fe80::200:5aff:fe00:b0e%eth0
Opening IP6 socket: [::]:27960
Opening IP socket: 0.0.0.0:27960

His computer (output when started in XDMCP graphic interface / fail)
Code:
$ openarena
ioq3+oa 1.35 linux-x86_64 Nov  3 2009
----- FS_Startup -----
Current search path:
/home/guest/.openarena/baseoa
/usr/share/openarena/baseoa/pak6-misc.pk3 (229 files)
/usr/share/openarena/baseoa/pak5-TA.pk3 (139 files)
/usr/share/openarena/baseoa/pak4-textures.pk3 (1753 files)
/usr/share/openarena/baseoa/pak2-players.pk3 (669 files)
/usr/share/openarena/baseoa/pak2-players-mature.pk3 (231 files)
/usr/share/openarena/baseoa/pak1-maps.pk3 (100 files)
/usr/share/openarena/baseoa/pak0.pk3 (1042 files)
/usr/share/openarena/baseoa

----------------------
4163 files in pk3 files
execing default.cfg
couldn't exec q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
----- Client Initialization -----
Couldn't read q3history.
Your network rate is too slow for VoIP.
Set 'Data Rate' to 'LAN/Cable/xDSL' in 'Setup/System/Network' and
restart.
Until then, VoIP is disabled.
----- Initializing Renderer ----
-------------------------------
QKEY found.
----- Client Initialization Complete -----
----- R_Init -----
SDL using driver "x11"
Initializing OpenGL display
Estimated display aspect: 1.707
...setting mode 3: 640 480
Available modes: '1024x600'
Couldn't get a visual
...WARNING: could not set the given mode (3)
----- CL_Shutdown -----
RE_Shutdown( 1 )
-----------------------
GLimp_Init() - could not load OpenGL subsystem
« Last Edit: December 11, 2009, 01:16:28 PM by josephg » Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #1 on: December 11, 2009, 12:55:02 AM »

I don't think you will have any success if the netbook cannot render openGL. The documentation I found about XDMCP and OpenGL is that the client receives the OpenGL calls from the host and must render the picture itself.
Logged

There are nothing offending in my posts.
Falkland
Member


Cakes 6
Posts: 590


« Reply #2 on: December 11, 2009, 08:53:59 AM »

I don't think you will have any success if the netbook cannot render openGL. The documentation I found about XDMCP and OpenGL is that the client receives the OpenGL calls from the host and must render the picture itself.

My experience with X forwarding through ssh says the same : X protocol is forwarded but the access to special devices ( also to the rendering device ) is done on the client.

If I have a NVIDIA card on the host and an ATI on the client , the rendering process will fall back to the software GL simply because the host will make a call to /dev/nvidia0 , it will forward it trhough X protocol but when the call will be executed on the client where there's no /dev/nvidia0 device , the direct render process will fail.
Logged
josephg
Ok i've posted twice!


Cakes 0
Posts: 2


« Reply #3 on: December 11, 2009, 01:16:07 PM »

As I thought. :/

Thanks a lot for the reply!
Logged
kernel panic
Lesser Nub


Cakes 6
Posts: 114


« Reply #4 on: December 23, 2009, 07:51:04 AM »

Yep, X11 forwarding will not cut it. My understanding is that it either sends the whole processed data through the network via xlib (or something), which is very slow, or the GLX commands straight away to be processed by the client. One way around it could be setting indirect rendering, but that would defeat the purpose of having the server doing the heavy duty stuff--and I'm not even sure how it would perform.

But fear not! I've been playing around with several remote display solutions lately, from VNC to X11 forwarding and NX. One solution to display OpenGL remotely is using TurboVNC + VirtualGL. VirtualGL sits somewhere between the application and the server, so it intercepts the 3D commands being sent through the network. The output from VirtualGL (now just a stream of still images) has to be sent through a sufficiently fast path for the client to display them properly. TurboVNC does this. TurboVNC is a VNC server that uses an assembly-optimised jpeg library (by Sun, I think) that performs incredibly well. Really, this is fast, fast, fast. You can launch a HD movie on the server and get it displayed on your client via VNC without a noticeable frame drop. For the sound I guess you could do something via pulse audio, for instance. You can read the details in the wikipedia 'VirtualGL' article, and the instructions to set it up in the project home page--nothing particularly complicated.

One requirement is that the server has to have a graphics card (and driver) that supports pixel buffers, i.e., you want to have the closed source drivers for Nvidia or ATI installed. I'd be interested in knowing whether this works for you, if you try it.

As a side note, this is what CERN uses for remote 3D visualisation, alongside Chromium (which I haven't bother with since it seems overkilling).
Logged
Falkland
Member


Cakes 6
Posts: 590


« Reply #5 on: December 28, 2009, 09:07:25 AM »

Yep, X11 forwarding will not cut it. My understanding is that it either sends the whole processed data through the network via xlib (or something), which is very slow, or the GLX commands straight away to be processed by the client. One way around it could be setting indirect rendering, but that would defeat the purpose of having the server doing the heavy duty stuff--and I'm not even sure how it would perform.

But fear not! I've been playing around with several remote display solutions lately, from VNC to X11 forwarding and NX. One solution to display OpenGL remotely is using TurboVNC + VirtualGL. VirtualGL sits somewhere between the application and the server, so it intercepts the 3D commands being sent through the network. The output from VirtualGL (now just a stream of still images) has to be sent through a sufficiently fast path for the client to display them properly. TurboVNC does this. TurboVNC is a VNC server that uses an assembly-optimised jpeg library (by Sun, I think) that performs incredibly well. Really, this is fast, fast, fast. You can launch a HD movie on the server and get it displayed on your client via VNC without a noticeable frame drop. For the sound I guess you could do something via pulse audio, for instance. You can read the details in the wikipedia 'VirtualGL' article, and the instructions to set it up in the project home page--nothing particularly complicated.

One requirement is that the server has to have a graphics card (and driver) that supports pixel buffers, i.e., you want to have the closed source drivers for Nvidia or ATI installed. I'd be interested in knowing whether this works for you, if you try it.

As a side note, this is what CERN uses for remote 3D visualisation, alongside Chromium (which I haven't bother with since it seems overkilling).

Nice find , I'll try this ...

btw , LHC was stopped on December 16th and it will be started again the next year on February 16th because (it seems that) it produced a very large amount of data during its first month ( more or less ) of work.
Logged
Pages: [1]
  Print  
 
Jump to: