Re: [R200] Nearly all xscreensavers GL flicker
On Wed, 2005-02-23 at 20:50 +0100, Marcello Maggioni wrote: > > I've a problem with lastest DRI (from CVS) drivers and Xscreensavers > that use OpenGL. > > I've tried nearly all of them , from "Bubble 3D" to "Rubik Cube" all > these simply flicker like hell when are executed . If you're running them manually with -root, it's probably because the root window isn't double buffered. Otherwise, does disabling colour tiling or page flipping make a difference? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Slightly OT: We should move #dri and #dri-devel off of FreeNode
On Wednesday 23 February 2005 12:37 pm, Patrick McFarland wrote: > Unfortunately, yes. And several more have been flooded in the past few > hours. However, I don't think banning Tor (or as lilo puts it, "Temporary > ban") is the answer. It is not up to opers to ban Tor, because channels > themselves can deal with Tor users on their own. Why hamper legit users > when maybe one or two are actually causing problems? Floodbots cause a lot of problems, though. It's not just in the interest of said channels getting flooded, you see. A floodbot on an IRC network creates a lot of waste traffic for all servers which receive the messages those bots send out. A temporary ban is probably the best solution in this case, and while it does hamper a few legitimate users, it also keeps the network afloat. Maybe Tor should look into the problem of malicious users. > imo, Tor is very important for free software. In my opinion, it is very unimportant for free software. It's important for people who can't IRC for whatever reason. Thank you. -- Bryan D. Stine [EMAIL PROTECTED] pgpQr44zlZK8Q.pgp Description: PGP signature
[R200] Nearly all xscreensavers GL flicker
Hi all, I've a problem with lastest DRI (from CVS) drivers and Xscreensavers that use OpenGL. I've tried nearly all of them , from "Bubble 3D" to "Rubik Cube" all these simply flicker like hell when are executed . I don't know why, so I ask you an info about this. Please help :( [EMAIL PROTECTED]:~$ glxinfo 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_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig 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_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 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_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20041207 AGP 4x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.3 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_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_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_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_S3_s3tc glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess 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 . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow [EMAIL PROTECTED]:~$ Bye Marcell
Re: r200 ycbcr
> > however I've just switched it back on and it appears to work for me except > > in the case where I've a client side gart texture and using > > R200_GART_CLIENT_TEXTURES... > Really? I've just tested this again, and the colors in yurrect/yuvsquare are > still completely wrong (rv250). hmm maybe they fixed in on the rv280... I've got an rv250 here somewhere in the stack.. I'll see if I can plug it in later... or maybe I messed up .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 fixed pipeline design
Hi Aapo, I have been thinking about this as well - the current code is just the attempt to get multitexturing working a little bit, apparently there is some info that is missing from r300_reg.h, or perhaps I misunderstood something. With regard to state switching, it might be worth it to simply hash various configuration (fog on /fog off, etc) and just upload state difference on such changes. This would not be too complicated to implement, whatever the mechanism of shader generation. Btw, another interesting link would be: http://ati.com/developer/samples/dx9/FixedFuncShader.html There is even some code to look at. Lastly, if you are in the mood to play with this please do - there is nothing wrong with trying multiple approaches. The important code in R300 driver has already been rewritten several times (AOS code handling, primitive submissions paths, etc) What worked for ATI will not necessarily work for us, as getting the last fps is not as important as having a stable and maintainable driver. Thus we can (and do need to) experiment. best Vladimir Dergachev On Wed, 23 Feb 2005, Aapo Tahkola wrote: Greetings all. I noticed that the code generation for r300 fixed pipeline has just started and decided to start this discussion before the actual implementation gets going at full speed. To cut to the chase, I would like to suggest alternative implementation using mesas struct vertex_program as a placeholder for fragments. As a fragment I mean smallest possible piece of code that can be combined into final program. Some examples could be: directional light, exponental fog, ... http://www.idi.ntnu.no/grupper/su/sif8094-reports/2002/p10.pdf should give you a some idea what I mean. IMO pretty much only benefit that could be achieved by implementing fixed pipeline by using mesas structures and functions is its generality. You could make it run on any chip that supports vertex programs. And I do not only mean full pipeline but just eg. fog. Im pretty founded of the possibility that mesa could implement parts that driver wants as vertex program fallbacks like this. Im not saying that by drivers supporting vertex programs would give it support for these fallbacks as I dont think translation from mesas representation to chip specific form just isnt fast enough for single state changes. Therefore fragments should be translated into form that chip wants only once(during first state change) or upon context creation. Completely different aproach would be to have only one fragment of each type and "call" them to get desired results. However I havent noticed anything in r300 that would even make this even close to possible. Though I think hardware vendors move into that direction sooner or later. -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Slightly OT: We should move #dri and #dri-devel off of FreeNode
On Wednesday 23 February 2005 06:46, Patrick McFarland wrote: > Do we want to use an IRC network that no longer supports freedom? Our only > option is to move to another network, such as irc.noderebellion.net or > irc.oftc.net Congratulations, you win a free procmail rule! - ajax pgpE2NkdByiPU.pgp Description: PGP signature
Re: Slightly OT: We should move #dri and #dri-devel off of FreeNode
Patrick McFarland <[EMAIL PROTECTED]> writes: > banned all Tor users from the FreeNode network. Not good at all. -- Esben Stien is [EMAIL PROTECTED] http://www.esben-stien.name irc://irc.esben-stien.name/%23contact [sip|iax]:[EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Slightly OT: We should move #dri and #dri-devel off of FreeNode
On Wednesday 23 February 2005 11:15 am, Donnie Berkholz wrote: > Patrick McFarland wrote: > > Today lilo (the FreeNode network owner) has decided to make one step away > > in a direction opposite of freedom, and banned all Tor users from the > > FreeNode network. > > > > Tor ( http://tor.eff.org ) is an open source anonymous gateway system. > > Many users who are not in the position to be able to use IRC otherwise > > (such as those who live in countries who do not believe in free speech) > > now cannot use Freenode any longer. > > Were you fortunate enough to be in one of the channels getting spammed > by bots coming from Tor last night? Unfortunately, yes. And several more have been flooded in the past few hours. However, I don't think banning Tor (or as lilo puts it, "Temporary ban") is the answer. It is not up to opers to ban Tor, because channels themselves can deal with Tor users on their own. Why hamper legit users when maybe one or two are actually causing problems? imo, Tor is very important for free software. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpCKw3dhke6u.pgp Description: PGP signature
Re: Slightly OT: We should move #dri and #dri-devel off of FreeNode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick McFarland wrote: > Today lilo (the FreeNode network owner) has decided to make one step away in > a > direction opposite of freedom, and banned all Tor users from the FreeNode > network. > > Tor ( http://tor.eff.org ) is an open source anonymous gateway system. Many > users who are not in the position to be able to use IRC otherwise (such as > those who live in countries who do not believe in free speech) now cannot use > Freenode any longer. Were you fortunate enough to be in one of the channels getting spammed by bots coming from Tor last night? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCHKwSXVaO67S1rtsRAvDmAKCh7alXZCejeMtAcJeNUXzP1qKxzQCdEEDc caCmZeA3Ud89s0hnaLWgvho= =13dF -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xglx and hardware renderers
On Tuesday 22 February 2005 21:06, Ian Romanick wrote: > Alexander E. Patrakov wrote: > > 3) I couldn't start Xglx at 1024x768 with Mesa as of Sunday, Feb 20, 2005 > > with LIBGL_ALWAYS_INDIRECT=1 in the environment. The error is: > > > > X Error of failed request: BadLength (poly request too large or internal > > Xlib length error) > > Major opcode of failed request: 145 (GLX) > > Minor opcode of failed request: 1 (X_GLXRender) > > Serial number of failed request: 85 > > Current serial number in output stream: 86 > > It sounds like there may be a bug in the new GLX protocol code. Can you > generate a debug version of indirect.c and figure out which command > generates the error? To do this, you'll need to cd to src/mesa/glapi > and run the following command. After that, you'll have to rebuild Mesa > with 'linux-dri' or 'linux-dri-x86' or some such. > > python glX_proto_send.py -d -m proto > ../../glx/x11/indirect.c > > You'll need to use LD_PRELOAD to force the use of that libGL. With this > debug libGL, it will log a message before every GL command and do a > glFinish after. The last command logged is likely the one with the bug. I have tried this and got no debugging output at all with Xglx besides the above-mentioned X error. The debugging library by itself works because glxgears now prints a lot of "Enter" and "Exit" debug statements. However, I reproduced the same X error with another (smaller and simpler) app, rendertest_glitz_glx, and got some possibly useful debugging output (pasted below). Enter glGetTexLevelParameteriv... Exit glGetTexLevelParameteriv. Enter glGetTexLevelParameteriv... Exit glGetTexLevelParameteriv. Enter glHint... Exit glHint. Enter glDepthMask... Exit glDepthMask. Enter glPolygonMode... Exit glPolygonMode. Enter glShadeModel... Exit glShadeModel. Enter glColorMask... Exit glColorMask. Enter glGetTexLevelParameteriv... X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 85 Current serial number in output stream: 86 The "glitzinfo" program doesn't report any errors, and results in the same log except that it doesn't enter the glGetTexLevelParameteriv function after glColorMask (that's normal, it's the end of that program) and therefore generates no X errors. I could not reproduce this bug with non-glitz programs. -- Alexander E. Patrakov --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 ycbcr
Dave Airlie wrote: The r200 driver disable ycbcr texturing for non-r200 cards, like my rv280, however I've just switched it back on and it appears to work for me except in the case where I've a client side gart texture and using R200_GART_CLIENT_TEXTURES... Really? I've just tested this again, and the colors in yurrect/yuvsquare are still completely wrong (rv250). Roland --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Slightly OT: We should move #dri and #dri-devel off of FreeNode
Today lilo (the FreeNode network owner) has decided to make one step away in a direction opposite of freedom, and banned all Tor users from the FreeNode network. Tor ( http://tor.eff.org ) is an open source anonymous gateway system. Many users who are not in the position to be able to use IRC otherwise (such as those who live in countries who do not believe in free speech) now cannot use Freenode any longer. Do we want to use an IRC network that no longer supports freedom? Our only option is to move to another network, such as irc.noderebellion.net or irc.oftc.net -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpUkgvLygvVO.pgp Description: PGP signature
r200 ycbcr
The r200 driver disable ycbcr texturing for non-r200 cards, like my rv280, however I've just switched it back on and it appears to work for me except in the case where I've a client side gart texture and using R200_GART_CLIENT_TEXTURES... I'll write a test soon and others can check it out.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 fixed pipeline design
Greetings all. I noticed that the code generation for r300 fixed pipeline has just started and decided to start this discussion before the actual implementation gets going at full speed. To cut to the chase, I would like to suggest alternative implementation using mesas struct vertex_program as a placeholder for fragments. As a fragment I mean smallest possible piece of code that can be combined into final program. Some examples could be: directional light, exponental fog, ... http://www.idi.ntnu.no/grupper/su/sif8094-reports/2002/p10.pdf should give you a some idea what I mean. IMO pretty much only benefit that could be achieved by implementing fixed pipeline by using mesas structures and functions is its generality. You could make it run on any chip that supports vertex programs. And I do not only mean full pipeline but just eg. fog. Im pretty founded of the possibility that mesa could implement parts that driver wants as vertex program fallbacks like this. Im not saying that by drivers supporting vertex programs would give it support for these fallbacks as I dont think translation from mesas representation to chip specific form just isnt fast enough for single state changes. Therefore fragments should be translated into form that chip wants only once(during first state change) or upon context creation. Completely different aproach would be to have only one fragment of each type and "call" them to get desired results. However I havent noticed anything in r300 that would even make this even close to possible. Though I think hardware vendors move into that direction sooner or later. -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
