Re: radeon/r200 color tiling ddx / drm questions
Roland Scheidegger wrote:
The dri and drm seem fairly straightforward, though I'm not sure the way
I handled communication between especially drm and ddx is how it's meant
to be. dri got a bit unlucky, as ddx can't know at startup if it will be
able to handle color tiling, so old dri together with new drm and new
ddx will not work (correctly) (if you have enabled color tiling). All
other combinations should however work if I didn't forget something.
If an "old" {radeon,r200}_dri.so is completely incompatible with the new
DDX, you need to bump the major version. When that happens the DRI
driver will bail when you try to load it.
---
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, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon client storage support...
I've done a cut-n-paste job on the r200 client storage stuff and made a radeon version.. http://www.skynet.ie/~airlied/patches/dri/radeon_client_storage.diff It builds I don't have a radeon here I can test it on .. when I get back into work I'll test it and commit it if no-one has any problems with it ... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon/r200 color tiling ddx / drm questions
(resend to also reach the xorg mailing list) I have put up an updated version of the color tiling patch here: http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri5.diff http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm5.diff http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx5.diff (if you're wondering why it has already reached patch version 5, that's because the other versions Stephane and me were working on were never really announced somewhere...) The dri and drm seem fairly straightforward, though I'm not sure the way I handled communication between especially drm and ddx is how it's meant to be. dri got a bit unlucky, as ddx can't know at startup if it will be able to handle color tiling, so old dri together with new drm and new ddx will not work (correctly) (if you have enabled color tiling). All other combinations should however work if I didn't forget something. However, 2d doesn't quite work very well, and I have no idea how to fix some issues. 1) the biggest problem is XAA's handling of graphic memory. It treats everything as a single big chunk of linear framebuffer. But we're setting things up so that only the front buffer is tiled (and back buffer / depth buffer (always tiled) in case of 3d). Big problem here, since the XAA functions are the same whether the target is the front buffer or pixmap store. I tried to solve that with explicit src/dst_pitch_offsets, set in the Subsequentxxx functions according to the target (and source) address. However, I still get 2d rendering errors for some reasons. I think I'm missing something here. It is actually not completely bogus, so it can't be that wrong neither. At least the errors are the same with ACCEL_MMIO and ACCEL_CP (and the changed XAA functions still work when tiling is disabled). Any ideas what could be wrong? 2) I was unable to make render work with the changed x coordinates trick, needed to support coordinates beyond 2048. I think it should be possible that this works? 3) When switching from/to a resolution without tiling support, everything on screen will be really wrong and needs to be redrawn. I guess it's somehow possible to mark everything as dirty or something like that? Just externally calling "xrender" doesn't sound like a good solution... 4) surface setup is a mess. Not restored when switching from/to X, not working for regular dual-head, not changed when switching from/to tiled resolutions, and so on. So don't tell me it's broken, I know, it will get fixed, it isn't really a problem. This will eventually use Stephane's new surface ioctl. (The setup should be correct if you just start X and don't switch to a non-tiled resolution - yet the 2d rendering problems remain :-(.) 5) I'm not sure how exactly fbdev (the UseFBDev option) works, but I'm pretty confident it won't work at all with color tiling, and I've no idea how you'd fix that, though I don't think it's really an important issue (a regular fb console should get fixed when the surface regs are properly restored when leaving/entering X). Unfortunately I think I might not figure out the XAA issues, so I could need some help there... Roland --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon/r200 color tiling ddx / drm questions
I have put up an updated version of the color tiling patch here: http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri5.diff http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm5.diff http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx5.diff (if you're wondering why it has already reached patch version 5, that's because the other versions Stephane and me were working on were never really announced somewhere...) The dri and drm seem fairly straightforward, though I'm not sure the way I handled communication between especially drm and ddx is how it's meant to be. dri got a bit unlucky, as ddx can't know at startup if it will be able to handle color tiling, so old dri together with new drm and new ddx will not work (correctly) (if you have enabled color tiling). All other combinations should however work if I didn't forget something. However, 2d doesn't quite work very well, and I have no idea how to fix some issues. 1) the biggest problem is XAA's handling of graphic memory. It treats everything as a single big chunk of linear framebuffer. But we're setting things up so that only the front buffer is tiled (and back buffer / depth buffer (always tiled) in case of 3d). Big problem here, since the XAA functions are the same whether the target is the front buffer or pixmap store. I tried to solve that with explicit src/dst_pitch_offsets, set in the Subsequentxxx functions according to the target (and source) address. However, I still get 2d rendering errors for some reasons. I think I'm missing something here. It is actually not completely bogus, so it can't be that wrong neither. At least the errors are the same with ACCEL_MMIO and ACCEL_CP (and the changed XAA functions still work when tiling is disabled). Any ideas what could be wrong? 2) I was unable to make render work with the changed x coordinates trick, needed to support coordinates beyond 2048. I think it should be possible that this works? 3) When switching from/to a resolution without tiling support, everything on screen will be really wrong and needs to be redrawn. I guess it's somehow possible to mark everything as dirty or something like that? Just externally calling "xrender" doesn't sound like a good solution... 4) surface setup is a mess. Not restored when switching from/to X, not working for regular dual-head, not changed when switching from/to tiled resolutions, and so on. So don't tell me it's broken, I know, it will get fixed, it isn't really a problem. This will eventually use Stephane's new surface ioctl. (The setup should be correct if you just start X and don't switch to a non-tiled resolution - yet the 2d rendering problems remain :-(.) 5) I'm not sure how exactly fbdev (the UseFBDev option) works, but I'm pretty confident it won't work at all with color tiling, and I've no idea how you'd fix that, though I don't think it's really an important issue (a regular fb console should get fixed when the surface regs are properly restored when leaving/entering X). Unfortunately I think I might not figure out the XAA issues, so I could need some help there... Roland --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Page flipping using the video overlay
On Thu, 6 Jan 2005, Roland Scheidegger wrote: Felix Kühling wrote: Hi all, has anyone ever considered using the video overlay for 3D page flipping? It always bothered me that the page-flipping method used by the radeon drivers is so complicated WRT 2D/3D interaction and it would even stop working when (if?) we switch to allocating back buffers per-client. So I thought, couldn't you use the video overlay to display the front buffer and do page flipping by switching the video overlay between two front buffers? It's an interesting idea. I'm not so sure it would work that well in practice (I would guess we'd have seen such implementations by some vendors for some OS otherwise). * requires more dynamic memory management than currently exists in most drivers with a static back buffer Everyone is waiting for a more sane memory management for various reasons... * on some hardware an enabled overlay may reduce 3D performance slightly (it does on Savage hardware) This should be true on all hardware I think. Performance-wise, it might actually not be all that faster than ordinary swaps (since the overlay is just a blit too, and consumes the same amount of memory bandwidth, though you wouldn't have to wait for the blit to happen, and for non-fullscreen (gl-wise) it should be faster). Actually, video overlay is done dynamically on Radeons, though one could use a texture blit for it as well. The usual way is to setup the overlay engine to overlay a surface on framebuffer. This implies that the engine needs to read pixels continously, just like it does with regular framebuffer. Because of this the application should be refreshing at less than half the display rate for the regular blit to consume the same bandwidth as overlay. There is also the nice part is that overlay update registers can trigger automatically on vsync. So if one sets up triple buffer system it is easy to eliminate most tearing *and* waiting completely. The overlay buffer height is not restricted (much), but the width is. On newer radeons it is around 1920 (for HDTV), though I think it's half that for RGB framebuffers. (HDTV assumes YUV). On older radeons it is smaller. The other drawback is that there is only one overlay engine and some GL apps might want it for menus and such. best Vladimir Dergachev Roland --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Page flipping using the video overlay
On Iau, 2005-01-06 at 18:36, Felix KÃhling wrote: > Hi all, > > has anyone ever considered using the video overlay for 3D page flipping? > It always bothered me that the page-flipping method used by the radeon > drivers is so complicated WRT 2D/3D interaction and it would even stop > working when (if?) we switch to allocating back buffers per-client. So I > thought, couldn't you use the video overlay to display the front buffer > and do page flipping by switching the video overlay between two front > buffers? Video overlays are expensive. Its doubling the memory bandwidth or worse. It seems to make much more sense to have an Xaa stackable module that can issue Xaa requests to both buffers. --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Page flipping using the video overlay
Felix Kühling wrote: Hi all, has anyone ever considered using the video overlay for 3D page flipping? It always bothered me that the page-flipping method used by the radeon drivers is so complicated WRT 2D/3D interaction and it would even stop working when (if?) we switch to allocating back buffers per-client. So I thought, couldn't you use the video overlay to display the front buffer and do page flipping by switching the video overlay between two front buffers? It's an interesting idea. I'm not so sure it would work that well in practice (I would guess we'd have seen such implementations by some vendors for some OS otherwise). > * requires more dynamic memory management than currently exists in > most drivers with a static back buffer Everyone is waiting for a more sane memory management for various reasons... > * on some hardware an enabled overlay may reduce 3D performance > slightly (it does on Savage hardware) This should be true on all hardware I think. Performance-wise, it might actually not be all that faster than ordinary swaps (since the overlay is just a blit too, and consumes the same amount of memory bandwidth, though you wouldn't have to wait for the blit to happen, and for non-fullscreen (gl-wise) it should be faster). Roland --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: chasing the four level page table
On Thu, Jan 06, 2005 at 03:05:49PM -0500, Jon Smirl wrote: > On 6 Jan 2005 20:38:27 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > > You can't use get_user_pages in this case because the AGP aperture > > can be above mem_map. If none of the callers take page_table_lock > > already you would need to add that too. I guess from the context the lock > > is not taken, but better double check. > > > > Perhaps we should add a get_user_phys() or somesuch for this. > > No where in DRM is page_table_lock being taken. Also, no other device > driver takes page_table_lock either, so that probably implies that DRM > shouldn't start doing it to. No other device driver is also doing such lowlevel stuff with page tables directly afaics. drivers/char/drm seem to be the only drivers using [pgd|pmd|pte]_offset() routines. Dave --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: chasing the four level page table
On 6 Jan 2005 20:38:27 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > You can't use get_user_pages in this case because the AGP aperture > can be above mem_map. If none of the callers take page_table_lock > already you would need to add that too. I guess from the context the lock > is not taken, but better double check. > > Perhaps we should add a get_user_phys() or somesuch for this. No where in DRM is page_table_lock being taken. Also, no other device driver takes page_table_lock either, so that probably implies that DRM shouldn't start doing it to. Best solution would probably be add an mm function for get_user_phys() that takes the lock internally. If you add the function I'll convert DRM to use it. -- Jon Smirl [EMAIL PROTECTED] --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
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 [EMAIL PROTECTED] 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
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 [EMAIL PROTECTED] 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New Debian packages built from Xorg
On Wed, Jan 05, 2005 at 11:46:01PM +0100, Roland Scheidegger wrote: > Philip Armstrong wrote: > >On Wed, Jan 05, 2005 at 10:04:50PM +0100, Roland Scheidegger wrote: > >>Philip Armstrong wrote: > >>>(Well, apart from the fact that UT2003 is completely borked that > >>>is. But that's been the case for a while with the DRI builds. > >>>Foliage and enemies are rendered but the landscape simply isn't > >>>there. It looks like you can see the skybox in all directions > >>>actually, but it might be a different texture. It looks the same > >>>regardless of whether hardware TCL is turned on or not.) > >> > >>I'm not seeing this, but it sounds like it could be related to > >>texgen changes some months ago. > > > > > >It's been like that for a while. Certainly since last Nov IIRC. > That would coincide well with the texgen/tex coord submission changes. > > >UT2004 also has a problem with the menus where they have a pure white > > background instead of the expected image. The game seems to run OK > >however (although not particularly speedily on my hardware). > Don't have issues with the menus. I think I've heard of that problem > some time ago though, iirc it was related to s3tc (not sure though). If > so it might be fixed in a newer version. I'm using the latest version of both UT2003 and UT2004 demos. The demo binary may lag the commercial release of course. In enclosed spaces I can sometimes see correct rendering in UT2003, but usually I just get the skybox. Some kind of Z buffer problem? > >Oh, and DOOM III segfaults on startup. > Sounds like the doom3 not loading libGL correctly to me. Fixed in newer > versions, or try LD_PRELOAD=/usr/lib/libGL.so when starting doom3 (note > though the old version also has some problem with detecting s3tc > extension, so if you don't have the external library installed it might > not work at all). Yup. I grabbed the latest version & it now just segfaults on exit :) (Oh, and I get the 'everything is black' problem as reported previously on dri-devel. But I wasn't expecting it to actually work perfectly.) cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: chasing the four level page table
On Thu, Jan 06, 2005 at 01:36:46PM -0500, Jon Smirl wrote:
> On Thu, 06 Jan 2005 19:12:15 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Yes, you should use get_user_pages() instead if you access real memory.
> > If you try to find hardware mappings using that there is no ready
> > function for you right now, although I guess it could be added.
>
> drm_follow_page is used like this:
>
> offset = drm_follow_page(pt) | ((unsigned long) pt & ~PAGE_MASK);
> map = drm_lookup_map(offset, size, dev);
> if (map && map->type == _DRM_AGP) {
> vunmap(pt);
> return;
> }
>
> I think pt is a user space address. In DRM AGP memory is mapped into
> kernel and user space so the user space address is being converted
> into a kernel space one. The kernel space one is used to verify that
> the address is a valid mapping to AGP space, if so the page is
> unmapped. I didn't write this code so I'm not 100% sure of what is
> going on.
You can't use get_user_pages in this case because the AGP aperture
can be above mem_map. If none of the callers take page_table_lock
already you would need to add that too. I guess from the context the lock
is not taken, but better double check.
Perhaps we should add a get_user_phys() or somesuch for this.
-Andi
---
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, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
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 [EMAIL PROTECTED] 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
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 [EMAIL PROTECTED] 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
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 go
Re: [r300] Latest r300_driver on PPC
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 [EMAIL PROTECTED] 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: chasing the four level page table
On Thu, 06 Jan 2005 19:12:15 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Yes, you should use get_user_pages() instead if you access real memory.
> If you try to find hardware mappings using that there is no ready
> function for you right now, although I guess it could be added.
drm_follow_page is used like this:
offset = drm_follow_page(pt) | ((unsigned long) pt & ~PAGE_MASK);
map = drm_lookup_map(offset, size, dev);
if (map && map->type == _DRM_AGP) {
vunmap(pt);
return;
}
I think pt is a user space address. In DRM AGP memory is mapped into
kernel and user space so the user space address is being converted
into a kernel space one. The kernel space one is used to verify that
the address is a valid mapping to AGP space, if so the page is
unmapped. I didn't write this code so I'm not 100% sure of what is
going on.
On Thu, 06 Jan 2005 19:12:15 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Jon Smirl <[EMAIL PROTECTED]> writes:
>
> > The DRM driver contains this routine:
> >
> > drivers/char/drm/drm_memory.h
> >
> > static inline unsigned long
> > drm_follow_page (void *vaddr)
> > {
> > pgd_t *pgd = pgd_offset_k((unsigned long) vaddr);
> > pud_t *pud = pud_offset(pgd, (unsigned long) vaddr);
> > pmd_t *pmd = pmd_offset(pud, (unsigned long) vaddr);
> > pte_t *ptep = pte_offset_kernel(pmd, (unsigned long) vaddr);
> > return pte_pfn(*ptep) << PAGE_SHIFT;
> > }
> >
> > No other driver needs to chase the page table like this so there is
> > probably some other way to achieve this. Can someone who knows more
> > about the VM system tell me if there is a way to eliminate this code?
>
> Yes, you should use get_user_pages() instead if you access real memory.
> If you try to find hardware mappings using that there is no ready
> function for you right now, although I guess it could be added.
>
> The function is also not quite correct, it should already least take
> the page_table_lock (depending on where you call it from) and check
> p*_none() on each level.
>
> -Andi
>
--
Jon Smirl
[EMAIL PROTECTED]
---
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, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Page flipping using the video overlay
Hi all, has anyone ever considered using the video overlay for 3D page flipping? It always bothered me that the page-flipping method used by the radeon drivers is so complicated WRT 2D/3D interaction and it would even stop working when (if?) we switch to allocating back buffers per-client. So I thought, couldn't you use the video overlay to display the front buffer and do page flipping by switching the video overlay between two front buffers? Potential advantages: * 2D drawing would not be complicated by page flipping * would work with per-client back buffers (just allocate two color buffers instead of one and switch the overlay between them instead of copying to the front buffer) * would be configurable per-application (driconf, .drirc) instead of per screen (xorg.conf) * one page-flipping client could run even with other non-page-flipping 3D clients active at the same time (currently page flipping is completely disabled as soon as the second 3D window opens) * page-flipping client could have a different color depth from the normal frame buffer * smooth scaling of arbitrary resolutions to full screen size would be possible Disadvantages: * watching movies via the Xv extension and page-flipping would not be possible at the same time * requires more dynamic memory management than currently exists in most drivers with a static back buffer * requires two off-screen buffers instead of just one * on some hardware an enabled overlay may reduce 3D performance slightly (it does on Savage hardware) I have no immediate plans to implement such a page-flipping scheme. I'd wait for some off-screen memory management to be in place first. Just wanted to write down the idea before it catches dust. Cheers, Felix -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] blended_fountain snapshot
Vladimir Dergachev wrote: Hi all, The winter holidays are over and I would get busy with regular (but still much fun:) ) things. Thus a bit more detail on the current status of R300 project: You done a great job :) I hope getting more times in few weeks to reduce the todo list :) But for now i am also a bit busy. best, Jerome Glisse --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Latest r300_driver on PPC
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 --- 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, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
