Bug 96711

Hi Roc,

Sorry about the trouble the new code has caused.
In general, no part of the rendering engine control code has been touched, however, it is quite possible that turning on certain registers that sound like "enable prefetch mode" might have caused the problem.
At this point, since I do not have the exact hardware you have, you may have to try to bisect the code to see which version still works and which one doesn't.
I had someone who was able to do this, and I plan to get a patch for him to try in the next few hours.
He told me that Version 0.4.151 worked but 0.4.152 didn't. (Bug 96352)
    I will delay release of the new official release version until this particular bug is resolved.
Regarding the viafb related bug you have reported, my view is that more and more registers have to be initialized correctly by OpenChrome itself, and I have been doing this, but due to lack of official programming documents for all but last 4 devices (i.e., CX700, VX800, VX855, and VX900) makes it difficult to properly develop OpenChrome.
I hope the future releases will gradually solve this problem, and you will no longer have to have viafb.

Hi Roc,

Just noticed something.

________________________________________________________________________
. . .
[    85.104] (==) CHROME(0): Default visual is TrueColor
[    85.104] (II) CHROME(0): VIASetupDefaultOptions - Setting up default chipset options.
[    85.104] (**) CHROME(0): Option "SWCursor" "true"
[    85.104] (**) CHROME(0): Option "NoXVDMA" "true"
[    85.104] (==) CHROME(0): Shadow framebuffer is disabled.
. . .
________________________________________________________________________


Does the hardware cursor work?
I know that software cursor slows down the system somewhat.
I will also be curious if multi-monitor (RandR) is working with your setup since I got it working with this release, although some problems still do exist (i.e., If you put the second screen near the extended screen right side border, the second screen gets messed up. In order to workaround this problem, move the second screen slightly away from the right side border. I still have not figured out a good solution to this bug.)
In your case, you should be able to do LVDS FP + VGA.
TV has number of problems, and I have observed this with EPIA-M mainboard (CLE266 + VT1622A).

Hi Roc,

It will be nice if you can try out Version 0.5 RC6.
There was an obscure bug where the Chrome IGP's DMA engine was behaving erratically due to a power management related setting I was utilizing.
I changed the setting and the problem went away for this particular setup.

See:

https://bugs.freedesktop.org/show_bug.cgi?id=96352#c13
https://bugs.freedesktop.org/show_bug.cgi?id=96352#c15

Hi Brace,

I'll give it a spin once I'm back from work.

Roc.

Built HEAD as of this commit: https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=52568cf3c04679684b7f62f59ae99ee2153ec8b2

The stall issue seems gone.

Now I'll look into forcing hardware cursors.

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.

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

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

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.

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

Created attachment 124847 [details]
Xorg.0.log with hardware cursor

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

Hi Roc,

> Built HEAD as of this commit:
> https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/
> ?id=52568cf3c04679684b7f62f59ae99ee2153ec8b2
> 
> The stall issue seems gone.
> 
> Now I'll look into forcing hardware cursors.

Okay, probably this commit fixed the problem.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=7199d8206673d227cd7f2b4332b232d8706773fc

The laptop that got the issue fixed was a laptop (Wyse X90L; VN896 chipset).
I do most of the development and primary testing on a laptop (MSI VR321 equivalent; VN896 chipset).
The register I changed the setting does affect engine behavior, in retrospect.
The setting used to clock gate the engine (i.e., pull the engine clock to low state and stay there, in order to reduce power consumption) if the engine entered an idle state.
Now the engine always is on, and this is why I think you do not see the problem anymore in the latest version.
If you do not mind putting your local repository into detached HEAD mode, you can bisect the issue, but I will assume that Version 0.5 RC5 has the issue, but RC6 solves it.
   Regarding the hardware cursor, it appears that CN700 chipset (Bug 94259) and K8M800 may have the same video display engine called CLE.
It appears that they are not capable of IGA1 and IGA2 (IGA = display controller) simultaneous display of the hardware cursor.
This feature is sort of necessary when using multi-monitor mode (i.e., RandR).
The newer CME video display engine appears to support simultaneous hardware cursor display.
I am not 100% positive when the video display engine switched to CME, but it appears around when PM800 / PM880 / CN400 came out.
When you do multi-monior and do not see the hardware cursor in one of the display, then you will have to use software cursor for now.
When you test multi-monitor, you may want to install ARandR to size the screen.

Hi Roc,

While I was writing the reply I just posted (https://bugs.freedesktop.org/show_bug.cgi?id=96711#c8), you posted a message.
Anyway, I am glad that the issue is resolved for now.
This will mean that the major obstacles for releasing OpenChrome Version 0.5 is gone, and I will only have to do a few more commits related to DVI transmitter chip support (VT1632A).
    I am in the process of adding lines of code to takeover the initialization of more and more of the VIA IGP registers, in order to do away with the shadow use of viafb.
As you saw from the bug you experienced, it takes time to get the register combination right since VIA had 11 different generations of IGP, and even within the same chipset, depending on the way the hardware vendor implemented the device, behavior changes.
Plus, for many of their chipsets, they never released hardware programming documents without an NDA.
So please be patient regarding the viafb issue.
I am still working on it since I will like to resolve the instability of ACPI S3 State resume for my own use.

(In reply to Kevin Brace from comment #8)
>    Regarding the hardware cursor, it appears that CN700 chipset (Bug 94259)
> and K8M800 may have the same video display engine called CLE.
> It appears that they are not capable of IGA1 and IGA2 (IGA = display
> controller) simultaneous display of the hardware cursor.
> When you do multi-monior and do not see the hardware cursor in one of the
> display, then you will have to use software cursor for now.
> When you test multi-monitor, you may want to install ARandR to size the
> screen.

Note that, as I don't currently have any VGA screens, I'm doing all tests with the laptop's screen. Just one screen, hardware cursors do not work.

Multi monitor "mode" probably not desirable in my scenario.

(In reply to Kevin Brace from comment #9)
>     I am in the process of adding lines of code to takeover the
> initialization of more and more of the VIA IGP registers, in order to do
> away with the shadow use of viafb.
> So please be patient regarding the viafb issue.

Do not worry. It never worked in the past, and I'm glad someone is working on it at all.

(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.