The driver is very slow with Kicad

Element Green element at elementsofsound.org
Mon Nov 28 13:23:26 PST 2011


On Mon, Nov 28, 2011 at 12:53 PM, Alex Deucher <alexdeucher at gmail.com>wrote:

> On Mon, Nov 28, 2011 at 3:33 PM, Element Green
> <element at elementsofsound.org> wrote:
> > Hello,
> > I happened upon this thread when searching for information on slow
> > performance with Kicad and the open source radeon driver.
> > http://lists.x.org/archives/xorg-driver-ati/2011-August/021077.html
> > I have a ATI/AMD HD 5800 series video card in my laptop.  I've also been
> > rather impressed with the open source driver, even compared to Catalyst
> > (which seems to suffer from many problems, especially with gnome 3).  So
> I'm
> > very keen on getting Kicad to be usable with it.
> > After doing a lot of profiling with sysprof, oprofile and gprof, I
> > discovered that the open source radeon driver works acceptably when the
> > radeon Kernel module is not loaded.  I discovered this when I was trying
> to
> > switch back to the open source driver from Catalyst and there was an
> issue
> > with the Kernel module loading.
> > From what I can tell from /var/log/Xorg.0.log there is some rather
> > significant initialization differences when the radeon Kernel module has
> not
> > been loaded.  I tried disabling dri and dri2 to see if they were the
> > culprit, but that makes Xorg non functional (weird square block for a
> mouse
> > cursor over a black or corrupted display).  I also tried disabling many
> > other extensions and modules (Render, glx, Composite), but none of them
> > seemed to be causing the issue.
> > Does this lend any information in regards to what could be causing the
> poor
> > performance with Kicad?  Any ideas what different code paths could be
>
> When you don't load KMS, you disable acceleration so you are getting
> software rendering.  Adding:
> Option "NoAccel" "True"
> to the device section of your xorg.conf should produce the same
> effect.  IIRC, Kicad uses certain operations that are not accelerated
> which causes a fallback to software rendering.  This ends up being
> slower than pure sw rendering due to ping-ponging between GPU and CPU
> memory and waiting for the gfx pipe to drain.
>
> Alex
>
>
Hello Alex,

I just gave that a try just before getting your email (a diff between the 2
Xorg logs made it obvious) and it did indeed speed things up.  Previously
using xtrace I got a list of X protocol drawing primitives being used
(listed below, with the number of calls in my test run).  What extension or
module would acceleration of these operations fall under?  EXA, Render, or
??  I'm a pretty competent programmer, but have never worked with Xorg and
find the sheer number of different extensions, deprecated extensions, etc
to be rather confusing.  I'd like to have a crack at adding acceleration
for the missing operations.  Any idea why they are missing for this card?
 Has AMD released enough info for this type of effort?  Also if you have
any tips on how I can tell if a given operation is accelerated or not, that
would be great.

Thanks for the helpful info!

Element Green


Some of the protocol operations gleaned using xtrace for Kicad test run:
   1035 CopyArea
   1072 op=Over(0x03)
   1168 GetInputFocus
   1193 FreePicture
   1231 CreatePicture
   1439 FillRectangles
   1616 FreePixmap
   1655 CreatePixmap
   2064 coordinate-mode=Origin(0x00)
   3235 PolyFillArc
   4467 SetClipRectangles
   8443 FillPoly
   9526 PolyRectangle
  10374 PolyFillRectangle
  13094 PolyArc
  31302 PolySegment
  39269 PolyPoint
  54587 ChangeGC
  59700 PolyLine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-driver-ati/attachments/20111128/da130eb9/attachment.html>


More information about the xorg-driver-ati mailing list