Linux dev dri card0
Hi,
i’m learning how to use opengl on pi4.
AFAIK in order to use create windows i must use Linux DRM (on pi0 it was DIspmanx).
Can you explain why there are three diffrent cards?
Re: Understanding /dev/dri/card0, card1 and renderD128
root@pi400:~# ls -l /dev/dri/by-path/ total 0 lrwxrwxrwx 1 root root 8 Mar 12 12:17 platform-fec00000.v3d-card -> ../card0 lrwxrwxrwx 1 root root 13 Mar 12 12:17 platform-fec00000.v3d-render -> ../renderD128 lrwxrwxrwx 1 root root 8 Mar 13 13:40 platform-gpu-card -> ../card1 renderD128 and card0 are the 3d only core, it can do 3d rendering, but never do any video output
card1 is the 2d subsystem, it deals with converting a 2d framebuffer into a usable video signal on one of the many output ports on the hardware
if using «dtoverlay=vc4-fkms-v3d», then DRM is just translating your requests, and using dispmanx behind the scenes, and it will happily co-exist with dispmanx based applications
if using «dtoverlay=vc4-kms-v3d» then DRM is directly manipulating the 2d hardware, and dispmanx will no longer work
6by9 Raspberry Pi Engineer & Forum Moderator
Posts: 14494 Joined: Wed Dec 04, 2013 11:27 am Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.
Re: Understanding /dev/dri/card0, card1 and renderD128
Please note that the load ordering is NOT guaranteed. You should always query the devices for their rendering capabilities when trying to work out which one to use, not hard code it.
(On a Pi2 or 3 with vc4-kms-v3d there will only be one card as the V3D block is part of the vc4 driver).
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I’m not interested in doing contracts for bespoke functionality — please don’t ask.
Re: Understanding /dev/dri/card0, card1 and renderD128
the official modetest.c has a lengthy function for determining which card (0/1) is valid — in fact I don’t think they ever even refer to cards by name so it’s robust to any number of «cards». I’ve found personally that a much simpler method is sufficient:
if ((resources = drmModeGetResources(device)) == NULL) // if we have the right device we can get it's resources but who knows how future proof that is. full example:
Ubuntu Wiki
The /dev/dri/card0 device file is provided by the Linux kernel. If the file is missing, it prevents hardware acceleration from working. See if reloading the kernel module makes it work:
# Save your work first! $ sudo rmmod i915 $ sudo modprobe i915 $ lsmod | grep i915 i915 65412 1 drm 96424 2 i915 $ sudo pkill X
Problem: Falling back to OpenGL software rendering
Check if you’re using software or hardware 3D rendering via glxinfo|grep render.
1. Is properly using hardware rendering:
bryce$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20090114 x86/MMX/SSE2
2. Is falling back to software rendering:
bryce$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Software Rendering
Having DRI disabled can lead to this. Check if it has been loaded; your Xorg.0.log should show something like this:
bryce$ egrep "(GLX|DRI)" /var/log/Xorg.0.log (==) AIGLX enabled (II) Loading extension GLX (II) Loading extension XFree86-DRI (II) Loading extension DRI2 (WW) intel(0): DRI2 requires UXA (II) intel(0): [DRI] installation complete (II) intel(0): 0x0077f000-0x0cd3ffff: DRI memory manager (202500 kB) (II) intel(0): direct rendering: XF86DRI Enabled (II) AIGLX: Screen 0 is not DRI2 capable (II) AIGLX: enabled GLX_SGI_make_current_read (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control (II) AIGLX: enabled GLX_texture_from_pixmap with driver support (II) AIGLX: Loaded and initialized /usr/lib/dri/i965_dri.so (II) GLX: Initialized DRI GL provider for screen 0
3. Has no direct 3D rendering:
bryce$ glxinfo | grep render direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) OpenGL renderer string: Mesa GLX Indirect
Problem: glxgears has low FPS
It is important to note and remember that glxgears is *not* a benchmark tool. It simply measures how fast the driver writes images to the screen, whereas most 3D applications are limited by render speed, not merely blit speed. Instead use a 3D game (flightgear, tremulous, etc.) that has a real rendering workload to make comparisons.
Too often when glxgears is quoted in a bug report, the reporter is simply misunderstanding the tool’s output. For this reason mention of glxgears in a bug report is a quick way to get the report closed as invalid! Use other tools instead.
But for your own edification, here’s some insights into what the glxgear number changes imply:
1. glxgears drops from XXXX to YYY
This is generally nothing to worry about. High glxgears numbers generally indicate excessively high screen repainting, so if this drops from say 1500 fps to 500 fps, it should not produce any noticeable performance impact.
2. glxgears drops from XXX to YYY
As in #1, these drops are *usually* nothing to worry about, especially if you haven’t noticed any change in performance. In *some* cases if you notice a performance drop, glxgears numbers may drop as well, and there may indeed be a correlation. However, glxgears isn’t a benchmark, so it does little good to post the numbers (indeed, if anything it flags your post as ill-informed on the subject!)
Instead, get before and after FPS measurements using a 3D game, such as sauerbraten, tuxracer, tremulous, or the like.
3. glxgears drops from XXX to YY (e.g. usually around ~50-60fps)
This may indicate that you have vblank syncing turned on. Is the glxgears fps roughly equal to the refresh rate of your monitor? (LCDs tend to operate at 60Hz, so 50-60fps is common in these cases)
If so, see the previous section for a discussion of vblank settings. Normally vblank is a GOOD thing, but it can cause side-effects. If you are experiencing performance impacts, try disabling vblank.
4. glxgears drops to 30fps or below
Any time glxgears returns fps less than your monitor’s refresh rate, it definitely indicates a performance problem.
If the fps seems to hit at about half your monitor refresh rate, it indicates the graphics card is not synchronizing properly, and is missing every other frame request by the monitor.
X/Troubleshooting/3D (последним исправлял пользователь static-50-53-79-63 2012-04-16 17:11:20)