r300 - problem with fragment program
Hi, I've been trying to run project xenocide(projectxenocide.com), but at the start of it there's a ps20 shader which always causes a crash. Setting USE_ARB_F_P == 0 in r300_context.c makes the program run. I'm using current mesa and drm(1.2) The error I get is: drmRadeonCmdBuffer: -22 (exiting) And in dmesg: [drm:r300_emit_carefully_checked_packet0] *ERROR* Cannot emit more than 64 values at a time (reg=4c00 sz=68) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed Is 64 values a hardware limit? Boris Peterbarg --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - problem with fragment program
Jerome Glisse wrote: On 1/26/06, Boris Peterbarg [EMAIL PROTECTED] wrote: Hi, I've been trying to run project xenocide(projectxenocide.com), but at the start of it there's a ps20 shader which always causes a crash. Setting USE_ARB_F_P == 0 in r300_context.c makes the program run. I'm using current mesa and drm(1.2) The error I get is: drmRadeonCmdBuffer: -22 (exiting) And in dmesg: [drm:r300_emit_carefully_checked_packet0] *ERROR* Cannot emit more than 64 values at a time (reg=4c00 sz=68) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed Is 64 values a hardware limit? Seems that the ps20 shader reach the hardware limit. Does fglrx works with this ? This might be due to the traduction of the program which isn't optimal. I guess we can save few more instructions and go from 68 to 64. Btw coud you try with USE_ARB_F_P == 1 and setting if (1) Dump.. in r300_fragprog.c (at bottom of the file). fglrx halts even with glxinfo here for some reason (linux 2.6.15.1, xorg 2.6.9) I've attached the dump with USE_ARB_F_P == 1. Boris Peterbarg dump.tar.gz Description: GNU Zip compressed data
Re: r300 - problem with fragment program
Boris Peterbarg wrote: fglrx halts even with glxinfo here for some reason (linux 2.6.15.1, xorg 2.6.9) I've attached the dump with USE_ARB_F_P == 1. Oops, should've been xorg 6.9.0 Boris Peterbarg Boris Peterbarg --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI AIW Radeon 9800 Pro - LockUp
Jerome Glisse wrote: On 1/7/06, Jerome Glisse [EMAIL PROTECTED] wrote: On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Have you tried checking what's going on with the card memory map ? (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE, CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ? There is definitely a bug or two lurking around when we have CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those lockups). It seems to be related to card memory map, with your patch (radeon mem fix) i have no lockups (at least no during last 10 minutes) but as i update many things and have tweaks in many place i will double check that... In the mean time if more people could test with your patch (even if their regression with it on some hardware) see if this fix the lockup for them. More people testing benh patch on radeon 9800 (or any other radeon that used to lockup) are welcome: http://lists.freedesktop.org/archives/xorg/2005-December/011679.html http://lists.freedesktop.org/archives/xorg/2005-December/011717.html It really seems to fix it. I have been on ut2004 for several minutes without a lockups while it used lockup pretty fast the card before. I will give a look a fglrx way to setup all this. best, Jerome Glisse A bit late to the discussion, but I have a radeon 9800 pro and with r300 and no ati drivers it works really great for a couple of hours straight inside some 3d games. ... Then it locks up. I don't think a 10 minute test is enough. People don't use 3d programs, and especially not games for 10 minutes. I didn't try the patch yet. I'll try it sometime during the week and report what happens. Boris Peterbarg --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: offtopic: quake3 source
Aapo Tahkola wrote: On Sat, 17 Sep 2005 14:05:11 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Bernardo Innocenti wrote: Roland Scheidegger wrote: I've just noticed I have page-flipping enabled in my xorg.conf. I can't afford to crash my X session at this time, but I'll try disabling it later. Works just fine for me (x86, latest drm, latest Mesa, rv250, pageflipping, color tiling, hyperz). My xorg is a bit outdated though (one week old). Hmmm... I'm on x86_64. Perhaps it's a bug in the DRM ioctl32 code? Neverball for x86_64 works fine btw... I shall try with a 32bit version too. You may also want to try this patch, which makes quake3 more stable on my R420 card. Really? Could you try if demos/lodbias works for you? or you can try setting r_textureMode to GL_NEAREST_MIPMAP_NEAREST and try using 16 bit textures (r_texturebits). Fixes in this patch: -Invalid mipmap filters chosen -Fix and enable cube maps -Fix command buffer corruption caused by r300EmitBlit -Fix bad temp count for vsf(fixes lots of little problems with it) This is a really nice patch. I've been playing with Ogre3D and thought of trying all it's samples and sending the result and frame rates to dri-devel. After I saw this, I re-ran all the samples with the patch applied. I ran all the tests on an athlon 2.5GHZ with radeon 9800 pro, after running fglrx first. I ran the tests in an 800x600 window in a 1024x768x32 resolution. Here's what I got: Order is: test, opinion, average, maximum, minimum frame rates If I don't write something, it means there was no change. Bezier: OK, 97.9, 547.9, 6.4 After patch: 308, 541, 19 CameraTrack: OK, 204, 210.1, 70.6 CelShading: pretty bad- the cell is full of squares, 79, 79.8, 42.8 After patch: almost all white, only edges look OK CubeMapping: only possible after patch: OK, 8.64, 10.86, 0.527 DeferredShading: It says Your card does not support at least two simulataneous render targets, so cannot run this demo. Sorry!. With fglrx this sample runs, but I didn't see anything except the fps Dot3Bump: Refused running After patch: Runs...detail by mapping: Specular: Can see black squares interchanged with the material totally Basic: all ok NormalMapped: a bit broken into triangles NormalMappedSpecular: white and red squares under any lighting bump mapping-multi light specular: all breakages possible in one bump mapping-single light: less breakage, some triangles, a little tv-like interpolation bump mapping-multi light: same as single light 55, 340, 3 DynTex: OK, 61.3, 62.1, 17.9 EnvMapping: OK, 251, 418, 74 After patch: 280, 580, 47 Fresnel: gives fragment shader errors, unknown fpi-Opcode 30,20,21,2 Grass: the cell looks pretty bad-red green and black squares with strange color in between, 44, 137, 21 Gui: OK, 4.88, 11.09, 0.78 Lighting: OK, 234, 529, 1 ParticleFX: OK, 164, 264, 1 RenderToTexture: OK, 4.8, 4.9, 0.7 Got a warning here: *WARN_ONCE* File r300_tex.c function r300TexEnv line 819 I am broken - Fixme ! SkeletalAnimation: OK, 164, 503, 50 Transparency: OK, 111, 238, 1.5 Water: broken textures-first texture is pure white instead of more water like transparent, 26, 33, 1 After patch: Much better, first texture fixed, water reflection seen, still some texture breaking into triangles. I also got some warnings about using elt buffers. There are 2-3 more samples, but they all looked fine and they're speed didn't really change after the patch. Boris Peterbarg --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] [patches] debugging lockups
Aapo Tahkola wrote: Jerome Glisse wrote: On 6/1/05, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: What you can do: Please, test the attached patch.drm-cmdbuf-more-pacifiers, and report if there are any regressions (I don't believe there are any) and/or if it removes certain lockups you are seeing. Well, it's hard for me to judge this patch :-) I played Q3A for just over 20 minutes without a single lockup, something I don't think I've accomplished before. I quit that and then tried UT... Which lasted for all of a minute or two before locking up. I rebooted and tried again and got a lockup after only a few minutes. If you're feeling adventurous, I'd appreciate it if you could also try this patch in combination with the patch.remove-userspace-pacifiers patch I posted earlier, though this patch appears to be dangerous still (even though I do not understand why). Well, my last attempt with this patch resulted in immediate lockups. Think it's still worth me testing this path in conjunction with the above patch? You should test it as this patch makes our driver behave more like fglrx. I will test it too, latter this day... Jerome Glisse Well, I'm not getting the immediate lockups that I got before with just the patch.remove-userspace-pacifiers. But I'm still getting seemingly random lockups with patch.remove-userspace-pacifiers + patch.drm-cmdbuf-more-pacifiers. No noticable regressions, but no noticable improvements. I can still play UT and Q3A from anywhere between 2 to 20 minutes. I thought I'd try a little experiment. I compiled the driver on my FreeBSD installation thanks to all the great work that had been done on that in the past. I then created a chrooted development environment in /compat/linux and compiled the linux version of the driver. Installed it in the compatability environment. Both Q3A and UT started up and ran on FreeBSD. And both locked up within the same general time frame I'm seeing under Linux. Not sure if this helps diagnose the problems any further, but I thought some people might be interested in hearing that linux OpenGL apps work on r300 hardware on FreeBSD. I did some figuring on the CB_DPATH problem. After little testing it turns out that the lock up with progs/demos/isosurf goes away when the pacifier sequences are applied to clearbuffer. Im starting to think that this sequence is needed whenever overwriting certain states rather than whenever 3d operation begins and ends. Any brave souls left? (patch attached) I think you're going in the right direction. ut2004demo, which previously always locked up the moment the menu appeared, now locks up after 6-20 seconds or so. Also, a lock up that happened to me with running other programs with glxgears, opening their popup menus and pressing icons takes longer too. Adding patch.remove-userspace-pacifiers to this one causes almost immediate lock ups. I get the feeling the mouse (even with silken mouse off) has some effect. It's as if the more I move it the faster the lock up appears. Boris Peterbarg --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Peter Zubaj wrote: Hi, First patch helped lot (but there are still lockups). Second - no diffrence with or without. Peter Zubaj Nicolai Haehnle wrote: Same here. All the lockups happen, it just takes them longer. Boris Peterbarg Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
Jerome Glisse wrote: Moreover i see that 9800 are reported to crash with the driver ? Is this still true ? Jerome Glisse Yes, this is still very true. I've just rebuilt xorg, mesa and r300 from cvs. I tested with glxgears and a couple of games. I've got a 9800 pro. glxgears running alone doesn't crash for a long time, but using anything else in parallel (for example firefox) gives me a crash in seconds. Playing neverball or tuxracer doesn't seem to crash at all. armagetron on the other hand has a high possibility to crash, and ut2004demo crashes in no more than 10 seconds. In crash I mean that X, the mouse and the keyboard freeze. Maybe it has something to do with frame rates? Boris Peterbarg --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] R300 DRM unfrozen
Vladimir Dergachev wrote: The old initialization looks like yours, just with the radeon version being 1.12.1 20041216 This would imply that, somehow, you are loading old radeon code. Which command are you using to load it ? Well, I ran make in the linux-core directory, and than copied drm.ko and radeon.ko to /lib/modules.../char/drm. This time I even did a reboot afterwards, to check that everything will work. After the reboot I ran `modprobe radeon`. Try using insmod with explicit path specification - this is what I do. You must have leftover radeon.ko someplace. It seems I did have some leftovers. The new code seems to lock up. I attached the end of the log from tuxracer. best Vladimir Dergachev Boris Peterbarg best Vladimir Dergachev Boris Peterbarg --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel log.gz Description: GNU Zip compressed data
Re: [R300] R300 DRM unfrozen
Vladimir Dergachev wrote: On Wed, 2 Mar 2005, Vladimir Dergachev wrote: On Thu, 3 Mar 2005, Boris Peterbarg wrote: athlon xp 2500+, kernel 2.6.10, xorg cvs from 27/02/05 Yes, I compiled the drivers. xorg loaded them. I'm using udev. With the drm before the changes, /dev/dri/card0 is created. With the new drm it's not. Upon some further thinking: 1) Try updating r300_driver (or checking out a fresh copy - maybe SourceForge lags a little. 2) Check which version of the driver is loading. Did it initialize ok ? My dmesg looks like this: I updated again, but I get only this line on the new drm initialization: [drm] Initialized drm 1.0.0 20040925 The old initialization looks like yours, just with the radeon version being 1.12.1 20041216 Boris Peterbarg --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] R300 DRM unfrozen
Vladimir Dergachev wrote: I finished the update. I suggest checking out a clean copy of r300_driver and trying linux-core. Please e-mail me if anything broke, or if I forgot to check in something. Here something definitely doesn't work drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::03:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card2 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card3 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card4 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card5 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card6 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card7 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card8 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card9 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card10 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card11 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card12 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card13 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card14 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card2 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card3 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card4 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card5 drmOpenDevice: open result is -1, (No such
Re: [R300] R300 DRM unfrozen
athlon xp 2500+, kernel 2.6.10, xorg cvs from 27/02/05 Yes, I compiled the drivers. xorg loaded them. I'm using udev. With the drm before the changes, /dev/dri/card0 is created. With the new drm it's not. Boris Peterbarg Vladimir Dergachev wrote: Hmmm... Which machine, Xserver, etc ? Did you compile and insmod drivers from r300_driver/drm/linux-core ? thank you ! Vladimir Dergachev On Wed, 2 Mar 2005, Boris Peterbarg wrote: Vladimir Dergachev wrote: I finished the update. I suggest checking out a clean copy of r300_driver and trying linux-core. Please e-mail me if anything broke, or if I forgot to check in something. Here something definitely doesn't work drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: open result is -1, (Unknown error 999) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::03:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card2 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card3 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card4 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card5 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card6 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card7 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card8 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card9 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card10 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card11 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card12 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card13 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card14 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -1023 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card2 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result
