[Openchrome-devel] [Bug 96711] K8M800/K8N800 (unsure which): 0.5.0-rc2 gets stuck saturating cpu during basic use

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96711

--- Comment #12 from Kevin Brace <kevinbrace at gmx.com> ---



(In reply to Roc Vallès Domènech from comment #6)

Hi Roc,

> Found this config file, which I apparently wrote in 24122014 and forgot
> about:
> 
> Section "Device"
>         Identifier      "openchrome"
>         Driver  "openchrome"
>         Option  "SWCursor"      "true"
>         Option  "AccelMethod"   "XAA"
>         Option  "NoXVDMA"       "true"
>         #Option "VBEModes"      "true"
> EndSection
> 
> So, I'm leaving the file as it might be helpful in the future, but commented
> all option lines and restarted X.
> 

You can safely take out the following lines.

Option  "AccelMethod"   "XAA"
#Option "VBEModes"      "true"


XAA has been gone since Version 0.3.3.
VBE was removed by me when Version 0.4.0 was released.
VBE is gone forever.
As for NoXVDMA, OpenChrome might be disabling it internally regardless of the
option since they has been some talk about K8M800 having a hardware bug with
their interrupt handling.
    I think this will be the minimalist xorg.conf.

______________________________________________________________________
Section "Device"
        Option  "SWCursor"      "true"
        Option  "NoXVDMA"       "true"
EndSection
______________________________________________________________________

You can probably even take out NoXVDMA option.


> X seems to start, but no mouse pointer. Power cycled just in case. Still no
> mouse pointer. Xorg of this attached shortly.
> 

Okay, I should have read your comment more carefully before clicking the "Save
Changes" button.
It appears that K8M800 and CN700 (and P4M800 Pro and VN800) all seem to have a
CLE video display engine.
In this situation, it is possible that one monitor (i.e., VGA) might see the
cursor, but not the other one.
I observed this with CN700 chipset recently.
When I tested OpenChrome with ABIT KV-80 mainboard (K8M800 chipset) 2 months
ago, hardware cursor worked. (i.e., I did not have to use xorg.conf.)


> Then I uncommented the SWCursor line, and so far all good, and with EXA now
> that the other lines are commented.
> 

You will have to stick to that option for now.
Around Version 0.6, I may force turn on software cursor if 2 display
controllers are going to be used.
HW cursor appears to work for desktop K8M800 (i.e., VGA only).


> Tested xterm scrolling, watching a video with mpv; it's as good (or as bad)
> as usual. -vo x11, as -vo xv (as always before) doesn't display a thing. Did
> some webbrowsing. So far so good.
> 

When I saw the Xorg.0.log, you are getting around 50 MB / sec. frame buffer
bandwidth.

______________________________________________________________________
. . .
[    67.817] DRM memory allocation failed -6
[    67.817] 635904 bytes of Linear memory allocated at 649000, handle
138823280
[    67.828] (II) CHROME(0): Benchmarking video copy.  Less time is better.
[    67.849] (--) CHROME(0): Timed   libc YUV420 copy... 17592246. Throughput:
54.0 MiB/s.
[    67.870] (--) CHROME(0): Timed kernel YUV420 copy... 16968511. Throughput:
55.9 MiB/s.
[    67.890] (--) CHROME(0): Timed    SSE YUV420 copy... 16869077. Throughput:
56.3 MiB/s.
[    67.911] (--) CHROME(0): Timed    MMX YUV420 copy... 16908711. Throughput:
56.1 MiB/s.
[    67.931] (--) CHROME(0): Timed 3DNow! YUV420 copy... 16954890. Throughput:
56.0 MiB/s.
[    67.951] (--) CHROME(0): Timed   MMX2 YUV420 copy... 16867230. Throughput:
56.3 MiB/s.
[    67.951] Freed 6590464 (pool 4)
. . .
______________________________________________________________________


Due to the way AMD architected HyperTransport bus and K8M800 being the first
generation AMD Athlon 64 IGP for VIA Technologies, maybe this is to be
expected.
K8M800 needs to talk to Athlon 64 first before Athlon 64 accesses its DRAM
controller reserved for frame buffer use.
This adds tremendous memory access latency.
Furthermore, write combining may not be turned on by BenQ (in the firmware),
and I will assume that this reduces performance as well.
Plus, the Athlon 64 you have is probably a single channel memory model (Socket
754 equivalent).
No wonder you end up with direct CPU frame buffer access performance worse than
CLE266.


> Also tested booting without viafb. Still crashes all the same.

I am still working on this, but it will likely take time before it is resolved.
Eventually, OpenChrome needs to get the intialization right since I will like
to resume the work on the newer DRM module supporting KMS.
But before that, I need to stabilize the UMS code.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/openchrome-devel/attachments/20160701/e9b85e06/attachment.html>