Summary: | EXA support for mach64 | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | George - <fufutos610> | ||||||||||||||||||||||
Component: | Server/Acceleration/EXA | Assignee: | Xorg Project Team <xorg-team> | ||||||||||||||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||||||
Severity: | enhancement | ||||||||||||||||||||||||
Priority: | high | CC: | alexdeucher, cbm, libv, vallesroc | ||||||||||||||||||||||
Version: | git | ||||||||||||||||||||||||
Hardware: | x86 (IA32) | ||||||||||||||||||||||||
OS: | Linux (All) | ||||||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||||||||||
Bug Depends on: | |||||||||||||||||||||||||
Bug Blocks: | 6877 | ||||||||||||||||||||||||
Attachments: |
|
Description
George -
2006-02-24 03:55:58 UTC
Created attachment 4731 [details] [review] exa for mach64 Created attachment 4778 [details] [review] exa for mach64 - try 1 This patch reorders module loading for ati similar to radeon (exa required fbGlyph symbols from fb). I also rewritten UploadToScreen to follow closely mach64UploadLocalSubImage from the dri driver. It does not work, the machine *locks* when I try to access the allocated DMA buffer. DMA buffer allocation seems ok, I get a pointer to the address at which the drm reports that DMA buffers get allocated. Any help or guidance with this ? Which mesa progs exercise mach64UploadLocalSubImage in mach_dri.so ? thanks, george. Created attachment 4815 [details] [review] exa for mach64 - try 2 With this patch: 24-bit seems to work now (only changed align requirements) in addition to 16bpp and it seems faster than 16bpp ... there is also my latest effort for UploadToScreen: it uses hostdata blits directly similar to CPUToScreenColorExpand from XAA; it does *not* work either, the produced colors are irrelevant; any pointer that may help with this ? Created attachment 4826 [details] [review] exa for mach64 - try 3 - UploadToScreen using hostdata blits works now but it is disabled by default (radeon XAA says memcpy is faster). Is there a typical xorg way to profile upload/download ? - I also started isolating the XAA offscreen memory management code. Currently, exa has a cursor (both hw/sw) but no xv or dri. Created attachment 4847 [details] [review] exa for mach64 - try 4 This is an updated version of the exa patch for mach64, it implement offscreen memory management for EXA (cursor, xv, dri). I plan to profile UploadToScreen to see if hostdata blits were worth the time, but other than that or bug fixes, I do not plan to do any more work in the near future. Thus, I think that the patch is worth an initial review or testing in order to decide if it feasible to include basic solid/copy exa support for mach64 in the 7.1 release. regards, george. change title, http://wiki.x.org/wiki/ExaStatus points here. Created attachment 4850 [details] [review] exa for mach64 - try 4 merge atimach64iodri.h back to atimach64io.h Created attachment 4861 [details] [review] exa for mach64 - try 5 This is a cleaned up version with hostdata blits completely dropped. Profiling showed that plain memcpy is about 4x to 5x faster and hostdata blits spend most of its time polling the FIFO. Created attachment 4870 [details] [review] exa for mach64 - try 6 Port to new EXA API. Created attachment 4906 [details] [review] exa for mach64 - try 7 Use pATI->NeedDRISync for EXA also, avoids unnecessary sync operations for EXA accelerated functions when DRI is not running. Looking at just the EXA acceleration bits, they're looking pretty good to me. I suspect the DRI locking could be simplified, but I haven't looked at it carefully enough, and I'm getting tired. If you don't have a CVS account yet, you should probably apply for one :) (http://www.freedesktop.org/wiki/AccountRequests) Created attachment 5134 [details] [review] exa for mach64 - try 8 In reply to comment #11) > Looking at just the EXA acceleration bits, they're looking pretty good to me. > I suspect the DRI locking could be simplified, but I haven't looked at it > carefully enough, and I'm getting tired. > Drop the DRIUnmarkSync macros. Add comments for DRIMarkSync macros. > If you don't have a CVS account yet, you should probably apply for one :) > (http://www.freedesktop.org/wiki/AccountRequests) However tempting this may be, its also a bit scaring, Maybe after libv lands the xf86-video-mach64 module. The attached patch has been merged in the following repository: git//git.freedesktop.org/~libv/xf86-video-mach64. xf86-video-mach64 is still in development but we intend to to have it distribution ready in time for 7.2. I can't find the repository: git//git.freedesktop.org/~libv/xf86-video-mach64 I'd like to poke around with the new split mach64 driver. Where is the repository for it? (In reply to comment #14) > I can't find the repository: git//git.freedesktop.org/~libv/xf86-video-mach64 > > I'd like to poke around with the new split mach64 driver. Where is the > repository for it? git-clone git://git.freedesktop.org/~libv/xf86-video-mach64 ^ (sorry for the typo) You may also want to poke with render acceleration from bug #6877. gah, copy-paste without thinking, bad Colin no banana. Commited to HEAD. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.