You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(25) |
Apr
(38) |
May
(9) |
Jun
(39) |
Jul
(64) |
Aug
(73) |
Sep
(86) |
Oct
(91) |
Nov
(112) |
Dec
(90) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(158) |
Feb
(178) |
Mar
(305) |
Apr
(269) |
May
(302) |
Jun
(126) |
Jul
(171) |
Aug
(143) |
Sep
(146) |
Oct
(96) |
Nov
(105) |
Dec
(100) |
2002 |
Jan
(112) |
Feb
(50) |
Mar
(91) |
Apr
(88) |
May
(99) |
Jun
(217) |
Jul
(95) |
Aug
(129) |
Sep
(107) |
Oct
(283) |
Nov
(261) |
Dec
(153) |
2003 |
Jan
(203) |
Feb
(129) |
Mar
(125) |
Apr
(159) |
May
(120) |
Jun
(165) |
Jul
(185) |
Aug
(181) |
Sep
(149) |
Oct
(165) |
Nov
(199) |
Dec
(165) |
2004 |
Jan
(121) |
Feb
(155) |
Mar
(246) |
Apr
(132) |
May
(113) |
Jun
(59) |
Jul
(146) |
Aug
(58) |
Sep
(96) |
Oct
(150) |
Nov
(143) |
Dec
(66) |
2005 |
Jan
(194) |
Feb
(193) |
Mar
(127) |
Apr
(53) |
May
(74) |
Jun
(43) |
Jul
(45) |
Aug
(83) |
Sep
(72) |
Oct
(74) |
Nov
(103) |
Dec
(79) |
2006 |
Jan
(129) |
Feb
(116) |
Mar
(124) |
Apr
(97) |
May
(44) |
Jun
(48) |
Jul
(22) |
Aug
(38) |
Sep
(23) |
Oct
(68) |
Nov
(62) |
Dec
(41) |
2007 |
Jan
(41) |
Feb
(27) |
Mar
(22) |
Apr
(19) |
May
(17) |
Jun
(11) |
Jul
(5) |
Aug
(6) |
Sep
(13) |
Oct
(21) |
Nov
(13) |
Dec
(18) |
2008 |
Jan
(25) |
Feb
(7) |
Mar
(19) |
Apr
|
May
(12) |
Jun
(12) |
Jul
(3) |
Aug
(14) |
Sep
(5) |
Oct
|
Nov
(5) |
Dec
(4) |
2009 |
Jan
|
Feb
(4) |
Mar
|
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(7) |
2010 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
From: Benno S. <ben...@ju...> - 2008-05-08 22:05:36
|
Philipp Klaus Krause wrote: > I tried (as documented in the wiki at > http://dri.freedesktop.org/wiki/TestingAndDebugging) > > export LIBGL_SOFTWARE_RENDERING=1 > glxinfo Try using LIBGL_ALWAYS_INDIRECT=1 instead. Benno |
From: Philipp K. K. <pk...@sp...> - 2008-05-08 18:30:03
|
I tried (as documented in the wiki at http://dri.freedesktop.org/wiki/TestingAndDebugging) export LIBGL_SOFTWARE_RENDERING=1 glxinfo and got OpenGL renderer string: Mesa DRI Intel(R) 965GM 4.1.3002 Philipp |
From: Philipp K. K. <pk...@sp...> - 2008-05-08 18:29:31
|
I tried (as documented in the wiki at http://dri.freedesktop.org/wiki/TestingAndDebugging) export LIBGL_SOFTWARE_RENDERING=1 glxinfo and got OpenGL renderer string: Mesa DRI Intel(R) 965GM 4.1.3002 Philipp |
From: Roland S. <sr...@tu...> - 2008-03-21 13:44:02
|
R. Aditya Kadambi wrote: > Hi; > > I had a question about max texel size on the R200 driver (I am using > 9250 card). Am I correct in assuming from the driver code that the max > texel size is 32 (r200_context.c)? > > I can render a texture with 8 bit image fine but am having some issues > with 16 bit images. Hence the inquiry about the limits. > > If the texel limit is indeed 32 bit for grayscale, is it 8+8+8+8 for RGBA? I am not quite sure what you're looking for. 32bit RGBA textures are certainly not a problem (neither are 16bit RGBA), pretty much only a maximum of 8bit is supported per channel (though the chip could in theory support a 16+16 format too). If you feed the driver formats it doesn't understand it should still work but the data will get converted (see r200_texstate.c to easily see what format your data will end up). Roland |
From: R. A. K. <rak...@gm...> - 2008-03-20 22:39:32
|
Hi; I had a question about max texel size on the R200 driver (I am using 9250 card). Am I correct in assuming from the driver code that the max texel size is 32 (r200_context.c)? I can render a texture with 8 bit image fine but am having some issues with 16 bit images. Hence the inquiry about the limits. If the texel limit is indeed 32 bit for grayscale, is it 8+8+8+8 for RGBA? Thanks, Aditya ---------------------------------------------------------- My glxinfo -l if needed: 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_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer 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_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20060602 AGP 8x TCL OpenGL version string: 1.3 Mesa 7.0.2 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_point_sprite, 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_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_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_fog_coord, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, 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_ATI_fragment_shader, 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_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 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 ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x67 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon |
From: Alex J. <awj...@ho...> - 2008-03-20 05:41:59
|
> Date: Wed, 19 Mar 2008 19:51:57 -0400 > From: ale...@gm... > To: awj...@ho... > Subject: Re: [Dri-users] Visual artifacts on radeon 9500 dri > CC: lr...@cs...; dri...@li... > > On Wed, Mar 19, 2008 at 7:29 PM, Alex Jackson <awj...@ho...> wrote: > > Wouldn't it be better, now that we have those register docs, to get the > > number of working pipes from the card itself (specifically GB_PIPE_SELECT) > > rather than using a list of PCI ids? > > Yes, I'm working on it :) > However, r3xx chips don't have GB_PIPE_SELECT. Only r4xx, rs4xx and r5xx do. Yeah, I just looked at the newly-dropped R300 doc and noticed that there's no sign of that register. I guess that's why the 9500s were easy to "softmod" in Windows, and there's no choice for those cards but to use a list of PCI IDs... According to the R500 doc, it looks like you can just set GB_PIPE_SELECT to the maximum (16 pipes) on all R4xx and R5xx cards and the card will automatically correct it to the actual number of working pipes. Is this right or am I misinterpreting the doc? I guess we'll want to query the card anyway for the real number of working pipes when/if we start tweaking the bits in GB_TILE_CONFIG for performance like the binary drivers (presumably) do. For example it looks like there's a bit in that register that's specific to 12-pipe configurations, and selects one of two ways of splitting the pixels between the three quads, any idea how that works? Is it something like [1][2] [3] versus [1] [2][3] ?? --AWJ-- _________________________________________________________________ Enter today for your chance to win $1000 a day—today until May 12th. Learn more at SignInAndWIN.ca http://g.msn.ca/ca55/215 |
From: Alex D. <ale...@gm...> - 2008-03-19 23:51:59
|
On Wed, Mar 19, 2008 at 7:29 PM, Alex Jackson <awj...@ho...> wrote: > > > Date: Wed, 19 Mar 2008 18:10:43 -0400 > > From: ale...@gm... > > To: lr...@cs... > > CC: dri...@li... > > Subject: Re: [Dri-users] Visual artifacts on radeon 9500 dri > > > > > > On Tue, Mar 18, 2008 at 9:45 AM, Reid Linnemann <lr...@cs...> > wrote: > > > Written by Alex Deucher on 03/18/08 08:39>> > > > > > > > > > > On Tue, Mar 18, 2008 at 9:02 AM, Reid Linnemann <lr...@cs...> > wrote: > > > >> Written by Alex Deucher on 03/17/08 08:18>> > > > >> > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann > <lr...@cs...> wrote: > > > >> >> Written by Alex Deucher on 03/16/08 19:55>> > > > >> >> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann > <lr...@cs...> wrote: > > > >> >> >> Jerome Glisse wrote: > > > >> >> >> > On Sat, 15 Mar 2008 11:00:25 -0500 > > > >> >> >> > Reid Linnemann <lr...@cs...> wrote: > > > >> >> >> > > > > >> >> >> >> Hi list, this is my first time posting and I'm not > subscribed. > > > >> >> >> >> > > > >> >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > > > >> >> >> >> > > > >> >> >> >> Some time ago I noticed that seemingly random pixels were > not being > > > >> >> >> >> rendered in all GL contexts, and simply chalked it up to my > card aging. > > > >> >> >> >> But after a while it started to irk me, and then I > remembered something > > > >> >> >> >> about my sapphire 9500 - it's got one of the chips with 8 > pipelines but > > > >> >> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and > was rebadged > > > >> >> >> >> as a 9500. At one time this card was on a Windows box, and I > tried > > > >> >> >> >> enabling all 8 pipelines with the softmod, and got the > checkerboard > > > >> >> >> >> pattern that indicated this. > > > >> >> >> >> > > > >> >> >> >> With this in mind, I took 10 dumps of a glxgears window and > merged them > > > >> >> >> >> together in a multilayer image in gimp, alternating > multiply/divide, and > > > >> >> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in > the > > > >> >> >> >> checkerboard pattern. I'm now pretty convinced that somehow > either my > > > >> >> >> >> system's DRM module, DRI, or radeon driver are erroneously > enabling all > > > >> >> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. > Anyone have > > > >> >> >> >> any thoughts on this? > > > >> >> >> >> > > > >> >> >> >> I've attached the images with and without the overlaid grid > for reference. > > > >> >> >> >> > > > >> >> >> >> > > > >> >> >> > > > > >> >> >> >>From memory code which detect card model and decide how many > > > >> >> >> > pipe to enable is wrong for many card. We were just > optimistic. > > > >> >> >> > > > > >> >> >> > Cheers, > > > >> >> >> > Jerome Glisse <gl...@fr...> > > > >> >> >> > > > >> >> >> I'd be fine if I knew what code initialized the pipelines, then > I might > > > >> >> >> be able to alter it to my needs. > > > >> >> >> > > > >> >> > > > > >> >> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c > > > >> >> > > > > >> >> > Alex > > > >> >> > > > >> >> FWIW I've tried changing the value of this constant from 3<<1 (or > 6) to > > > >> >> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They > just > > > >> >> appear as flickering holes in the gl context in the same > checkerboard > > > >> >> pattern. Does that mean anything to you? > > > >> > > > > >> > The only valid values for pipe count (bits 3:1) for r3xx chips are > 0 > > > >> > (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The > > > >> > documentation for these chips are available here: > > > >> > > http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf > > > >> > > http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf > > > >> > > > > >> > In your case I suspect you want 0. > > > >> > > > > >> > Alex > > > >> > > > >> That was the ticket. Defining R300_GB_TILE_COUNT as 0 in r300_reg.h > > > >> fixed the tiling issue. Huzzah! > > > >> > > > > > > > > Hey, send me your pci ids so I can push the fix upstream. > > > > > > > > Alex > > > > > > pciconf -lv output: > > > > fix pushed to mesa: 65c4ced1ccea7ff88123296b7f0587faa6f23eef > > Wouldn't it be better, now that we have those register docs, to get the > number of working pipes from the card itself (specifically GB_PIPE_SELECT) > rather than using a list of PCI ids? Yes, I'm working on it :) However, r3xx chips don't have GB_PIPE_SELECT. Only r4xx, rs4xx and r5xx do. Alex |
From: Alex J. <awj...@ho...> - 2008-03-19 23:29:32
|
> Date: Wed, 19 Mar 2008 18:10:43 -0400 > From: ale...@gm... > To: lr...@cs... > CC: dri...@li... > Subject: Re: [Dri-users] Visual artifacts on radeon 9500 dri > > On Tue, Mar 18, 2008 at 9:45 AM, Reid Linnemann <lr...@cs...> wrote: > > Written by Alex Deucher on 03/18/08 08:39>> > > > > > > > On Tue, Mar 18, 2008 at 9:02 AM, Reid Linnemann <lr...@cs...> wrote: > > >> Written by Alex Deucher on 03/17/08 08:18>> > > >> > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lr...@cs...> wrote: > > >> >> Written by Alex Deucher on 03/16/08 19:55>> > > >> >> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: > > >> >> >> Jerome Glisse wrote: > > >> >> >> > On Sat, 15 Mar 2008 11:00:25 -0500 > > >> >> >> > Reid Linnemann <lr...@cs...> wrote: > > >> >> >> > > > >> >> >> >> Hi list, this is my first time posting and I'm not subscribed. > > >> >> >> >> > > >> >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > > >> >> >> >> > > >> >> >> >> Some time ago I noticed that seemingly random pixels were not being > > >> >> >> >> rendered in all GL contexts, and simply chalked it up to my card aging. > > >> >> >> >> But after a while it started to irk me, and then I remembered something > > >> >> >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but > > >> >> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged > > >> >> >> >> as a 9500. At one time this card was on a Windows box, and I tried > > >> >> >> >> enabling all 8 pipelines with the softmod, and got the checkerboard > > >> >> >> >> pattern that indicated this. > > >> >> >> >> > > >> >> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them > > >> >> >> >> together in a multilayer image in gimp, alternating multiply/divide, and > > >> >> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the > > >> >> >> >> checkerboard pattern. I'm now pretty convinced that somehow either my > > >> >> >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all > > >> >> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have > > >> >> >> >> any thoughts on this? > > >> >> >> >> > > >> >> >> >> I've attached the images with and without the overlaid grid for reference. > > >> >> >> >> > > >> >> >> >> > > >> >> >> > > > >> >> >> >>From memory code which detect card model and decide how many > > >> >> >> > pipe to enable is wrong for many card. We were just optimistic. > > >> >> >> > > > >> >> >> > Cheers, > > >> >> >> > Jerome Glisse <gl...@fr...> > > >> >> >> > > >> >> >> I'd be fine if I knew what code initialized the pipelines, then I might > > >> >> >> be able to alter it to my needs. > > >> >> >> > > >> >> > > > >> >> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c > > >> >> > > > >> >> > Alex > > >> >> > > >> >> FWIW I've tried changing the value of this constant from 3<<1 (or 6) to > > >> >> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just > > >> >> appear as flickering holes in the gl context in the same checkerboard > > >> >> pattern. Does that mean anything to you? > > >> > > > >> > The only valid values for pipe count (bits 3:1) for r3xx chips are 0 > > >> > (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The > > >> > documentation for these chips are available here: > > >> > http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf > > >> > http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf > > >> > > > >> > In your case I suspect you want 0. > > >> > > > >> > Alex > > >> > > >> That was the ticket. Defining R300_GB_TILE_COUNT as 0 in r300_reg.h > > >> fixed the tiling issue. Huzzah! > > >> > > > > > > Hey, send me your pci ids so I can push the fix upstream. > > > > > > Alex > > > > pciconf -lv output: > > fix pushed to mesa: 65c4ced1ccea7ff88123296b7f0587faa6f23eef Wouldn't it be better, now that we have those register docs, to get the number of working pipes from the card itself (specifically GB_PIPE_SELECT) rather than using a list of PCI ids? --AWJ-- _________________________________________________________________ Turn every day into $1000. Learn more at SignInAndWIN.ca http://g.msn.ca/ca55/213 |
From: Alex D. <ale...@gm...> - 2008-03-19 22:10:45
|
On Tue, Mar 18, 2008 at 9:45 AM, Reid Linnemann <lr...@cs...> wrote: > Written by Alex Deucher on 03/18/08 08:39>> > > > > On Tue, Mar 18, 2008 at 9:02 AM, Reid Linnemann <lr...@cs...> wrote: > >> Written by Alex Deucher on 03/17/08 08:18>> > >> > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lr...@cs...> wrote: > >> >> Written by Alex Deucher on 03/16/08 19:55>> > >> >> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: > >> >> >> Jerome Glisse wrote: > >> >> >> > On Sat, 15 Mar 2008 11:00:25 -0500 > >> >> >> > Reid Linnemann <lr...@cs...> wrote: > >> >> >> > > >> >> >> >> Hi list, this is my first time posting and I'm not subscribed. > >> >> >> >> > >> >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > >> >> >> >> > >> >> >> >> Some time ago I noticed that seemingly random pixels were not being > >> >> >> >> rendered in all GL contexts, and simply chalked it up to my card aging. > >> >> >> >> But after a while it started to irk me, and then I remembered something > >> >> >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but > >> >> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged > >> >> >> >> as a 9500. At one time this card was on a Windows box, and I tried > >> >> >> >> enabling all 8 pipelines with the softmod, and got the checkerboard > >> >> >> >> pattern that indicated this. > >> >> >> >> > >> >> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them > >> >> >> >> together in a multilayer image in gimp, alternating multiply/divide, and > >> >> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the > >> >> >> >> checkerboard pattern. I'm now pretty convinced that somehow either my > >> >> >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all > >> >> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have > >> >> >> >> any thoughts on this? > >> >> >> >> > >> >> >> >> I've attached the images with and without the overlaid grid for reference. > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> >>From memory code which detect card model and decide how many > >> >> >> > pipe to enable is wrong for many card. We were just optimistic. > >> >> >> > > >> >> >> > Cheers, > >> >> >> > Jerome Glisse <gl...@fr...> > >> >> >> > >> >> >> I'd be fine if I knew what code initialized the pipelines, then I might > >> >> >> be able to alter it to my needs. > >> >> >> > >> >> > > >> >> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c > >> >> > > >> >> > Alex > >> >> > >> >> FWIW I've tried changing the value of this constant from 3<<1 (or 6) to > >> >> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just > >> >> appear as flickering holes in the gl context in the same checkerboard > >> >> pattern. Does that mean anything to you? > >> > > >> > The only valid values for pipe count (bits 3:1) for r3xx chips are 0 > >> > (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The > >> > documentation for these chips are available here: > >> > http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf > >> > http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf > >> > > >> > In your case I suspect you want 0. > >> > > >> > Alex > >> > >> That was the ticket. Defining R300_GB_TILE_COUNT as 0 in r300_reg.h > >> fixed the tiling issue. Huzzah! > >> > > > > Hey, send me your pci ids so I can push the fix upstream. > > > > Alex > > pciconf -lv output: fix pushed to mesa: 65c4ced1ccea7ff88123296b7f0587faa6f23eef Thanks! Alex > > vgapci0@pci0:1:0:0: class=0x030000 card=0x00021002 chip=0x41441002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon 9500 Series (R300)' > class = display > subclass = VGA > vgapci1@pci0:1:0:1: class=0x038000 card=0x00031002 chip=0x41641002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon 9500 Series, secondary R300 (128bit mem bus)' > class = display > |
From: Reid L. <lr...@cs...> - 2008-03-18 13:46:08
|
Written by Alex Deucher on 03/18/08 08:39>> > On Tue, Mar 18, 2008 at 9:02 AM, Reid Linnemann <lr...@cs...> wrote: >> Written by Alex Deucher on 03/17/08 08:18>> >> > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lr...@cs...> wrote: >> >> Written by Alex Deucher on 03/16/08 19:55>> >> >> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: >> >> >> Jerome Glisse wrote: >> >> >> > On Sat, 15 Mar 2008 11:00:25 -0500 >> >> >> > Reid Linnemann <lr...@cs...> wrote: >> >> >> > >> >> >> >> Hi list, this is my first time posting and I'm not subscribed. >> >> >> >> >> >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. >> >> >> >> >> >> >> >> Some time ago I noticed that seemingly random pixels were not being >> >> >> >> rendered in all GL contexts, and simply chalked it up to my card aging. >> >> >> >> But after a while it started to irk me, and then I remembered something >> >> >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but >> >> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged >> >> >> >> as a 9500. At one time this card was on a Windows box, and I tried >> >> >> >> enabling all 8 pipelines with the softmod, and got the checkerboard >> >> >> >> pattern that indicated this. >> >> >> >> >> >> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them >> >> >> >> together in a multilayer image in gimp, alternating multiply/divide, and >> >> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the >> >> >> >> checkerboard pattern. I'm now pretty convinced that somehow either my >> >> >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all >> >> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have >> >> >> >> any thoughts on this? >> >> >> >> >> >> >> >> I've attached the images with and without the overlaid grid for reference. >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >>From memory code which detect card model and decide how many >> >> >> > pipe to enable is wrong for many card. We were just optimistic. >> >> >> > >> >> >> > Cheers, >> >> >> > Jerome Glisse <gl...@fr...> >> >> >> >> >> >> I'd be fine if I knew what code initialized the pipelines, then I might >> >> >> be able to alter it to my needs. >> >> >> >> >> > >> >> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c >> >> > >> >> > Alex >> >> >> >> FWIW I've tried changing the value of this constant from 3<<1 (or 6) to >> >> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just >> >> appear as flickering holes in the gl context in the same checkerboard >> >> pattern. Does that mean anything to you? >> > >> > The only valid values for pipe count (bits 3:1) for r3xx chips are 0 >> > (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The >> > documentation for these chips are available here: >> > http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf >> > http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf >> > >> > In your case I suspect you want 0. >> > >> > Alex >> >> That was the ticket. Defining R300_GB_TILE_COUNT as 0 in r300_reg.h >> fixed the tiling issue. Huzzah! >> > > Hey, send me your pci ids so I can push the fix upstream. > > Alex pciconf -lv output: vgapci0@pci0:1:0:0: class=0x030000 card=0x00021002 chip=0x41441002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon 9500 Series (R300)' class = display subclass = VGA vgapci1@pci0:1:0:1: class=0x038000 card=0x00031002 chip=0x41641002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon 9500 Series, secondary R300 (128bit mem bus)' class = display |
From: Alex D. <ale...@gm...> - 2008-03-18 13:39:54
|
On Tue, Mar 18, 2008 at 9:02 AM, Reid Linnemann <lr...@cs...> wrote: > Written by Alex Deucher on 03/17/08 08:18>> > > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lr...@cs...> wrote: > >> Written by Alex Deucher on 03/16/08 19:55>> > >> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: > >> >> Jerome Glisse wrote: > >> >> > On Sat, 15 Mar 2008 11:00:25 -0500 > >> >> > Reid Linnemann <lr...@cs...> wrote: > >> >> > > >> >> >> Hi list, this is my first time posting and I'm not subscribed. > >> >> >> > >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > >> >> >> > >> >> >> Some time ago I noticed that seemingly random pixels were not being > >> >> >> rendered in all GL contexts, and simply chalked it up to my card aging. > >> >> >> But after a while it started to irk me, and then I remembered something > >> >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but > >> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged > >> >> >> as a 9500. At one time this card was on a Windows box, and I tried > >> >> >> enabling all 8 pipelines with the softmod, and got the checkerboard > >> >> >> pattern that indicated this. > >> >> >> > >> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them > >> >> >> together in a multilayer image in gimp, alternating multiply/divide, and > >> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the > >> >> >> checkerboard pattern. I'm now pretty convinced that somehow either my > >> >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all > >> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have > >> >> >> any thoughts on this? > >> >> >> > >> >> >> I've attached the images with and without the overlaid grid for reference. > >> >> >> > >> >> >> > >> >> > > >> >> >>From memory code which detect card model and decide how many > >> >> > pipe to enable is wrong for many card. We were just optimistic. > >> >> > > >> >> > Cheers, > >> >> > Jerome Glisse <gl...@fr...> > >> >> > >> >> I'd be fine if I knew what code initialized the pipelines, then I might > >> >> be able to alter it to my needs. > >> >> > >> > > >> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c > >> > > >> > Alex > >> > >> FWIW I've tried changing the value of this constant from 3<<1 (or 6) to > >> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just > >> appear as flickering holes in the gl context in the same checkerboard > >> pattern. Does that mean anything to you? > > > > The only valid values for pipe count (bits 3:1) for r3xx chips are 0 > > (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The > > documentation for these chips are available here: > > http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf > > http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf > > > > In your case I suspect you want 0. > > > > Alex > > That was the ticket. Defining R300_GB_TILE_COUNT as 0 in r300_reg.h > fixed the tiling issue. Huzzah! > Hey, send me your pci ids so I can push the fix upstream. Alex |
From: Reid L. <lr...@cs...> - 2008-03-18 13:02:39
|
Written by Alex Deucher on 03/17/08 08:18>> > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lr...@cs...> wrote: >> Written by Alex Deucher on 03/16/08 19:55>> >> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: >> >> Jerome Glisse wrote: >> >> > On Sat, 15 Mar 2008 11:00:25 -0500 >> >> > Reid Linnemann <lr...@cs...> wrote: >> >> > >> >> >> Hi list, this is my first time posting and I'm not subscribed. >> >> >> >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. >> >> >> >> >> >> Some time ago I noticed that seemingly random pixels were not being >> >> >> rendered in all GL contexts, and simply chalked it up to my card aging. >> >> >> But after a while it started to irk me, and then I remembered something >> >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but >> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged >> >> >> as a 9500. At one time this card was on a Windows box, and I tried >> >> >> enabling all 8 pipelines with the softmod, and got the checkerboard >> >> >> pattern that indicated this. >> >> >> >> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them >> >> >> together in a multilayer image in gimp, alternating multiply/divide, and >> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the >> >> >> checkerboard pattern. I'm now pretty convinced that somehow either my >> >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all >> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have >> >> >> any thoughts on this? >> >> >> >> >> >> I've attached the images with and without the overlaid grid for reference. >> >> >> >> >> >> >> >> > >> >> >>From memory code which detect card model and decide how many >> >> > pipe to enable is wrong for many card. We were just optimistic. >> >> > >> >> > Cheers, >> >> > Jerome Glisse <gl...@fr...> >> >> >> >> I'd be fine if I knew what code initialized the pipelines, then I might >> >> be able to alter it to my needs. >> >> >> > >> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c >> > >> > Alex >> >> FWIW I've tried changing the value of this constant from 3<<1 (or 6) to >> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just >> appear as flickering holes in the gl context in the same checkerboard >> pattern. Does that mean anything to you? > > The only valid values for pipe count (bits 3:1) for r3xx chips are 0 > (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The > documentation for these chips are available here: > http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf > http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf > > In your case I suspect you want 0. > > Alex That was the ticket. Defining R300_GB_TILE_COUNT as 0 in r300_reg.h fixed the tiling issue. Huzzah! |
From: Roland S. <sr...@tu...> - 2008-03-17 15:54:25
|
Reid Linnemann wrote: > Written by Alex Deucher on 03/17/08 08:18>> >> On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lr...@cs...> wrote: >>> Written by Alex Deucher on 03/16/08 19:55>> >>> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: >>> >> Jerome Glisse wrote: >>> >> > On Sat, 15 Mar 2008 11:00:25 -0500 >>> >> > Reid Linnemann <lr...@cs...> wrote: >>> >> > >>> >> >> Hi list, this is my first time posting and I'm not subscribed. >>> >> >> >>> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. >>> >> >> >>> >> >> Some time ago I noticed that seemingly random pixels were not being >>> >> >> rendered in all GL contexts, and simply chalked it up to my card aging. >>> >> >> But after a while it started to irk me, and then I remembered something >>> >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but >>> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged >>> >> >> as a 9500. At one time this card was on a Windows box, and I tried >>> >> >> enabling all 8 pipelines with the softmod, and got the checkerboard >>> >> >> pattern that indicated this. >>> >> >> >>> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them >>> >> >> together in a multilayer image in gimp, alternating multiply/divide, and >>> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the >>> >> >> checkerboard pattern. I'm now pretty convinced that somehow either my >>> >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all >>> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have >>> >> >> any thoughts on this? >>> >> >> >>> >> >> I've attached the images with and without the overlaid grid for reference. >>> >> >> >>> >> >> >>> >> > >>> >> >>From memory code which detect card model and decide how many >>> >> > pipe to enable is wrong for many card. We were just optimistic. >>> >> > >>> >> > Cheers, >>> >> > Jerome Glisse <gl...@fr...> >>> >> >>> >> I'd be fine if I knew what code initialized the pipelines, then I might >>> >> be able to alter it to my needs. >>> >> >>> > >>> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c >>> > >>> > Alex >>> >>> FWIW I've tried changing the value of this constant from 3<<1 (or 6) to >>> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just >>> appear as flickering holes in the gl context in the same checkerboard >>> pattern. Does that mean anything to you? >> The only valid values for pipe count (bits 3:1) for r3xx chips are 0 >> (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The >> documentation for these chips are available here: >> http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf >> http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf >> >> In your case I suspect you want 0. >> >> Alex > > > Ah, I see. I wondered why the tile pipe count constants were specified > as left-shifted values, I never considered that they were a value in a > bitfield. I'll try that out tonight. > > On further investigation, this really makes sense. Looking at > ati.amd.com, the 9500 isn't even listed in discontinued products - like > they want to pretend it never existed. The 9600, with the rv350 chipset, > has half the pipes of a real r300 chip, and the rv350 tile count value > is 0. I hadn't even considered that. > > Thanks for the help, and for the doc links. This will be good nightstand > reading for a while. If I remember correctly, there was another issue with the r300 chip (and the docs might not tell), it couldn't use hierarchical-z if only 1 pipe was activated due to the way this was coupled to the different pipes. Doesn't look like it gets enabled with the current driver however, so shouldn't be a problem. Roland |
From: Reid L. <lr...@cs...> - 2008-03-17 15:10:42
|
Written by Alex Deucher on 03/17/08 08:18>> > On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lr...@cs...> wrote: >> Written by Alex Deucher on 03/16/08 19:55>> >> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: >> >> Jerome Glisse wrote: >> >> > On Sat, 15 Mar 2008 11:00:25 -0500 >> >> > Reid Linnemann <lr...@cs...> wrote: >> >> > >> >> >> Hi list, this is my first time posting and I'm not subscribed. >> >> >> >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. >> >> >> >> >> >> Some time ago I noticed that seemingly random pixels were not being >> >> >> rendered in all GL contexts, and simply chalked it up to my card aging. >> >> >> But after a while it started to irk me, and then I remembered something >> >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but >> >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged >> >> >> as a 9500. At one time this card was on a Windows box, and I tried >> >> >> enabling all 8 pipelines with the softmod, and got the checkerboard >> >> >> pattern that indicated this. >> >> >> >> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them >> >> >> together in a multilayer image in gimp, alternating multiply/divide, and >> >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the >> >> >> checkerboard pattern. I'm now pretty convinced that somehow either my >> >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all >> >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have >> >> >> any thoughts on this? >> >> >> >> >> >> I've attached the images with and without the overlaid grid for reference. >> >> >> >> >> >> >> >> > >> >> >>From memory code which detect card model and decide how many >> >> > pipe to enable is wrong for many card. We were just optimistic. >> >> > >> >> > Cheers, >> >> > Jerome Glisse <gl...@fr...> >> >> >> >> I'd be fine if I knew what code initialized the pipelines, then I might >> >> be able to alter it to my needs. >> >> >> > >> > search for R300_GB_TILE_PIPE_COUNT in r300_state.c >> > >> > Alex >> >> FWIW I've tried changing the value of this constant from 3<<1 (or 6) to >> 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just >> appear as flickering holes in the gl context in the same checkerboard >> pattern. Does that mean anything to you? > > The only valid values for pipe count (bits 3:1) for r3xx chips are 0 > (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The > documentation for these chips are available here: > http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf > http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf > > In your case I suspect you want 0. > > Alex Ah, I see. I wondered why the tile pipe count constants were specified as left-shifted values, I never considered that they were a value in a bitfield. I'll try that out tonight. On further investigation, this really makes sense. Looking at ati.amd.com, the 9500 isn't even listed in discontinued products - like they want to pretend it never existed. The 9600, with the rv350 chipset, has half the pipes of a real r300 chip, and the rv350 tile count value is 0. I hadn't even considered that. Thanks for the help, and for the doc links. This will be good nightstand reading for a while. |
From: Alex D. <ale...@gm...> - 2008-03-17 13:18:11
|
On Mon, Mar 17, 2008 at 9:08 AM, Reid Linnemann <lr...@cs...> wrote: > Written by Alex Deucher on 03/16/08 19:55>> > > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: > >> Jerome Glisse wrote: > >> > On Sat, 15 Mar 2008 11:00:25 -0500 > >> > Reid Linnemann <lr...@cs...> wrote: > >> > > >> >> Hi list, this is my first time posting and I'm not subscribed. > >> >> > >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > >> >> > >> >> Some time ago I noticed that seemingly random pixels were not being > >> >> rendered in all GL contexts, and simply chalked it up to my card aging. > >> >> But after a while it started to irk me, and then I remembered something > >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but > >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged > >> >> as a 9500. At one time this card was on a Windows box, and I tried > >> >> enabling all 8 pipelines with the softmod, and got the checkerboard > >> >> pattern that indicated this. > >> >> > >> >> With this in mind, I took 10 dumps of a glxgears window and merged them > >> >> together in a multilayer image in gimp, alternating multiply/divide, and > >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the > >> >> checkerboard pattern. I'm now pretty convinced that somehow either my > >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all > >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have > >> >> any thoughts on this? > >> >> > >> >> I've attached the images with and without the overlaid grid for reference. > >> >> > >> >> > >> > > >> >>From memory code which detect card model and decide how many > >> > pipe to enable is wrong for many card. We were just optimistic. > >> > > >> > Cheers, > >> > Jerome Glisse <gl...@fr...> > >> > >> I'd be fine if I knew what code initialized the pipelines, then I might > >> be able to alter it to my needs. > >> > > > > search for R300_GB_TILE_PIPE_COUNT in r300_state.c > > > > Alex > > FWIW I've tried changing the value of this constant from 3<<1 (or 6) to > 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just > appear as flickering holes in the gl context in the same checkerboard > pattern. Does that mean anything to you? The only valid values for pipe count (bits 3:1) for r3xx chips are 0 (RV3xx chips - 1 pipe) and 3 (R3xx chips - 2 pipes). The documentation for these chips are available here: http://ati.amd.com/developer/open_gpu_documentation/R3xx_3D_Registers.pdf http://ati.amd.com/developer/open_gpu_documentation/R5xx_Acceleration_v1.2.pdf In your case I suspect you want 0. Alex |
From: Reid L. <lr...@cs...> - 2008-03-17 13:08:27
|
Written by Alex Deucher on 03/16/08 19:55>> > On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: >> Jerome Glisse wrote: >> > On Sat, 15 Mar 2008 11:00:25 -0500 >> > Reid Linnemann <lr...@cs...> wrote: >> > >> >> Hi list, this is my first time posting and I'm not subscribed. >> >> >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. >> >> >> >> Some time ago I noticed that seemingly random pixels were not being >> >> rendered in all GL contexts, and simply chalked it up to my card aging. >> >> But after a while it started to irk me, and then I remembered something >> >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but >> >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged >> >> as a 9500. At one time this card was on a Windows box, and I tried >> >> enabling all 8 pipelines with the softmod, and got the checkerboard >> >> pattern that indicated this. >> >> >> >> With this in mind, I took 10 dumps of a glxgears window and merged them >> >> together in a multilayer image in gimp, alternating multiply/divide, and >> >> overlaid a 16x16 grid. The artifacting lined up perfectly in the >> >> checkerboard pattern. I'm now pretty convinced that somehow either my >> >> system's DRM module, DRI, or radeon driver are erroneously enabling all >> >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have >> >> any thoughts on this? >> >> >> >> I've attached the images with and without the overlaid grid for reference. >> >> >> >> >> > >> >>From memory code which detect card model and decide how many >> > pipe to enable is wrong for many card. We were just optimistic. >> > >> > Cheers, >> > Jerome Glisse <gl...@fr...> >> >> I'd be fine if I knew what code initialized the pipelines, then I might >> be able to alter it to my needs. >> > > search for R300_GB_TILE_PIPE_COUNT in r300_state.c > > Alex FWIW I've tried changing the value of this constant from 3<<1 (or 6) to 2<<1 (or 4), but the bad tiles persist - only unrendered to. They just appear as flickering holes in the gl context in the same checkerboard pattern. Does that mean anything to you? Thanks, Reid |
From: Alex D. <ale...@gm...> - 2008-03-17 00:56:02
|
On Sun, Mar 16, 2008 at 8:49 PM, Reid Linnemann <lr...@cs...> wrote: > Jerome Glisse wrote: > > On Sat, 15 Mar 2008 11:00:25 -0500 > > Reid Linnemann <lr...@cs...> wrote: > > > >> Hi list, this is my first time posting and I'm not subscribed. > >> > >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > >> > >> Some time ago I noticed that seemingly random pixels were not being > >> rendered in all GL contexts, and simply chalked it up to my card aging. > >> But after a while it started to irk me, and then I remembered something > >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but > >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged > >> as a 9500. At one time this card was on a Windows box, and I tried > >> enabling all 8 pipelines with the softmod, and got the checkerboard > >> pattern that indicated this. > >> > >> With this in mind, I took 10 dumps of a glxgears window and merged them > >> together in a multilayer image in gimp, alternating multiply/divide, and > >> overlaid a 16x16 grid. The artifacting lined up perfectly in the > >> checkerboard pattern. I'm now pretty convinced that somehow either my > >> system's DRM module, DRI, or radeon driver are erroneously enabling all > >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have > >> any thoughts on this? > >> > >> I've attached the images with and without the overlaid grid for reference. > >> > >> > > > >>From memory code which detect card model and decide how many > > pipe to enable is wrong for many card. We were just optimistic. > > > > Cheers, > > Jerome Glisse <gl...@fr...> > > I'd be fine if I knew what code initialized the pipelines, then I might > be able to alter it to my needs. > search for R300_GB_TILE_PIPE_COUNT in r300_state.c Alex |
From: Reid L. <lr...@cs...> - 2008-03-17 00:50:09
|
Jerome Glisse wrote: > On Sat, 15 Mar 2008 11:00:25 -0500 > Reid Linnemann <lr...@cs...> wrote: > >> Hi list, this is my first time posting and I'm not subscribed. >> >> I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. >> >> Some time ago I noticed that seemingly random pixels were not being >> rendered in all GL contexts, and simply chalked it up to my card aging. >> But after a while it started to irk me, and then I remembered something >> about my sapphire 9500 - it's got one of the chips with 8 pipelines but >> only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged >> as a 9500. At one time this card was on a Windows box, and I tried >> enabling all 8 pipelines with the softmod, and got the checkerboard >> pattern that indicated this. >> >> With this in mind, I took 10 dumps of a glxgears window and merged them >> together in a multilayer image in gimp, alternating multiply/divide, and >> overlaid a 16x16 grid. The artifacting lined up perfectly in the >> checkerboard pattern. I'm now pretty convinced that somehow either my >> system's DRM module, DRI, or radeon driver are erroneously enabling all >> 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have >> any thoughts on this? >> >> I've attached the images with and without the overlaid grid for reference. >> >> > >>From memory code which detect card model and decide how many > pipe to enable is wrong for many card. We were just optimistic. > > Cheers, > Jerome Glisse <gl...@fr...> I'd be fine if I knew what code initialized the pipelines, then I might be able to alter it to my needs. |
From: Alex D. <ale...@gm...> - 2008-03-17 00:48:03
|
On Sun, Mar 16, 2008 at 7:55 PM, Jerome Glisse <gl...@fr...> wrote: > > On Sat, 15 Mar 2008 11:00:25 -0500 > Reid Linnemann <lr...@cs...> wrote: > > > Hi list, this is my first time posting and I'm not subscribed. > > > > I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > > > > Some time ago I noticed that seemingly random pixels were not being > > rendered in all GL contexts, and simply chalked it up to my card aging. > > But after a while it started to irk me, and then I remembered something > > about my sapphire 9500 - it's got one of the chips with 8 pipelines but > > only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged > > as a 9500. At one time this card was on a Windows box, and I tried > > enabling all 8 pipelines with the softmod, and got the checkerboard > > pattern that indicated this. > > > > With this in mind, I took 10 dumps of a glxgears window and merged them > > together in a multilayer image in gimp, alternating multiply/divide, and > > overlaid a 16x16 grid. The artifacting lined up perfectly in the > > checkerboard pattern. I'm now pretty convinced that somehow either my > > system's DRM module, DRI, or radeon driver are erroneously enabling all > > 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have > > any thoughts on this? > > > > I've attached the images with and without the overlaid grid for reference. > > > > > > >From memory code which detect card model and decide how many > pipe to enable is wrong for many card. We were just optimistic. > There is a way to detect bad pipes and the proper number of pipes to enable per-card, but It hasn't been implemented yet. I'll try and dig up what we need. Alex |
From: Jerome G. <gl...@fr...> - 2008-03-16 23:55:47
|
On Sat, 15 Mar 2008 11:00:25 -0500 Reid Linnemann <lr...@cs...> wrote: > Hi list, this is my first time posting and I'm not subscribed. > > I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. > > Some time ago I noticed that seemingly random pixels were not being > rendered in all GL contexts, and simply chalked it up to my card aging. > But after a while it started to irk me, and then I remembered something > about my sapphire 9500 - it's got one of the chips with 8 pipelines but > only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged > as a 9500. At one time this card was on a Windows box, and I tried > enabling all 8 pipelines with the softmod, and got the checkerboard > pattern that indicated this. > > With this in mind, I took 10 dumps of a glxgears window and merged them > together in a multilayer image in gimp, alternating multiply/divide, and > overlaid a 16x16 grid. The artifacting lined up perfectly in the > checkerboard pattern. I'm now pretty convinced that somehow either my > system's DRM module, DRI, or radeon driver are erroneously enabling all > 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have > any thoughts on this? > > I've attached the images with and without the overlaid grid for reference. > > >From memory code which detect card model and decide how many pipe to enable is wrong for many card. We were just optimistic. Cheers, Jerome Glisse <gl...@fr...> |
From: Reid L. <lr...@cs...> - 2008-03-15 16:01:23
|
Reid Linnemann wrote: > Hi list, this is my first time posting and I'm not subscribed. > Correction, I have subscribed =) |
From: Reid L. <lr...@cs...> - 2008-03-15 16:00:38
|
Hi list, this is my first time posting and I'm not subscribed. I'm running Xorg 7.3 with dri on FreeBSD 7-STABLE. Some time ago I noticed that seemingly random pixels were not being rendered in all GL contexts, and simply chalked it up to my card aging. But after a while it started to irk me, and then I remembered something about my sapphire 9500 - it's got one of the chips with 8 pipelines but only 4 enabled, presumably a 9700 that didn't pass QA and was rebadged as a 9500. At one time this card was on a Windows box, and I tried enabling all 8 pipelines with the softmod, and got the checkerboard pattern that indicated this. With this in mind, I took 10 dumps of a glxgears window and merged them together in a multilayer image in gimp, alternating multiply/divide, and overlaid a 16x16 grid. The artifacting lined up perfectly in the checkerboard pattern. I'm now pretty convinced that somehow either my system's DRM module, DRI, or radeon driver are erroneously enabling all 8 pipelines on the card, resulting in mooky-stink rendering. Anyone have any thoughts on this? I've attached the images with and without the overlaid grid for reference. |
From: Fred S. <fre...@ya...> - 2008-02-25 15:29:52
|
Hi Vince, OK for the specs, here it goes: - Sony VAIO PCG-FX 602 laptop, Mobile AMD Duron 1,1 GHz (poor 64 Ko L2 Cache), 256 Mo SDRAM (133MHz) brought up to 512 on a VIA KT133A chipset, PhoenixBIOS R0121K5, HDD IBM 20 Go 32 Bits, UDMA 5 and SMART enabled. The detailed specs can be found on this Debian / Woody installation how-to: http://www.michael-prokop.at/computer/sony.html the chipset here: http://www.via.com.tw/en/products/chipsets/legacy/kt133a/ scanpci gives "pci bus 0x0001 device 0x4c4d ATI Rage Mobility P/M AGP 2X" (same result by www.pcidatabase.com) so here the specs: http://ati.de/companyinfo/press/2000/4296.html and http://support.packardbell.com/fr/item/index.php?i=spec_AtiMobilityM1_4MB_AGPπ=platform_J4 The difference between M and M1 is 4 Mo and 8 Mo graphic RAM and it's sad to know that the KT133A chipset can handle AGP 4X, but that's life = ; ) - Xorg.0.log gives 8192 kB of SDRAM - The monitor utility of Ubuntu shows model "Plug 'n' Play", resolution "1024x768" at "85 Hz", I want to believe it... - The default mode is 1024x768 in 16 bits (24 gives just 180 fps...), Synaptic touchpad correctly works without help, the only changes in xorg.conf are the ones I needed to load the Mach64 DRM module and get the DRI working, then to disable AIGLX and Composite, which are too hungry for our old Rage = : ( - Same OpenGL renderer string as you, OpenGL version 1.2 Mesa 7.0.1 here. By the way, using export LIBGL_DEBUG=verbose shows me 2 drirc files missing errors (/etc/drirc and ~/.drirc). To get rid of those, installing driconf, running it in user and then as root created both files and that was done. It's more a bug than a real error: http://www.mail-archive.com/dri...@li.../msg21945.html and this is what it is: http://dri.freedesktop.org/wiki/ConfigurationInfrastructure Some other stuff: - Fresh install of standard Ubuntu Gutsy, kernel 2.6.22-14-generic for x86, Ethernet 100, AC97 sound, Function Keys, PowerNow and Suspend -to Ram and -to Disk working out of the box. Thanks acpid you can suspend the baby by closing the lid, what is really cool = : ) - Firewire, parallel and serial port not used for now and therefore not tested. I can't get an USB mouse working on the same time than the touchpad, but I don't use it anyway, so I don't go further. - A PCMCIA USB 2.0 card with NEC chipset works out of the box, with an extra energy cable (and NOT without) and makes no trouble to suspend. - A few services disabled (as I don't need Avahi, Bluetooth or CUPS on this system), top shows 92 Tasks, 1 or 2 running when idle and 180 Mo SDRAM free after booting. But I didn't noticed any changes regarding glxgears results in this aspect. - No boot parameters, personal scripts or special configuration, I've only corrected my DSDT table for ACPI with iasl and and rebuild my initramfs to use it (it changes nothing in glxgears). Suspend worked already before, I hope it helps to check better the battery, which last at best 15 minutes = : ( - The boot Splash screen didn't showed up, it was wrongly set in /etc/ usplash.conf at 1280x1024, not 1024x768. This has also slowed down the boot process. It can be change by correcting it and rebuilding the initramfs, or more easily with installing startupmanager. Choosing 8 bits is enough to be nice. So, I hope it can be useful to someone... Regards, FSW _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr |
From: Vince S. <hli...@ya...> - 2008-02-24 17:29:33
|
Hello: I'm curious (and a little jealous): I got direct rendering with a maximum of ~220 FPS (increase from ~80 FPS before DRI) with this mach64 driver. But glxgears is not a good benchmark tool. I would like to know your system specs and video settings so that we can compare results/performance. Here are my specs: Machine #1: > micron.pc ClientPro CN, Pentium III (Coppermine, ~800MHz), 384 MB RAM, 3D Rage Pro AGP 1X/2X (Rage Pro AIW AGP 2X PCI card, 8 MB SGRAM), full specs: http://smolt.fedoraproject.org/client/show_all?uuid=pub_136d9c2b-6c5c-4414-9069-040715716a4c; > Screen resolution 1024 x 768 @ 60 Hz, Color Depth 16 bpp; > Fedora 7, kernel 2.6.23.15-80.fc7.i386; > glxinfo: Direct rendering: Yes; OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE; > glxgears ~220 FPS. Machine #2: > emachines etower 466id, Celeron (Mendocino, ~466 MHz), 256 MB RAM, 3D Rage Pro AGP 1X/2X (Rage Pro Turbo AGP 2X on-board, 4 MB SGRAM), full specs: http://smolt.fedoraproject.org/client/show_all?uuid=pub_4caba599-039f-4ac7-ae9a-d03c56e839b3; > Screen resolution 800 x 600 @ 85 Hz, Color Depth 16 bpp; > Fedora 7, kernel 2.6.23.15-80.fc7.i386; > glxinfo: Direct rendering: Yes; OpenGL renderer string: Mesa DRI Mach64 [Rage Pro] 20051019 AGP 2x x86/MMX/SSE; > glxgears ~220 FPS. Maybe it will help the developers also if they can see some performance results.... Many thanx again to George F. for his help on getting this to work. Thanx and Regards, VJS "I may detest what you say, but I will defend to the death your right to say it." EB Hall, "Friends of Voltaire", 1906 ----- Original Message ---- From: "dri...@li..." <dri...@li...> To: dri...@li... Sent: Sunday, February 24, 2008 6:14:08 AM Subject: Dri-users Digest, Vol 21, Issue 1 Send Dri-users mailing list submissions to dri...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dri-users or, via email, send a message with subject or body 'help' to dri...@li... You can reach the person managing the list at dri...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Dri-users digest..." Today's Topics: 1. Re: mach64 driver (George -) 2. mach64 - dri2 trouble (Fred Scali) 3. Re: mach64 - dri2 trouble (George -) 4. mach64 - dri2 trouble (Fred Scali) [...] Restart X et voila: Direct Rendering: Yes and glxgears around 300 fps (the best this card can make...) = : ) = : ) = : ) This could work for others distributions, if not, one can try to found which part is too old / to new or try to make the Mesa part, but with a version older than the 02/15/2008, when the DRI2 was commited. Or wait that the bug is solved... Regards to all the dri-users. FSW Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail -----Inline Attachment Follows----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Dri-users mailing list Dri...@li... https://lists.sourceforge.net/lists/listinfo/dri-users ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs |
From: Fred S. <fre...@ya...> - 2008-02-24 11:14:07
|
Hi, just a word to say George is right! (Thank you again, George) On a fresh Ubuntu Gutsy, you just have to get the necessary packages like this: sudo apt-get install git-core autoconf automake libtool (that bring 6 other needed packages with) then git clone git://anongit.freedesktop.org/git/mesa/drm then cd drm/linux-core make DRM_MODULES="mach64" (you don't need the others modules and a new drm.ko is automatically made) then sudo cp *.ko /lib/modules/(uname -r)/kernel/drivers/char/drm (that will copy mach64.ko AND the new drm.ko -save before the old drm.ko if you are anxious = ; ) and at last sudo depmod -a Now, save a copy of your xorg.conf and edit it likes this: #load the modules Section "Module" Load "glx" Load "dri" EndSection #allow all users Section "DRI" Mode 0666 EndSection #disable AIGLX and Composite (this card CAN'T handle it correctly!!!) Section "ServerFlags" Option "AIGLX" "off" EndSection Section "Extensions" Option "Composite" "Disable" EndSection Restart X et voila: Direct Rendering: Yes and glxgears around 300 fps (the best this card can make...) = : ) = : ) = : ) This could work for others distributions, if not, one can try to found which part is too old / to new or try to make the Mesa part, but with a version older than the 02/15/2008, when the DRI2 was commited. Or wait that the bug is solved... Regards to all the dri-users. FSW _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr |