From: Keith C. <kc...@pi...> - 2005-01-05 20:21:33
|
Hi, I was able to compile the latest r300_driver as of this writing. glxgears now gets ~650fps but the actual image is drawn below the window. I also tried a couple NeHe demos and the show the same drwaing problem. I took a screenshot of the problem http://pimpstation.org/Screenshot.png . One question I had was did I only need to build r300_dri.so or all of Mesa? The README wasn't clear so I only copied the dri driver into X. My machine: Ubuntu 4.10 Powerbook 15" 1Ghz RV350 [Mobility Radeon 9600 M10] Thanks, -- -------- Keith Conger Kei...@gm... http://pimpstation.org |
From: Jerome G. <j.g...@fr...> - 2005-01-06 18:00:43
|
Keith Conger wrote: >Hi, > >I was able to compile the latest r300_driver as of this writing. >glxgears now gets ~650fps but the actual image is drawn below the >window. I also tried a couple NeHe demos and the show the same drwaing >problem. I took a screenshot of the problem >http://pimpstation.org/Screenshot.png . One question I had was did I >only need to build r300_dri.so or all of Mesa? The README wasn't clear >so I only copied the dri driver into X. > >My machine: >Ubuntu 4.10 >Powerbook 15" 1Ghz >RV350 [Mobility Radeon 9600 M10] > > >Thanks, > > Maybe the drivers actually do not care about endianness issue, looking at r200 driver should give a clue of what is needed for PPC. By the way did you see that dri is enabled (glxinfo or your X log file). And what was the previous score of glxgears. For now you should just stay with r300_dri.so, the 2D drivers need to be fixed for PPC. best, Jerome Glisse |
From: Keith C. <kc...@pi...> - 2005-01-06 18:27:38
|
Hi, > Maybe the drivers actually do not care about endianness issue, > looking at r200 driver should give a clue of what is needed for > PPC. > > By the way did you see that dri is enabled (glxinfo or your X log file). > And what was the previous score of glxgears. $ glxinfo name of display: :0.0 Using 8 maximum texture units.. disabling 3D acceleration 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 R300 20040924 AGP 1x PowerPC/Altivec NO-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_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_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 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 > > For now you should just stay with r300_dri.so, the 2D drivers > need to be fixed for PPC. Actually it works pretty good for me with the following two options to fix some corruptions: Option "XaaNoScanlineImageWriteRect" Option "XaaNoScanlineCPUToScreenColorExpandFill" I actually meant Mesa itself, libGL* > best, > Jerome Glisse -- -------- Keith Conger Kei...@gm... http://pimpstation.org |
From: Vladimir D. <vo...@mi...> - 2005-01-06 18:24:32
|
On Wed, 5 Jan 2005, Keith Conger wrote: > Hi, > > I was able to compile the latest r300_driver as of this writing. > glxgears now gets ~650fps but the actual image is drawn below the > window. I also tried a couple NeHe demos and the show the same drwaing > problem. I took a screenshot of the problem > http://pimpstation.org/Screenshot.png . One question I had was did I > only need to build r300_dri.so or all of Mesa? The README wasn't clear > so I only copied the dri driver into X. Hi Keith, * I did compile the entire Mesa tree, but did not install it, instead just added a link to the driver in /usr/X11/lib/modules/dri. Seems to work fine, except that xdriinfo does not appear to work - could be a bug in the driver, though. * your problem looks like an issue at setting viewport and related values (scissor, etc..) It is puzzling you see only a single gear- I would have expected at the very least partial teeth from other gears to show up. This is especially puzzling since your computer does not lockup, as what should surely happen if there were endianness problems all over the place. Could you check what is the value of fbLocation ? (in Xserver and the driver). thank you ! Vladimir Dergachev > > My machine: > Ubuntu 4.10 > Powerbook 15" 1Ghz > RV350 [Mobility Radeon 9600 M10] > > > Thanks, > -- > -------- > Keith Conger > Kei...@gm... > http://pimpstation.org > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Keith C. <kc...@pi...> - 2005-01-06 18:30:49
|
Hi, > Hi Keith, > > * I did compile the entire Mesa tree, but did not install it, instead > just added a link to the driver in /usr/X11/lib/modules/dri. > > Seems to work fine, except that xdriinfo does not appear to work - > could be a bug in the driver, though. Ok thats what I did. > > * your problem looks like an issue at setting viewport and related > values (scissor, etc..) It is puzzling you see only a single gear- > I would have expected at the very least partial teeth from other > gears to show up. Actually the screen shot caught it during a flicker but gears looks fine its just below its window and it flickers. Sorry should have been more clear. > > This is especially puzzling since your computer does not lockup, > as what should surely happen if there were endianness problems all > over the place. > > Could you check what is the value of fbLocation ? (in Xserver and > the driver). Not sure exactly how to do this but will gladly if you you give me a hint. :) Thanks! -- -------- Keith Conger Kei...@gm... http://pimpstation.org |
From: Vladimir D. <vo...@mi...> - 2005-01-06 18:58:58
|
> >> >> This is especially puzzling since your computer does not lockup, >> as what should surely happen if there were endianness problems all >> over the place. >> >> Could you check what is the value of fbLocation ? (in Xserver and >> the driver). > > Not sure exactly how to do this but will gladly if you you give me a > hint. :) Probably the easiest way is to grep for it in the driver source, find a place that is executed and add fprintf(stderr, ...) . The texture code uses it (r300_state.c), so you could put fprintf there and run lesson06 or anything else that uses textures. best Vladimir Dergachev > > Thanks! > > -- > -------- > Keith Conger > Kei...@gm... > http://pimpstation.org > |
From: Keith C. <kc...@pi...> - 2005-01-10 14:06:03
|
Hi, Sorry this took so long. r300_driver prints -16580608 as fbLocation. As for X I can't seem to get it to print it, I'll keep working on this though. Thanks, Keith On Thu, 2005-01-06 at 13:58 -0500, Vladimir Dergachev wrote: > > > >> > >> This is especially puzzling since your computer does not lockup, > >> as what should surely happen if there were endianness problems all > >> over the place. > >> > >> Could you check what is the value of fbLocation ? (in Xserver and > >> the driver). > > > > Not sure exactly how to do this but will gladly if you you give me a > > hint. :) > > Probably the easiest way is to grep for it in the driver source, find a > place that is executed and add fprintf(stderr, ...) . > > The texture code uses it (r300_state.c), so you could put fprintf there > and run lesson06 or anything else that uses textures. > > best > > Vladimir Dergachev > > > > > Thanks! > > > > -- > > -------- > > Keith Conger > > Kei...@gm... > > http://pimpstation.org > > -- -------- Keith Conger Kei...@gm... http://pimpstation.org |
From: Vladimir D. <vo...@mi...> - 2005-01-10 14:44:36
|
On Mon, 10 Jan 2005, Keith Conger wrote: > Hi, > > Sorry this took so long. r300_driver prints -16580608 as fbLocation. As > for X I can't seem to get it to print it, I'll keep working on this > though. Could you change the format to 0x%08x (instead of %d) ? This way it will be printed as hex, easier to read. thank you ! Vladimir Dergachev > > Thanks, > Keith > On Thu, 2005-01-06 at 13:58 -0500, Vladimir Dergachev wrote: >>> >>>> >>>> This is especially puzzling since your computer does not lockup, >>>> as what should surely happen if there were endianness problems all >>>> over the place. >>>> >>>> Could you check what is the value of fbLocation ? (in Xserver and >>>> the driver). >>> >>> Not sure exactly how to do this but will gladly if you you give me a >>> hint. :) >> >> Probably the easiest way is to grep for it in the driver source, find a >> place that is executed and add fprintf(stderr, ...) . >> >> The texture code uses it (r300_state.c), so you could put fprintf there >> and run lesson06 or anything else that uses textures. >> >> best >> >> Vladimir Dergachev >> >>> >>> Thanks! >>> >>> -- >>> -------- >>> Keith Conger >>> Kei...@gm... >>> http://pimpstation.org >>> > -- > -------- > Keith Conger > Kei...@gm... > http://pimpstation.org > |
From: Keith C. <kc...@pi...> - 2005-01-10 18:09:42
|
Hi, Here ya go: 0xff030000 Also as of this morning the cvs HEAD's driver no longer displays the gears for me. Keith On Mon, 2005-01-10 at 09:44 -0500, Vladimir Dergachev wrote: > > On Mon, 10 Jan 2005, Keith Conger wrote: > > > Hi, > > > > Sorry this took so long. r300_driver prints -16580608 as fbLocation. As > > for X I can't seem to get it to print it, I'll keep working on this > > though. > > Could you change the format to 0x%08x (instead of %d) ? This way it will > be printed as hex, easier to read. > > thank you ! > > Vladimir Dergachev > > > > > Thanks, > > Keith > > On Thu, 2005-01-06 at 13:58 -0500, Vladimir Dergachev wrote: > >>> > >>>> > >>>> This is especially puzzling since your computer does not lockup, > >>>> as what should surely happen if there were endianness problems all > >>>> over the place. > >>>> > >>>> Could you check what is the value of fbLocation ? (in Xserver and > >>>> the driver). > >>> > >>> Not sure exactly how to do this but will gladly if you you give me a > >>> hint. :) > >> > >> Probably the easiest way is to grep for it in the driver source, find a > >> place that is executed and add fprintf(stderr, ...) . > >> > >> The texture code uses it (r300_state.c), so you could put fprintf there > >> and run lesson06 or anything else that uses textures. > >> > >> best > >> > >> Vladimir Dergachev > >> > >>> > >>> Thanks! > >>> > >>> -- > >>> -------- > >>> Keith Conger > >>> Kei...@gm... > >>> http://pimpstation.org > >>> > > -- > > -------- > > Keith Conger > > Kei...@gm... > > http://pimpstation.org > > -- -------- Keith Conger Kei...@gm... http://pimpstation.org |
From: Vladimir D. <vo...@mi...> - 2005-01-10 22:23:50
|
On Mon, 10 Jan 2005, Keith Conger wrote: > Hi, > Here ya go: > 0xff030000 > > Also as of this morning the cvs HEAD's driver no longer displays the > gears for me. This is probably because I left the pipeline using agp buffer upload of vertices instead of immediate one. Try editint r300_render.c, r300_run_render function to make sure it calls r300_run_immediate_render and not *vb* version. Also, could you try putting the following fragment in r300_render.c r300_run_immediate_render (and/or *vb* counterpart): reg_start(0x2140, 0); e32(2); (Also try 0 and 1). If this has any effect, try changing r300_state.c, r300ResetHwState, from line r300->hw.unk2140.cmd[1] = 0x00000000; to r300->hw.unk2140.cmd[1] = #ifdef MESA_BIG_ENDIAN R200_VC_32BIT_SWAP; #else R200_VC_NO_SWAP; #endif (R200 is not a mistake - these constants are not defined (yet ?) for R300). thank you ! Vladimir Dergachev > > Keith > On Mon, 2005-01-10 at 09:44 -0500, Vladimir Dergachev wrote: >> >> On Mon, 10 Jan 2005, Keith Conger wrote: >> >>> Hi, >>> >>> Sorry this took so long. r300_driver prints -16580608 as fbLocation. As >>> for X I can't seem to get it to print it, I'll keep working on this >>> though. >> >> Could you change the format to 0x%08x (instead of %d) ? This way it will >> be printed as hex, easier to read. >> >> thank you ! >> >> Vladimir Dergachev >> >>> >>> Thanks, >>> Keith >>> On Thu, 2005-01-06 at 13:58 -0500, Vladimir Dergachev wrote: >>>>> >>>>>> >>>>>> This is especially puzzling since your computer does not lockup, >>>>>> as what should surely happen if there were endianness problems all >>>>>> over the place. >>>>>> >>>>>> Could you check what is the value of fbLocation ? (in Xserver and >>>>>> the driver). >>>>> >>>>> Not sure exactly how to do this but will gladly if you you give me a >>>>> hint. :) >>>> >>>> Probably the easiest way is to grep for it in the driver source, find a >>>> place that is executed and add fprintf(stderr, ...) . >>>> >>>> The texture code uses it (r300_state.c), so you could put fprintf there >>>> and run lesson06 or anything else that uses textures. >>>> >>>> best >>>> >>>> Vladimir Dergachev >>>> >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> -------- >>>>> Keith Conger >>>>> Kei...@gm... >>>>> http://pimpstation.org >>>>> >>> -- >>> -------- >>> Keith Conger >>> Kei...@gm... >>> http://pimpstation.org >>> > -- > -------- > Keith Conger > Kei...@gm... > http://pimpstation.org > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Keith C. <kc...@pi...> - 2005-01-11 20:05:23
|
Hi, > This is probably because I left the pipeline using agp buffer upload > of vertices instead of immediate one. > > Try editint r300_render.c, r300_run_render function to make sure > it calls r300_run_immediate_render and not *vb* version. Checkout cvs today, looks like you switched this back? > > Also, could you try putting the following fragment > in r300_render.c r300_run_immediate_render (and/or *vb* counterpart): > > reg_start(0x2140, 0); > e32(2); > > (Also try 0 and 1). Tried this gears still draw outside the window. > > If this has any effect, try changing r300_state.c, r300ResetHwState, > from line > r300->hw.unk2140.cmd[1] = 0x00000000; > > to > r300->hw.unk2140.cmd[1] = > #ifdef MESA_BIG_ENDIAN > R200_VC_32BIT_SWAP; > #else > R200_VC_NO_SWAP; > #endif Tried this gears still draw outside the window. -- -------- Keith Conger Kei...@gm... http://pimpstation.org |
From: Vladimir D. <vo...@mi...> - 2005-01-11 20:35:43
|
On Tue, 11 Jan 2005, Keith Conger wrote: > Hi, > >> This is probably because I left the pipeline using agp buffer upload >> of vertices instead of immediate one. >> >> Try editint r300_render.c, r300_run_render function to make sure >> it calls r300_run_immediate_render and not *vb* version. > Checkout cvs today, looks like you switched this back? Yep. I found out that such use of AGP space corrupts texture structures. It'd be nice if someone who knows how Mesa includes work (i.e. the template stuff used in mga driver..) or has time to study their usage converts r300_render.c to the proper way of things. Especially as Aapo Tahkola has added to r300_demo a demonstration of drawing using element buffers. >> >> Also, could you try putting the following fragment >> in r300_render.c r300_run_immediate_render (and/or *vb* counterpart): >> >> reg_start(0x2140, 0); >> e32(2); >> >> (Also try 0 and 1). > > Tried this gears still draw outside the window. Is there any difference at all ? What about texture programs like NeHe lesson 06 ? best Vladimir Dergachev |
From: Keith C. <kc...@pi...> - 2005-01-11 20:48:32
|
Hi, > > Is there any difference at all ? What about texture programs like NeHe > lesson 06 ? Nope, still draws below the window. :( Thanks, -- -------- Keith Conger Kei...@gm... http://pimpstation.org |
From: Jerome G. <j.g...@fr...> - 2005-01-12 17:51:57
|
Keith Conger wrote: >Hi, > > > >>Is there any difference at all ? What about texture programs like NeHe >>lesson 06 ? >> >> > >Nope, still draws below the window. :( > >Thanks, > > I think i found somethings that might help. Unfortunetly i am away for my study. But i will try this friday or saturday. Anyway Keith there is no too much wory to have as the r300_demo work well and draw where expected :) This is just few things to tweak for PPC in dri. By the way you said that with setting 0x2140 to 2 you got the gears again with last r300_dri thus using vertex buffer (this what use last cvs Vlad ?). If so that mean we know what is the purpose of the 0x2140 register and could give him the right name :). I will let you know as soon as i successfully test my idea. I read too that r300_demo & dri seems to work on r400 great news :) best, Jerome Glisse |
From: Keith C. <kc...@pi...> - 2005-01-06 18:35:57
|
Hi, > > * I did compile the entire Mesa tree, but did not install it, instead > just added a link to the driver in /usr/X11/lib/modules/dri. > > Seems to work fine, except that xdriinfo does not appear to work - > could be a bug in the driver, though. Actually this works for me: $ xdriinfo Screen 0: r300 -- -------- Keith Conger Kei...@gm... http://pimpstation.org |
From: Vladimir D. <vo...@mi...> - 2005-01-06 18:55:15
|
On Thu, 6 Jan 2005, Keith Conger wrote: > Hi, > >> >> * I did compile the entire Mesa tree, but did not install it, instead >> just added a link to the driver in /usr/X11/lib/modules/dri. >> >> Seems to work fine, except that xdriinfo does not appear to work - >> could be a bug in the driver, though. > > Actually this works for me: > $ xdriinfo > Screen 0: r300 Yes, but it does not report any options, while there should be some - just copied from r200 driver. best Vladimir Dergachev > > -- > -------- > Keith Conger > Kei...@gm... > http://pimpstation.org > |
From: Jerome G. <j.g...@fr...> - 2005-01-10 17:52:13
|
Vladimir Dergachev wrote: > > > On Mon, 10 Jan 2005, Keith Conger wrote: > >> Hi, >> >> Sorry this took so long. r300_driver prints -16580608 as fbLocation. As >> for X I can't seem to get it to print it, I'll keep working on this >> though. > > > Could you change the format to 0x%08x (instead of %d) ? This way it > will be printed as hex, easier to read. > I played with this value and i got no lockup when i do some swapping : aabbccdd become bbaaccdd I do this in radeon_screen.c where the FBLOCATION register is read. By the way ccdd are no revealent here because they are 0. I i got no lockup (with glxgears or one of my gl applications) i still see nothing (in fact the window is fill with some random pattern or memory garbage) and the fps drop to very low value (65fps with glxgears where i get 200 & more in software and expect 1000 & more with hardware :)) I also looked at the radeon driver in the Xorg tree and i notice that there seems to be byte swapping for MMIO register access. But when i try to do so for r300 dri i lockup the computer. To see for byte swapping in xorg look at /xc/programs/Xserver/hw/xfree86/common/compiler.h There is the definition for MMIO_IN32 & MMIO_IN16 MMIO_OUT32 & MMIO_OUT16. If we are on ppc architecture thus macro are defined with byte swapping unless PPC_MMIO_IS_BE is defined. But all definition of MMIO are dependant of too much things...So i am not sure which version is used. I guess i have to make some print to test this... So do you think there is somethings related with byte swapping MMIO ? With applying byte swapping to get_short & get_int in r300_demo i successfully run all the demo except the --vb-triangles, --eb-triangles & --idx-triangles where i see nothing guess this is related to cp engine that need some byte swapping no ? Or does that Keith successfully running glxgears (even if they are drawn in wrong place) means that the vertex or elements buffer work properly on ppc ? Dammm G5 are beautifull but they give some work :) best, Jerome Glisse |
From: Vladimir D. <vo...@mi...> - 2005-01-10 21:15:57
|
> > With applying byte swapping to get_short & get_int in > r300_demo i successfully run all the demo except the > --vb-triangles, --eb-triangles & --idx-triangles where i see > nothing guess this is related to cp engine that need some > byte swapping no ? Or does that Keith successfully running > glxgears (even if they are drawn in wrong place) means that > the vertex or elements buffer work properly on ppc ? It might be that these have different byteswapping for the data in AGP memory. I imagine if vertex data got byteswapped the wrong way you would see nothing as the coordinates would be outside of the viewport or triangles be too small to draw (in which case you will see only one point on the screen) best Vladimir Dergachev > > Dammm G5 are beautifull but they give some work :) > > best, > Jerome Glisse > |