On Sun, Mar 21, 2010 at 4:46 AM, Chia-I Wu <olva...@gmail.com> wrote: > On Fri, Mar 19, 2010 at 09:57:41PM +0200, George Sapountzis wrote: >> The timing of the first attempt was unfortunate because it was in the >> middle of a re-factoring I had not realized it was happening. The good >> thing is that after the changes by Chia-I and Keith, implementing >> swrastg_dri.so is much simpler. I update the patches at the above >> branch, gallium swrast_dri.so works now with the following caveats: >> * stride: the driver and the loader compute the stride independently. >> They usually agree, but when you start resizing and they finally >> don't, you get a regular oblique image. If you run with valgrind, you >> also get a regular message the size of the mismatch, at each PutImage. >> * fences: i did not use any, are they needed for cell/llvmpipe ? > Nice work. > > I haven't tried this, but I think there should be DRM_CREATE_DRISW and > drisw_api.h, similar to how DRI1 is supported, and let winsys/drm decide > which version to support. swrast will be the only one to support > DRM_CREATE_DRISW. > > This will also give st/dri a chance to define whatever needed to swrast > to implement displaytarget_display in drisw_api.h, both at > drm_api::create_screen time and pipe_screen::flush_frontbuffer time. > drisw_st_framebuffer_flush_front will then only prepare a pipe_surface > for the given attachment and call pipe_screen::flush_frontbuffer. > Similar to what st/glx is doing. This may also solve the resize issue. >
Ah ok, I see this is the right way to do it in gallium. The problem is that DRISW, similar to DRI2, will need to call the loader from the winsys, and from a quick look, this is not done for DRI2 either. So this probably will have to wait for the infrastructure to grow for DRI2 and DRISW will be adapted accordingly afterwards. Wrt the resize issue, solving it properly requires adding the stride as a parameter to the putImage hook of the DRISW loader extension. I committed an ugly workaround at ~gsap7/gallium-drisw which works for softpipe but I don't know when it will explode platform-, rendering- or performance-wise. > If it is feasible, I think it is better to have st/dri support all three > of DRI1/DRI2/DRISW at the same time when drm.h is available; And have > st/dri support only DRISW when drm.h is not available. This will > eliminate the need for st/drisw. Yes, it is feasible but it requires mingling with the mesa build system, which I am not too enthusiastic about :-) Thanks for your comments! George. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
