Jump to content

Recommended Posts

Posted

@jock here I am again, I have some interesting information that I discovered doing experiments.
if you remember, some time ago I did some experiments with xorg and acceleration media files on legacy kernels
I had "found" that xorg worked with both the "modesetting" and "armsoc" driver but found that armsoc was definitely much slower than modesetting
https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/?do=findComment&comment=104900

 


so I wanted to experiment with the 5.6 kernel as well....
here's what i found:

on legacy kernel, I found that armsoc and libmali (specifically libmali-rk-utgard-400-r7p0-x11_1.7-1_armhf.deb) conflict, in fact uninstalling this library, and starting xorg with armsoc driver, x11 goes fast. obviously, however, the functionality of opengles is lost. but it does not matter. I wanted to check.
I found relevant information that could also be functional on kernel 5.6.
investigating I saw that an armsoc driver was available on the apt repositories, I tried to install it but nothing, x11 did not start.
So i tried to install xserver-xorg-video-armsoc_1.4-2_armhf.deb of the legacy kernel media pack and it works! x11 starts .. well partially, we lost the window manager, the background and the desktop icons (all black) but we see that the acceleration is active and all there !, so I tried to mix the LIMA drivers with armsoc and it seems to work, or at least glxinfo tells me that the opengl mali 400 acceleration is present.

Section "ServerFlags"
        Option  "AutoAddGPU" "off"
EndSection

Section "Device"
    Identifier  "armsoc"
    Driver      "armsoc"
EndSection


Section "OutputClass"
        Identifier "Lima"
        MatchDriver "armsoc"
        Driver "modesetting"
        Option "PrimaryGPU" "true"
EndSection



now it is evident that the armsoc driver does not work because I assume it is compiled for the legacy kernel
I also searched the net to understand why this driver works, and the one in the repository doesn't.
and that's because this version is compatible with rockchip soc!


https://github.com/paolosabatino/xf86-video-armsoc

  Quote

The currently supported DRM drivers are: - pl111 - exynos - kirin - meson - rockchip - sti - sun4i

Expand  

 


Now I assume that by compiling these armsoc drivers for kernel 5.6 there is a good chance it will work correctly, and can be mixed with the LIMA 3D driver.

my limitation from trying at the moment, is that I don't know how to compile these, I've never done a cross compilation, and don't know (currently) how to do it. And I don't even know how to create installable .deb files from a build (my other current limitation)

Posted

 

Has anyone managed to make IR control work?

 

root@rk322x-box:~# ir-keytable
/sys/class/rc/: No such file or directory
No devices found


root@rk322x-box:~# lsmod
Module                  Size  Used by
lz4                    16384  4
lz4_compress           16384  1 lz4
ssv6x5x               483328  0
mali                  229376  0
snd_soc_rk3228         16384  1
lzo                    16384  4
zram                   24576  2
sch_fq_codel           20480  6
ip_tables              24576  0
autofs4                32768  0


 

Posted
  On 8/22/2020 at 5:19 PM, fabiobassa said:


2) ehmm.... that repository is another work of jock :-)

Expand  

LOL  I didn't associate, stupid me, I'm distracted.

 

 

  Quote

1) download the kernel headers and compile on the board itself, no cross compile. the board is powerfull enough to compile

 

Expand  


i will try, but i don't know if i will succeed, the last time i compiled a kernel, those rare times i did it was over ten years ago

Posted

@jock @fabiobassa I was able to compile the module armsoc,
but unfortunately i can't start it, probably something is missing, i compiled it with everything by default .. here's what the xorg log result is, i get it find the screen but it's not usable, i tried to configure xorg with a section screen with custom resolutions, but I can't go further, I always get the same error.
here the log:

  Reveal hidden contents



 

Posted
  On 8/23/2020 at 3:55 AM, Gabriel Vinicius said:

 

Has anyone managed to make IR control work?

 

root@rk322x-box:~# ir-keytable
/sys/class/rc/: No such file or directory
No devices found

Expand  

i'm not an expert, but i just try a guess, maybe the IR system, in these tvbox, depends from box to box, you should check the dts tree (the original one from your tvbox) and see how it's configured inside, then i don't know how the kernel is put if there is or isn't the right driver.

Posted

@Gabriel Vinicius

You're right, the IR kernel module is not enabled in legacy kernel. This is a mistake I will correct as soon as I can.

It works fine on mainline kernel though. Since most of the remotes shipped with rk3229 boxes uses the NEC protocol, you can probably successfully test it running ir-keytable -p NEC -t and pressing the remote keys.

 

@nokirunner

I tested Lima driver on 5.7 and 5.8, but performance is always the same. The kernel driver is only a small part of the whole, most of the important code is in Mesa project, which contains the actual OpenGL implementation for the Mali-400, so until Mesa is updated to the latest stable version in Ubuntu/Debian or you compile the latest development Mesa, you won't see any real progress.

 

By the way, I think that the Lima driver is not yet very well optimized yet, there is some bottleneck somewhere that makes it work so slowly in X.org. I also tried Gnome 3 on a poor rk3228a (kernel 5.6) and, incredibly, it seems to work a bit better than xfce. It is still slow, but at least has a rich graphics and does not stutter like xfce do.

As the Mesa developer said also in the issue regarding the slow performance of the Allwinner A20, modesetting x.org driver seems not to be really friendly with Lima driver and, in general, with embedded graphics. Panfrost suffers too, for example, and is not so snappier as it used to be with armsoc.

 

I didn't try armsoc yet, I don't even know if it could work or not: actually the kernel is not involved in compiling armsoc, since it only interacts with the DRM bits via "dumb buffers", but I'm skeptic about its interaction with lima driver. You should try to force it using /dev/dri/card0 using some xorg.conf option (DRICard maybe, but man armsoc could help you) and see what happens: if it works (eg: fast 2D) probably you won't be able to use hardware acceleration for 3d games.

 

Lastly, the armsoc driver packaged with armbian is an old one that does not use generic dumb buffers, but instead specific IOCTLs and works only on some DRM drivers found in very old kernels. Don't use it.

 

Ah, a last note... I have an AmLogic S905 box around here too, it has Mali-450 GPU, which is much faster than Mali-400, and also faster DDR3 memory. There Lima driver works much better for 2D out of the box, but still I have the feeling it is not perfectly fluid and optimized as it should be.

Posted

@jockwell, thanks for the explanations.
the fact is that there is certainly something badly designed right now.
we hope for notable improvements in the future.

i managed to compile and install the latest mesa with the latest LIMA driver updates, but nothing has changed.

the last test I would like to do is to install the dri module for the kernel with the latest patches, but I would not want to recompile the whole kernel, but only the module I need, I wonder if I can do it while using an older kernel. ...
this:
https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/lima

but also this, which I understand is the display driver, and takes care of interfacing with the hdmi manages the resolutions of the monitors and so on ..

(which apparently, according to the LIMA documentation, must be started with xorg together with LIMA, but reading you and how you configured xorg, it seems to me that you have totally ignored the existence of this other "display driver" and that must be "mixed" with the LIMA driver)

https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/rockchip

 

according to the LIMA documentation, the two drivers must be combined in this way:
(pay particular attention to that MatchDriver "display DRM driver" ... which must be replaced with "rockchip" or other drivers according to the various brands of the various socs)

Section "ServerFlags"
        Option  "AutoAddGPU" "off"
        Option "Debug" "dmabuf_capable"
EndSection

Section "OutputClass"
        Identifier "Lima"
        MatchDriver "<display DRM driver>"
        Driver "modesetting"
        Option "PrimaryGPU" "true"
EndSection


 

Posted (edited)

Out of curiosity I built the armsoc driver for my rk3399. I can confirm your observation of the faster display output. Of course, there is no 3D acceleration because the driver has no way to delegate 3D requests to the 3D render node. The armada driver (you want the unstable-devel branch) I use for my imx6 has such an ability and surpasses the rk3399 with modesetting despite the lower specification for now.

IMHO armsoc is a dead end until it gets a similar ability. And using glamor with its unnecessary scanout indirection via 3d is also a bad idea. We are all in the same boot, no xorg driver to glue all IPs in an efficient manner together available.

xorg-rockchip-modesetting.logFetching info... xorg-rockchip-armsoc.logFetching info... xorg-imx-armada.logFetching info...

Edited by usual user
attach correct xorg-rockchip-armsoc.log
Posted
  On 8/24/2020 at 10:44 PM, nokirunner said:

according to the LIMA documentation, the two drivers must be combined in this way:
(pay particular attention to that MatchDriver "display DRM driver" ... which must be replaced with "rockchip" or other drivers according to the various brands of the various socs)

Expand  

 

That's the DRM driver built in the kernel. I'm no expert in DRM matter, but this is the general idea I made up: the 3d chip (Mali) can't access the 2D framebuffer; the SoC instead can, precisely on rockchip SoCs it is the VOP that has access to it. With "MatchDriver" configuration line you tell the modesetting driver that it has to connect to the rockchip DRM in the kernel.

 

Since the DRM interface is pretty standard among various SoCs on recent mainline kernels, it does not really matter. If you take a look to the armsoc source code (my variant), you will see that the Allwinner (sunxi), Rockchip and AmLogic DRM (meson) interfaces and they are exactly the same code: I copy-pasted and it just works, only the DRM name to connect to changes, but the core code of armsoc uses the standard dumb buffers DRM interface from the kernel.

Modesetting does the same thing to connect to the kernel DRM, you may optionally tell it which is the DRM to connect to (or the "card").

 

As @usual user also said, the general slowness comes from the glamor "acceleration", which uses the Mali 3D OpenGL for 2D things, instead of leverage the DRM things for 2D.

I suspect that if you disable the glamor acceleration for modesetting with:

Section "Device"
	Identifier "Lima"
	Driver "modesetting"
	Option "AccelMethod" "none"
	Option "kmsdev" "/dev/dri/card1"
EndSection

you end up with decent 2D and no 3D: modesetting will behave like armsoc for 2D, but differently from armsoc, it will totally ignore the 3D part. (hint: you may have to change card1 to card0 on your box)

 

Posted

@jockMine are obviously just guesses of reasoning, based on the information I gathered, but I couldn't test .
You will probably be right, being much more grounded and experienced.
Only for fun I like to test things to verify, maybe you never know, with a bit of (culo) some miracle happens.
I checked the drm kernel folder, there is only the module LIMA, why is not the there rockchip module also?
one thing is certain and makes me suspect that something has gone wrong, something is wrong with the monitor recognition, only one resolution comes out, and the refresh management marks "zero" (showing that it is broken), perhaps, and it's just a guess, this module is not compiled.
FYc3pPd.png

Posted
  On 8/23/2020 at 3:55 AM, Gabriel Vinicius said:

 

Has anyone managed to make IR control work?

 

root@rk322x-box:~# ir-keytable
/sys/class/rc/: No such file or directory
No devices found

 


 

Expand  

Hello, I updated the legacy images with the new kernel module.

If you want to upgrade without reinstalling the full system, you can install the kernel image package downloading it from here: <https://drive.google.com/file/d/1x1ReMTWc1ymEqHT8ahc9wZADfSQGkkCF/view?usp=sharing>

I didn't test the images, I guess they work though.

Posted
  On 8/25/2020 at 12:25 PM, jock said:

You don't see the rockchip module there because it is not compiled as an external module

Expand  

You will also not see it as built-in, the Rockchip display subsystem will be provided by DesignWare IP. The rockchip driver functionality will be provided by the dw_hdmi module. It will provide a cardX node in /dev/dri/. The 3d Mali GPU IP will use either the lima or panfrost module depending which flavor of Mali your device has. It will provide a renderDXXX node in /dev/dri/. Its companion cardX node is of no use and is only there for drm implementation reasons. The ddx xorg driver (modesetting, armsoc, armada, ...) will use the cardX node for display output. Since Xwindow doesn't know what hardware you have, you can use this stanza to give it a hint instead of let it guess which cardX node to use:

Section "OutputClass"
    Identifier   "dwhdmi-rockchip"
    MatchDriver  "rockchip"
    Option       "PrimaryGPU"      "TRUE"
EndSection

This stanza will force instead of autoprobe which ddx driver is to be used:

Section "Device"
    Identifier   "KMS-1"
    Driver       "armsoc"
EndSection

For the ddx driver to support 3d on a different IP it needs the functionality of a submodule (glamoregl for modesetting, etnaviv_drm for armada, but I'm not aware of one for armsoc) to access it via the renderDXXX node. The IPs will exchange buffers via dma_buf with zero copy. The armada driver can configure which submodule to use, so you can combine the i.MX display subsystem with any GPU IP you have a suitable submodule for.

drmdevice-rockchip.logFetching info...

Posted
  On 8/25/2020 at 2:20 PM, usual user said:

You will also not see it as built-in, the Rockchip display subsystem will be provided by DesignWare IP. The rockchip driver functionality will be provided by the dw_hdmi module. It will provide a cardX node in /dev/dri/. The 3d Mali GPU IP will use either the lima or panfrost module depending which flavor of Mali your device has. It will provide a renderDXXX node in /dev/dri/. Its companion cardX node is of no use and is only there for drm implementation reasons. The ddx xorg driver (modesetting, armsoc, armada, ...) will use the cardX node for display output. Since Xwindow doesn't know what hardware you have, you can use this stanza to give it a hint instead of let it guess which cardX node to use:

Section "OutputClass"
    Identifier   "dwhdmi-rockchip"
    MatchDriver  "rockchip"
    Option       "PrimaryGPU"      "TRUE"
EndSection

 

drmdevice-rockchip.log 1.86 kB · 3 downloads

Expand  

I tried this on my rk232x based device and i suspect it doesn't work.
If I put "modesetting" as driver then it recognizes  rockchip and vdpau-rockchip, but with the method described by you I don't get the same result, it tells me that the driver rockchip is not found and starts the same through modesetting ... I suspect that for the rk322x it does not work ... and I also suspect that it is for this reason that glamoregl even if it seems to start does not work as 2d acceleration ... this driver dri is not optimized  at all (or partially brocken) for rk322x  at least the 5.6 kernel, maybe the latest versions like the upcoming kernel 5.9 already contain these fixes.

edit :
in fact there seems to be no trace of rk3228 registers.


https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
(Visual Output Processor) is the Display Controller for the Rockchip series of SoCs which transfers the image data from a video memory buffer to an external LCD interface
look only other rockchip socs :

  Reveal hidden contents


edit2: better investingating
maybe 14 june 2020 is added a basic hdmi support for rk3228 ... (is valid also for rk3229 ?)
https://github.com/torvalds/linux/commit/53ffa1ee8de2cdfb0fcbef798486ba9c7f9316fd#diff-0f18fb301f41340ce62f8d1b44e1247e

evidenced code here:

  Reveal hidden contents

 

Posted
  On 8/26/2020 at 7:36 PM, usual user said:

Can you please attach your /var/log/Xorg.0.log?

Expand  

Xorg driver as "rockchip"
Xorg.0_driver_as_rockchip.log
Xorg driver as "modesetting"
Xorg.0_driver_as_modesetting.log

 

  Quote

That commit was in 2019 and should be available since 5.2.

Expand  

my mistake, I don't know where I saw "2020" ,perhaps  searching and scrolling through this chronology I got confused with the latest HDMI commit
https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/rockchip

 

what is the command to see the devices tree like the one you attached?

Posted

Here my log analysis.

Xorg.0_driver_as_modesetting.log:

The Section "OutputClass" finds the rockchip KMS device and identifies the card node.

[    31.046] (**) OutputClass "dwhdmi-rockchip" setting /dev/dri/card0 as PrimaryGPU

No

Section "Device"
    Identifier   "KMS-1"
    Driver       "modesetting"
EndSection

so driver auto probing with modesetting and fbdev.

[    31.206] (II) LoadModule: "modesetting"
[    31.214] (II) LoadModule: "fbdev"

modesetting initializes with KMS device and glamor is loading.

[    31.262] (II) modeset(0): using drv /dev/dri/card0
[    31.285] (II) Loading sub module "glamoregl"

glamor is associating with GPU device

[    36.175] (II) modeset(0): glamor X acceleration enabled on Mali400

fbdev gets unloaded.

[    36.195] (II) UnloadModule: "fbdev"

All is set up properly and Xwindow is working as best as possibly with modesetting. modesetting does not use acceleration functions from KMS by design and shifts all 2D actions to the 3D GPU, regardless of whether it is emulated by software or accelerated by hardware.

You can test with the attached glxgears script started from a terminal window.

 

Xorg.0_driver_as_rockchip.log:

No "Section "OutputClass" so no KMS device identification.

No Section "Device" so driver auto probing with modesetting and fbdev.

[    53.702] (II) LoadModule: "modesetting"
[    53.704] (II) LoadModule: "fbdev"

modesetting initializes with GPU (Mali) device because of fall back.

[    53.694] 	falling back to /sys/devices/platform/20000000.gpu/drm/card1
[    53.707] (WW) Falling back to old probe method for modesetting

modesetting outputs to a not display capable device because a rendernode has no scan-out facility.

 

fbdev is associating with framebuffer device

[    54.354] (II) FBDEV(1): hardware: rockchipdrmfb (video memory: 3600kB)

I am confused what is going on here and not sure what this proves.

Now I see. In the end you get fbdev with swrast. With this stanza you should get the same observation in the performance:

Section "OutputClass"
    Identifier   "dwhdmi-rockchip"
    MatchDriver  "rockchip"
    Option       "PrimaryGPU"      "TRUE"
EndSection

Section "Device"
    Identifier   "KMS-1"
    Driver       "fbdev"
EndSection

 

  On 8/26/2020 at 9:16 PM, nokirunner said:

what is the command to see the devices tree like the one you attached?

Expand  

"drmdevice" located at libdrm

glxgearsFetching info...

Posted
  On 8/27/2020 at 1:22 AM, usual user said:

Now I see. In the end you get fbdev with swrast. With this stanza you should get the same observation in the performance:

Section "OutputClass"
    Identifier   "dwhdmi-rockchip"
    MatchDriver  "rockchip"
    Option       "PrimaryGPU"      "TRUE"
EndSection

Section "Device"
    Identifier   "KMS-1"
    Driver       "fbdev"
EndSection

 

Expand  



with this configuration I get a decent "2d acceleration" on card0 there is no trace of glamoregl, and there is no trace of 3d acceleration, in fact MESA tells me that it is in softrender on cpu via llvmpipe

I also did a test putting modesetting in place of fbdev and glamoregl immediately comes back, 3d acceleration is activated on MALI, but there is a terribly slow 2D.

At this point I give up. it is evident there is something broken somewhere.

I would be curious to know if the same thing happens on other rk322x Major sister socs or is it just a problem of these rk322x socs

Posted
  On 8/27/2020 at 5:14 AM, nokirunner said:

At this point I give up. it is evident there is something broken somewhere.

Expand  

Everything is as expected.
 - modesetting doesn't have 2D acceleration, but 3D hardware acceleration support over glamour.
 - fbdev has some 2d acceleration via KMS frambuffer emulation, but no 3d hardware
   acceleration support.
 - armsoc seems to have no real 2d acceleration support and no 3d acceleration as I see
   no suitable sub module.

Wayland can use full KMS and 3d acceleration. E.g. Weston with the the drm-backend is running full accelerated. For example, to get a similar flow with Xwindow, armsoc must receive adequate KMS acceleration support and a sub module for 3D acceleration. But there is not much development for ddx drivers anymore. Every new development is Wayland focused. Think it's time to look for a suitable Waland compositor.

glmark2-es2-wayland.logFetching info... glmark2-es2-Xwindow.logFetching info...

Posted
  On 8/27/2020 at 8:16 AM, usual user said:

- modesetting doesn't have 2D acceleration, but 3D hardware acceleration support over glamour.

Expand  

Yes, but obviously something goes wrong with glamoregl, because not only is there no 2d acceleration, but everything becomes so slow that it is almost not usable.   In my opinion it is as if channels some registers that should use hardware of any kind for the correct use, but here something is not going well, which worsens the situation even compared to a context without acceleration at all. That's what I wanted to highlight.

all obviously refers to my hardware based on soc rk322x exsperience.

Posted
  On 8/25/2020 at 12:20 PM, jock said:

Hello, I updated the legacy images with the new kernel module.

If you want to upgrade without reinstalling the full system, you can install the kernel image package downloading it from here: <https://drive.google.com/file/d/1x1ReMTWc1ymEqHT8ahc9wZADfSQGkkCF/view?usp=sharing>

I didn't test the images, I guess they work though.

Expand  

@Gabriel Vinicius did you then do a test with the ir and this new image? it works??

Posted
  On 8/18/2020 at 9:52 AM, hexdump said:

you might have a look at this, but you are on your own then (no warranties or support from my side) - for me it worked to get my h96max h2 which cannot boot from sd card too working by installing an adjusted u-boot - https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328-no-sd-boot

Expand  

Been trying to build this SW on a Linux Mint laptop, when I get to "make PLAT=rk3328 DEBUG=1 bl31" the result is:

 

  CC      bl31/bl31_context_mgmt.c
gcc: error: unrecognized command line option ‘-mstrict-align’; did you mean ‘-Wstrict-aliasing’?
make: *** [Makefile:1070: build/rk3328/debug/bl31/bl31_context_mgmt.o] Error 1

 

Can somebody more experienced than me please give me a hint on what to do about it?

Posted

@Reddwarf please keep on the subjects of the threads - this one here is about rk322x and not rk3328 ... to me it looks like you are trying to compile arm code on an intel machine maybe - for that you'll need to cross compile or compile native on an arm machine ... followup if needed please in a separate thread

 

best wishes - hexdump

Posted
  On 8/27/2020 at 8:16 AM, usual user said:

Everything is as expected.
 - modesetting doesn't have 2D acceleration, but 3D hardware acceleration support over glamour.
 - fbdev has some 2d acceleration via KMS frambuffer emulation, but no 3d hardware
   acceleration support.
 - armsoc seems to have no real 2d acceleration support and no 3d acceleration as I see
   no suitable sub module.

Wayland can use full KMS and 3d acceleration. E.g. Weston with the the drm-backend is running full accelerated. For example, to get a similar flow with Xwindow, armsoc must receive adequate KMS acceleration support and a sub module for 3D acceleration. But there is not much development for ddx drivers anymore. Every new development is Wayland focused. Think it's time to look for a suitable Waland compositor.

glmark2-es2-wayland.log 2.81 kB · 2 downloads glmark2-es2-Xwindow.log 2.81 kB · 2 downloads

Expand  

Thanks for the explanations, I read some of the DRM documentation from the linux kernel and understood some of the /dev/dri/card* and /dev/dri/render* things.

I took a look into the Lima driver to see some references, but I need to read the documentation again because there still are lots of shadows.

 

About the X11 modules, I'm a bit puzzled because I know that modesetting has 2D acceleration, but uses OpenGL to do drawing and compositing, so it uses the 3D capabilities to do 2D job, with horrible performance on our SoCs as we can see.

I'm pretty sure that in the old days when Lima was still not there, modesetting was just able to use KMS/DRM sort of "acceleration", with 2D performance on par with armsoc.

Armsoc has decent 2D performance on 4.4 kernel, but it should work also on mainline if you blacklist Lima driver. it used to work with Mali proprietary driver even on mainline kernel. I took a look into armsoc code, I see it loads EXA and fbdev submodules and nothing else, it provides an internal framework to implement some accelerated function via EXA: normally it is "null" acceleration (source file: armsoc_exa_null.c), but there also forks which use 2D blocks provided by hardware like this for Samsung Exynos which, I suppose, leverages G2D acceleration (see: armsoc_exa_g2d.c).

By the way, when Armsoc is paired with Mali proprietary kernel driver and Mali proprietary userland OpenGL ES libraries, allows accelerated 3D graphics even on mainline kernel via regular DRM dumb buffers. I tested it a lot on rk3288 (Mali T760-MP4), but never really tried on rk322x. If you use modesetting driver along with proprietary Mali things, you can't have 3D acceleration.

This makes up my last confused thought: why armsoc, even without any paired submodule, allows 3D acceleration? Also, looking into the rockchip repository for something interesting, I found a libdrm fork with an implementation of rockchip_drm library that uses the RGA 2D blocks: https://github.com/rockchip-linux/libdrm-rockchip

It is flagged as "deprecated", but maybe could be used to implement some decent 2D... but don't see any direct connection to 3D bits (maybe it is hidden behind the Buffer Object creation via kernel DRM IOCTLs?)

Posted
  On 8/27/2020 at 5:58 PM, jock said:

I know that modesetting has 2D acceleration, but uses OpenGL to do drawing and compositing, so it uses the 3D capabilities to do 2D job, with horrible performance on our SoCs as we can see.

Expand  

This is all about where the memory is located where the operations takes place. In PC world there is only one "GPU" IP. It is implementing everything. Display engine for scan-out and GPU for OpenGL. Once the GPU has rendered directly to the scan-out memory the hardware of the display subsystem outputs it to the monitor. So offloading anything on OpenGl is a good idea. It is a device independent standard and doing composition for movie video is also a fast path. There is no need to support display subsystem acceleration in the CPU area.

But we are dealing with SOCs. They have several IPs where the memory they are dealing with is separated. I.e. They need to pass around memory buffers so that they can work on data that they share. The buffer format has to be identical between different IPs otherwise  you have to convert. A "dumb buffer" format is always possible but you loose acceleration features of special formats. But this requires device dependent knowledge. E.g. a display subsystem may support NV12 format for scan-out. Uploading NV12 data for compositing on the 3d GPU and then forwarding via dump buffer to the display subsystem will not improve the performance, but forwarding via dma_buf to the display subsystem will.

The impact of improper buffer pass around can be seen by the uploaded glmark2 logs. The 3d performance is decreasing cause the GPU can not be served fast enough.
The armada driver implements buffer pass around via etnaviv_gpu for i.MX6 in a device dependent manner and uses dma_buf for zero copy.  See buffer-flow.pdf for the ways the buffers have to travel. modesetting and armsoc are missing this support, hence the low performance. Maybe the armada source can serve as a template for what is required.

  On 8/27/2020 at 5:58 PM, jock said:

I'm pretty sure that in the old days when Lima was still not there, modesetting was just able to use KMS/DRM sort of "acceleration", with 2D performance on par with armsoc.

Expand  

As both use the same method for buffer pass around, this is expected. modesetting is only optimized for PC like scenarios.

 

  On 8/27/2020 at 5:58 PM, jock said:

Armsoc has decent 2D performance on 4.4 kernel, but it should work also on mainline if you blacklist Lima driver.

Expand  

Armsoc is only dealing with the display subsystem. It does not interact with lima or panfrost it is falling back to swrast as no armsoc_dri for mainline is available.

 (EE) AIGLX error: dlopen of /usr/lib64/dri/armsoc_dri.so failed (/usr/lib64/dri/armsoc_dri.so: cannot open shared object file: No such file or directory)
 (EE) AIGLX error: unable to load driver armsoc
 (II) IGLX: Loaded and initialized swrast
 (II) GLX: Initialized DRISWRAST GL provider for screen 0

In the Mali proprietary case that code took care for the proper buffer pass around via the proprietary kernel interface. But that doesn't belong in the Mesa counterpart, as it only cares about OpenGL and it doesn't matter how IPs interact. It provides only buffer import and export. For mainline in xorg the submodule is the proper place. For Weston it is the drm-backend which it already has.

Posted

this is where the big players start playing and everything becomes so dark that I can only catch small shreds of light. :lol:

but I try to ask a question:
why when we force "modesetting" on card1 we have 2D acceleration but the 3D acceleration disappears? or rather, it is channeled to the cpu through softrender llvmpipe ...
wouldn't it be the easiest way to try  change the code by telling it to use the 3d acceleration libraries in these conditions?
do you think it is possible to do such a thing?

Posted

@nokirunner and others

pardon if i say a totally dumb thing, but on legacy kernel there was a way to obtain both x org and accelerated things:

was to EXIT xserver with a init 3 , go into a shell and from there , from cli, launch the appropriate video player with appropriate libraries.
It is necessary to unload some dll and charge back some others.

 

At least on 4.4
When it comes mainline kernel I hold my arms in air 

Again this is what PERSONALLY have understood ater 1.000.000 of post read :mellow: :D

Posted
  On 8/27/2020 at 4:12 PM, hexdump said:

@Reddwarf please keep on the subjects of the threads - this one here is about rk322x and not rk3328 ... to me it looks like you are trying to compile arm code on an intel machine maybe - for that you'll need to cross compile or compile native on an arm machine ... followup if needed please in a separate thread

 

best wishes - hexdump

Expand  

Started a new topic about building problems on ARM platform, can you please help?

Posted
  On 8/28/2020 at 9:32 AM, fabiobassa said:

At least on 4.4
When it comes mainline kernel I hold my arms in air 

Expand  

well, lately I got excited with the mainline kernel for more reasons, I thought that with a bit of cunning and a few tricks I would be able to fit both accelerations by force ... well it's obvious that it's not as simple as I thought ..
I did this also because I see the 4.4 kernel as a dead end, we might as well concentrate the forces with the new ones, also because many improvements are still in sight, both on the gpu side and in other functions in general. (hoping these problems with the rk322x socs will be solved)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines