[Bug 17019] mesa implementation error
http://bugs.freedesktop.org/show_bug.cgi?id=17019 Michael Fu <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Michael Fu <[EMAIL PROTECTED]> 2008-08-06 22:30:01 PST --- *** This bug has been marked as a duplicate of bug 11131 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Please HELP!!! accumulation buffers support FC9
Svilen wrote: > Hi, > > This is second time I'm trying to get your attention guys. > Shall I flag it as a bug? Or it is not a DRI problem. I know at least a > couple of similar platforms with the same trouble. > > If this is not a right place to ask the question, I'll appreciate if you > point me another mailing list. I've already discussed this in > [EMAIL PROTECTED] but they claim it's not a driver problem. > > Regards > Svilen > > Svilen Krustev wrote: >> Hi, >> >> I'm having troubles obtaining GLX visual with accumulation buffers. It >> happens only on Fedora 9. Attached is glxinfo log. >> Problem never appears with fglrx drivers, but as you know it's not >> available for FC9. >> >> I'm really looking forward for your comments. >> >> Here is my platform: >> X1600 Mobility Radeon >> Linux, Fedora 9 >> Xorg 7.4 (unofficial) >> Mesa 7.1 (unofficial) >> >> xorg.conf >> ... >> Section "Device" >> Identifier "Videocard0" >> Driver "radeon" >> EndSection >> ... >> >> Regards >> > > > > > name of display: :0.0 > display: :0 screen: 0 > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.2 > server glx extensions: > GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, > GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, > GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group > client glx vendor string: SGI > client glx version string: 1.4 > client glx extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, > GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > GLX version: 1.2 > GLX extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, > GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, > GLX_SGIX_visual_select_group > OpenGL vendor string: DRI R300 Project > OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL > OpenGL version string: 1.3 Mesa 7.1 rc1 > OpenGL extensions: > GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging, > GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_shadow, > 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_crossbar, > GL_ARB_texture_env_dot3, GL_MESAX_texture_float, > GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, > GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, > GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, > GL_EXT_blend_color, GL_EXT_blend_equation_separate, > GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, > GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, > GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, > GL_EXT_draw_range_elements, GL_EXT_gpu_program_parameters, > GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, > GL_EXT_polygon_offset, 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_subtexture, > GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, > GL_EXT_texture_env_add, GL_EXT_texture_env_combine, > GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, > GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, > GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, > GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, > GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, > GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, > GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, > GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, > GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, > GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, > GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, > GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, > GL_SUN_multi_draw_arrays > > 3 GLX Visuals >visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > ---
Please HELP!!! accumulation buffers support FC9
Hi, This is second time I'm trying to get your attention guys. Shall I flag it as a bug? Or it is not a DRI problem. I know at least a couple of similar platforms with the same trouble. If this is not a right place to ask the question, I'll appreciate if you point me another mailing list. I've already discussed this in [EMAIL PROTECTED] but they claim it's not a driver problem. Regards Svilen Svilen Krustev wrote: Hi, I'm having troubles obtaining GLX visual with accumulation buffers. It happens only on Fedora 9. Attached is glxinfo log. Problem never appears with fglrx drivers, but as you know it's not available for FC9. I'm really looking forward for your comments. Here is my platform: X1600 Mobility Radeon Linux, Fedora 9 Xorg 7.4 (unofficial) Mesa 7.1 (unofficial) xorg.conf ... Section "Device" Identifier "Videocard0" Driver "radeon" EndSection ... Regards name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL OpenGL version string: 1.3 Mesa 7.1 rc1 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_shadow, 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_crossbar, GL_ARB_texture_env_dot3, GL_MESAX_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_polygon_offset, 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_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SUN_multi_draw_arrays 3 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x52 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 16 GLXFBConfigs: visual x bf lv rg d st colorbuffer ax dp st
Re: OpenGL 3.0 release at siggraph
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pasi Kärkkäinen wrote: | It seems OpenGL 3.0 will be (finally) released at Siggraph! Yes, finally. :) | http://www.khronos.org/news/events/detail/siggraph_2008_los_angeles_california// | | OpenGL BOF | | SIGGRAPH 2008 | Wednesday, 13 August | 6:00 pm - 8:00 pm | Wilshire Grand Hotel - Wilshire Room I will be at SIGGRAPH and at the BoF this year...in case anyone wants to meet up and hang out or something. | OpenGL 3.0 new features | Specification Review Jeremy Sandmel, Apple | | GLSL 1.3 new features New Shader language definition Bill Licea-Kane, AMD | | OpenGL 3.0 ISV PerspectiveDaniel Koch, Transgaming | Discussion of benefits OpenGL 3.0 provides ISVs Rob Barris, Blizzard I'm hoping to present a lot of this material at the Linux Plumbers Conference in September, in case anyone is attending that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkiZ86EACgkQX1gOwKyEAw8wawCfXryBLJCkReLQYf+uf5ly8jl9 UJsAnR0AkgaNiQy1rdDuv49A0fBAKOnz =PZA7 -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17019] New: mesa implementation error
http://bugs.freedesktop.org/show_bug.cgi?id=17019 Summary: mesa implementation error Product: Mesa Version: 7.0.3 Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I get the following error when trying to run Postal 2 with wine. Mesa 7.0.3-rc2 implementation error: i915_program_error: Exceeded max nr indirect texture lookups Please report at bugzilla.freedesktop.org DRM_I830_CMDBUFFER: -22 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRM question
Yeah, you're right on the money about the architecture, except that we also have a hardware specific userspace driver that the windowing system uses to either take care of video operations with MMIO or by sending the command to the kernel driver. My plan is to replace the kernel drivers with drm drivers. After that, I'll remove the windowing system's dependence on the video driver & instead link it to libGL. At that point, I would have already gotten DRI to build successfully. The one thing that really stumps me is providing DRM capabilities fully as they are in Linux, considering that a lot of our hardware abstractions are completely different. Also, is there any DRM state info that's stored and active in drm.ko? I've also tried to do this without touching the stuff in shared-core, but there are some things in there that doesn't quite fit with Syllable, but are needed for DRM. I may have to add some '#ifdef's' to a few of the headers. There are some things that pretty much expect to be compiled in an XWindow's environment. Also, we support shared object loading, however we can't reference functions from one driver to the next. Dee Sharpe -Original Message- From: Nicolai Hähnle <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; dri-devel@lists.sourceforge.net Sent: Wed, 6 Aug 2008 2:43 am Subject: Re: [Mesa3d-dev] DRM question Am Mittwoch 06 August 2008 02:53:23 schrieb [EMAIL PROTECTED] cape.net: > I've been working on a port of DRM for Syllable.? Syllable doesn't support > drivers (or kernel modules) that are on the same level of abstraction & > communicate with each other.? For example our sound card drivers can't > communicate with any other driver normal driver, they can only communicate > with busmanagers (PCI, ISA, etc.).? With this in mind, I've been wondering > what the signifigance of having a drm kernel object that's seperate from > the video driver, but the video driver is dynamicly linked to it.? If I > have gotten something wrong, please let me know.? Also, is it a big deal to > just compile all of the drm driver code into the video drivers?? I ask > this, not because I'm trying to change the way you all do things, but only > because I'm trying to find a suitable solution for Syllable. It's been a very long time since I last looked into Syllable, but if I remember things correctly, the setup was something like: 1. Hardware-specific video driver in the kernel 2. Hardware agnostic server in userspace that manages the desktop The Linux setup is like this: 1. Hardware-independent kernel module "drm" 2. Hardware-specific kernel module, e.g. "radeon" 3. Hardware-specific module in the Xserver Since you already have a hardware-specific module in the kernel, I think it's reasonable to merge the hardware-specific parts of the drm into that existing module. After all, when you have two hardware-specific modules in the kernel you only end up having to worry about interface compatibility issues when people run versions of the modules that don't match (alternatively you could force the module versions to be the same, but then why separate things into two different modules in the first place). As for the hardware-independent kernel bits (the "drm" module), perhaps you should think of them not as a driver but as a kind of shared library that contains utility functions for writing a driver? Once you're in that mindset of the "drm" bits being a library, and if the Syllable kernel really doesn't support shared library loading (that's a very odd design decision), you could always build them as a static library that is linked into each of the hardware-specific drivers. So if that was your original question, no, I don't think it's a big deal if that's the way Syllable works. The important thing is that it should be possible to do all this without touching the shared-core directory by putting the Syllable-specific things in their own directory (as is the case for Linux and BSD today). cu, Nicolai - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
OpenGL 3.0 release at siggraph
Hi list! It seems OpenGL 3.0 will be (finally) released at Siggraph! http://www.khronos.org/news/events/detail/siggraph_2008_los_angeles_california// OpenGL BOF SIGGRAPH 2008 | Wednesday, 13 August | 6:00 pm - 8:00 pm | Wilshire Grand Hotel - Wilshire Room OpenGL 3.0 new features Specification ReviewJeremy Sandmel, Apple GLSL 1.3 new features New Shader language definitionBill Licea-Kane, AMD OpenGL 3.0 ISV Perspective Daniel Koch, Transgaming Discussion of benefits OpenGL 3.0 provides ISVs Rob Barris, Blizzard etc.. -- Pasi - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16998] Mesa unichrome (openchrome, chrome, chrome9) driver does not support Compiz
http://bugs.freedesktop.org/show_bug.cgi?id=16998 --- Comment #2 from Michel Dänzer <[EMAIL PROTECTED]> 2008-08-06 02:14:27 PST --- (In reply to comment #1) > > 1) Accelerated copypixels. That shouldn't be necessary with GLX_MESA_copy_sub_buffer. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] DRM question
Am Mittwoch 06 August 2008 02:53:23 schrieb [EMAIL PROTECTED]: > I've been working on a port of DRM for Syllable.? Syllable doesn't support > drivers (or kernel modules) that are on the same level of abstraction & > communicate with each other.? For example our sound card drivers can't > communicate with any other driver normal driver, they can only communicate > with busmanagers (PCI, ISA, etc.).? With this in mind, I've been wondering > what the signifigance of having a drm kernel object that's seperate from > the video driver, but the video driver is dynamicly linked to it.? If I > have gotten something wrong, please let me know.? Also, is it a big deal to > just compile all of the drm driver code into the video drivers?? I ask > this, not because I'm trying to change the way you all do things, but only > because I'm trying to find a suitable solution for Syllable. It's been a very long time since I last looked into Syllable, but if I remember things correctly, the setup was something like: 1. Hardware-specific video driver in the kernel 2. Hardware agnostic server in userspace that manages the desktop The Linux setup is like this: 1. Hardware-independent kernel module "drm" 2. Hardware-specific kernel module, e.g. "radeon" 3. Hardware-specific module in the Xserver Since you already have a hardware-specific module in the kernel, I think it's reasonable to merge the hardware-specific parts of the drm into that existing module. After all, when you have two hardware-specific modules in the kernel you only end up having to worry about interface compatibility issues when people run versions of the modules that don't match (alternatively you could force the module versions to be the same, but then why separate things into two different modules in the first place). As for the hardware-independent kernel bits (the "drm" module), perhaps you should think of them not as a driver but as a kind of shared library that contains utility functions for writing a driver? Once you're in that mindset of the "drm" bits being a library, and if the Syllable kernel really doesn't support shared library loading (that's a very odd design decision), you could always build them as a static library that is linked into each of the hardware-specific drivers. So if that was your original question, no, I don't think it's a big deal if that's the way Syllable works. The important thing is that it should be possible to do all this without touching the shared-core directory by putting the Syllable-specific things in their own directory (as is the case for Linux and BSD today). cu, Nicolai signature.asc Description: This is a digitally signed message part. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
