每日彙整: 2017-11-04

樹莓派、樹莓派之學習、樹莓派之教育

【鼎革‧革鼎】︰ Raspbian Stretch 《六之 D.1 》

甲骨文吏

甲骨文行

『事』從吏字分化出來，表示傳達命令並且監督實施。人『行』到縱橫暢通的十字路口 ，或將有所作為乎？

事要是真的能行，行事『前』的『規劃』不能少，期『中』 必須要『監督』實施，事行『後』一定得『檢驗』是否『符合規劃 』。

……

【怎麼會發生回歸錯誤？】

當一個軟體『變大』『變複雜』的時候，即使好好的『測試』，也難保沒有『錯誤』。以致針對『已知的』臭蟲必須『除錯』。只是除錯這一件事遠比想像的『困難』，常常『改好了這個』卻又『發生了那個』。又有時『修正新錯誤』反而使得『原先沒問題』的倒是『產生了狀況』，這種情形就叫做『回 歸錯誤』Regression Fail！！玩新版 B+ 如果遇到這事，不要覺的奇怪！！

─── 《媒體中心──行事》

 

回顧三年前樹莓派革故 B 鼎新 B+ 之時，也曾遭遇回歸性錯誤！不知今日論壇上何事劍拔弩張？

Re: Mesa driver much slower on Stretch than on Jessie

ShiftPlusOne

Tue Sep 05, 2017 2:30 pm

jamesh wrote: ↑

Tue Sep 05, 2017 2:16 pm

I inclined think the best thing would be to remove the entire slow MESA package from our Stretch, that way people won’t think we are responsible for it when we clearly are not. Not sure how easy that is to do, and it might set a bad precedent – there are quite a few packages that you can easily install that don’t work – don’t want to have to remove all of them, maintenance would be horrendous.

It’s the same package that is responsible for the handling opengl for the vc4 driver. It just uses software rendering if no hardware acceleration is available.

……

Re: Mesa driver much slower on Stretch than on Jessie

jamesh

Tue Sep 05, 2017 2:33 pm

RichardRussell wrote: ↑

Tue Sep 05, 2017 11:36 am

I am unclear to what extent Debian support the armhf architecture. If they do, then absolutely it should be their responsibility to fix issues in packages not supplied by the RPF. But if they don’t, and a regression affects only ARM platforms like the Raspberry Pi, then there’s a danger of nobody accepting ownership of the problem.

Welcome to the world of Open source software…

It is the ‘responsibility’ of the package maintainer to test and ensure their software works correctly. But if they are not interested in ARM devices, they are under no obligation to fix any issues that may occur on the ARM platform. It’s not like they are making any money off the software, or are being paid to maintain it.

I can hear to incoming comment “But the RPF makes money from the software”. This isn’t true. We make money from selling HW, nothing from software. Although there is an interesting calculation you can make. Lets say the RPF make 5 profit per board (this is a made up figure, 5 for roundness). There are approximately 26000 packages in Raspbian. That means5/26000 of that profit, IFF we made money only on the SW, per package, multiplied by the total number of Pi’s sold (14m) = about 2700. So, the profit the RPF have made on one specific package is about2700. Which is few days of engineering time. And that assumes every single Pi runs that package. OK, so its a dodgy calculation, but gives some idea of the cost benefit analysis of where we need to put engineering effort.

 

當此鼎革革鼎之際，莫若面對問題︰

Re: Mesa driver much slower on Stretch than on Jessie

mikerr

Tue Oct 03, 2017 1:53 pm

I was able to improve MESA performance 2x by regressing to the jessie version of one of the libraries, while still running stretch:

Bare stretch:

glxgears -info
123 frames in 5.0 seconds = 24.481 FPS

edit /etc/apt/sources.list to add this at the end:

deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi

now revert to the jessie version:

sudo apt-get update
sudo apt-get install libgl1-mesa-dri=10.3.2-1+deb8u1
sudo apt-mark hold libgl1-mesa-dri

this DOUBLES the framerate of glxgears from 24 fps to 53 fps on my pi2 (and corrects the colours too)

glxgears -info
269 frames in 5.0 seconds = 53.790 FPS

[edit]
if you want to return to the most recent (slow) version for any reason, do this:

sudo apt-mark unhold libgl1-mesa-dri
sudo apt-get upgrade

 

嘗試釐清原由︰

pi@raspberrypi:~ sudo apt-get install libgl1-mesa-dri=10.3.2-1+deb8u1 正在讀取套件清單... 完成 正在重建相依關係           正在讀取狀態資料... 完成 下列的額外套件將被安裝：   libllvm3.5 下列【新】套件將會被安裝：   libllvm3.5 下列套件將會被【降級】：   libgl1-mesa-dri 升級 0 個，新安裝 1 個，降級 1 個，移除 0 個，有 21 個未被升級。 需要下載 9,119 kB 的套件檔。 此操作完成之後，會空出 76.0 MB 的磁碟空間。 是否繼續進行 [Y/n]？ [Y/n]  下載:1 http://mirrordirector.raspbian.org/raspbian jessie/main armhf libllvm3.5 armhf 1:3.5-10+rpi1 [6,644 kB] 下載:2 http://mirrordirector.raspbian.org/raspbian jessie/main armhf libgl1-mesa-dri armhf 10.3.2-1+deb8u1 [2,476 kB] 取得 9,119 kB 用了 3min 18s (46.0 kB/s)                                         選取了原先未選的套件 libllvm3.5:armhf。 （讀取資料庫 ... 目前共安裝了 276416 個檔案和目錄。） Preparing to unpack .../libllvm3.5_1%3a3.5-10+rpi1_armhf.deb ... Unpacking libllvm3.5:armhf (1:3.5-10+rpi1) ... dpkg: 警告: 將 libgl1-mesa-dri:armhf 從 13.0.6-1+rpi2 降級到 10.3.2-1+deb8u1 Preparing to unpack .../libgl1-mesa-dri_10.3.2-1+deb8u1_armhf.deb ... Unpacking libgl1-mesa-dri:armhf (10.3.2-1+deb8u1) over (13.0.6-1+rpi2) ... 設定 libllvm3.5:armhf (1:3.5-10+rpi1) ... 設定 libgl1-mesa-dri:armhf (10.3.2-1+deb8u1) ... 安裝新版的設定檔 /etc/drirc ... pi@raspberrypi:~

 

或許可見曙光︰

 

 

 

知道方向︰

pi@raspberrypi:~ glxinfo | grep -i opengl libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 10.3.2 OpenGL shading language version string: 1.20 OpenGL extensions: OpenGL ES profile version string: OpenGL ES 2.0 Mesa 10.3.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 OpenGL ES profile extensions: pi@raspberrypi:~

 

踏出關鍵一步耶☆

OpenGL ES

Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0. More information about OpenGL ES can be found at https://www.khronos.org/opengles/.

OpenGL ES depends on a working EGL implementation. Please refer to Mesa EGL for more information about EGL.

Build the Libraries

  1. Run configure with --enable-gles1 --enable-gles2 and enable the Gallium driver for your hardware.
  2. Build and install Mesa as usual.

Alternatively, if XCB-DRI2 is installed on the system, one can use egl_dri2 EGL driver with OpenGL|ES-enabled DRI drivers

  1. Run configure with --enable-gles1 --enable-gles2.
  2. Build and install Mesa as usual.

Both methods will install libGLESv1_CM, libGLESv2, libEGL, and one or more EGL drivers for your hardware.

Developers

Dispatch Table

OpenGL ES has an additional indirection when dispatching functions

Mesa: glFoo() –> _mesa_Foo()
OpenGL ES: glFoo() –> _es_Foo() –> _mesa_Foo()

The indirection serves several purposes

  • When a function is in Mesa and the type matches, it checks the arguments and calls the Mesa function.
  • When a function is in Mesa but the type mismatches, it checks and converts the arguments before calling the Mesa function.
  • When a function is not available in Mesa, or accepts arguments that are not available in OpenGL, it provides its own implementation.

Other than the last case, OpenGL ES uses APIspec.xml to generate functions to check and/or converts the arguments.

 

OpenGL® ES is a royalty-free, cross-platform API for rendering advanced 2D and 3D graphics on embedded and mobile systems – including consoles, phones, appliances and vehicles. It consists of a well-defined subset of desktop OpenGL suitable for low-power devices, and provides a flexible and powerful interface between software and graphics acceleration hardware.

 

OpenGL ES API Versions at a Glance

OpenGL ES 3.2 – Additional OpenGL functionality

The latest in the series, OpenGL ES 3.2 added additional functionality based on the Android Extension Pack for OpenGL ES 3.1, which brought the mobile API’s functionality significantly closer to it’s desktop counterpart – OpenGL.

OpenGL ES 3.1 – Bringing Compute to Mobile Graphics

Despite being only a bump in the minor revision of the API, OpenGL ES 3.1 was an enormous milestone for the API, as it added the ability to do general purpose compute in the API, bringing compute to mobile graphics.

OpenGL ES 3.0 – Enhanced Graphics

OpenGL ES 3.0 was another evolutionary step for OpenGL ES, notably including multiple render targets, additional texturing capabilities, uniform buffers, instancing and transform feedback.

OpenGL ES 2.0 – Programmable Shading

OpenGL ES 2.0 was the first portable mobile graphics API to expose programmable shaders in the then latest generation of graphics hardware. It remains a prevalent API today, and still is the most widely available 3D graphics API, and remains a solid choice to target the widest range of devices in the market.

OpenGL ES 1.X – Fixed Function Graphics

OpenGL ES 1.0 and 1.1 were the first portable mobile graphics APIs, defined relative to the OpenGL 1.5 specification, providing fixed function graphics acceleration

 

您在所有發行版中所有硬體架構下所有區域里，指定關鍵字 libgl1-mesa-dri 在套件名稱中搜尋的結果。 找到 5 個匹配的套件。

完整匹配

套件 libgl1-mesa-dri

  • wheezy (oldoldstable) (libs): free implementation of the OpenGL API — DRI modules
    8.0.5-4+deb7u2: amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
  • jessie (oldstable) (libs): free implementation of the OpenGL API — DRI modules
    10.3.2-1+deb8u1: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x
  • jessie-backports (libs): free implementation of the OpenGL API — DRI modules
    13.0.6-1~bpo8+1: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x
  • stretch (stable) (libs): free implementation of the OpenGL API — DRI modules
    13.0.6-1+b2: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
  • buster (testing) (libs): free implementation of the OpenGL API — DRI modules
    17.2.3-1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
  • sid (unstable) (libs): free implementation of the OpenGL API — DRI modules
    17.2.4-1: alpha amd64 arm64 armel armhf hppa i386 m68k mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el s390x sparc64 x32
    13.0.6-1: hurd-i386
    12.0.4-2: kfreebsd-amd64 kfreebsd-i386
    11.2.2-1 [debports]: sh4
  • experimental (rc-buggy) (libs): free implementation of the OpenGL API — DRI modules
    17.3.0~rc2-1: amd64 arm64 armel armhf hppa i386 m68k mips powerpc ppc64 ppc64el s390x sparc64