2021-08-11.log

- wagga (QUIT: Quit: Client closed) (~wagga@node-1w7jra22ildhvg0963fkd9csj.ipv6.telus.net)01:31
+ jcs (~jcs@jcs.org)01:59
chartreuseNoticed a neat thing with the clear trackball buttons, they flouresce slightly under sunlight, gives them a slight purplish hue02:23
mntmnyeah they respond to UV more than the ones we printed before02:42
dopplerhuh, neat03:14
+ reform10226 (~jamin@2603-8000-b400-1b02-06f0-21ff-fe91-0625.res6.spectrum.com)03:42
* reform10226 -> acdimalev03:42
- acdimalev (QUIT: Client Quit) (~jamin@2603-8000-b400-1b02-06f0-21ff-fe91-0625.res6.spectrum.com)03:43
+ reform26164 (~jamin@2603-8000-b400-1b02-06f0-21ff-fe91-0625.res6.spectrum.com)03:45
* reform26164 -> acdimalev03:46
chartreuseThink I'm going to do my first circuit board level mod. Replacing C127 and C147 47uF ceramics with 100-330uF audio electrolytics (gotta check what I have) to improve the headphone output bass response greatly06:14
chartreuseWith my 24 ohm over-ears 47uF has a cutoff of 150Hz, and with my 16ohm ear buds it's worse at 220Hz06:16
+ chartreu1e (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net)07:45
- chartreuse (QUIT: Ping timeout: 272 seconds) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net)07:49
- chartreu1e (QUIT: Quit: leaving) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net)07:54
+ chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net)08:35
chartreuseOkay well the soldering was a bit sketchy trying to solder some rather large 100uF 16v audio caps I had onto 0603 pads, but it's a massive improvement in sound and bass08:36
chartreuseI've got some better/smaller 220uF 6.3v ones on the way on digikey, didn't think the 0603 pads were big enough for a surface mount electrolytic so got through hole ones again08:37
chartreuseJust going to mount them in much the same way though they should be slightly smaller as well so might fit neater08:37
chartreuseNot like the motherboard can be changed now, but replacing those ceramics with holes for small diameter through hole caps would likely fit in the area. Or possibly some surface mount electrolytics would fit with a little shuffling09:08
ex-parrotNice 09:16
ex-parrotI should do a similar mod09:17
chartreuseMakes a nice improvement even just going up to 100uF. Do be careful if you do do it, it's a small area and the pads will be relatively fragile09:28
chartreuseI don't like MLCC for audio, but another idea could be to stack another 47uF in parallel with the originals09:29
chartreusePosted a picture of the jank on the community forum09:30
- acdimalev (QUIT: Quit: .) (~jamin@2603-8000-b400-1b02-06f0-21ff-fe91-0625.res6.spectrum.com)10:43
chartreuseAlso forcing Firefox to use native wayland makes a large difference if you have a video playing, even when the video is off screen. I tried it a few days ago and I thought I had issues with firefox starting, but trying it again it works just fine. 10:46
chartreuseDoes give different graphical glitches at the moment, sometimes the window flickers transparant when loading a new page10:59
- wiedi (QUIT: Read error: Connection reset by peer) (~wiedi@37.228.191.159)11:51
+ wagga (~wagga@node-1w7jra22ildhybaszosec4fjh.ipv6.telus.net)12:39
- erlehmann (QUIT: Read error: Connection reset by peer) (~erle@dynamic-046-114-036-024.46.114.pool.telefonica.de)13:24
+ erlehmann (~erle@dynamic-046-114-032-213.46.114.pool.telefonica.de)13:37
mntmnchartreuse: i saw your mod, cool cool13:41
mntmnchartreuse: and yes, i got the same flickering @ firefox with forced layer acceleration13:41
- wagga (QUIT: Quit: Client closed) (~wagga@node-1w7jra22ildhybaszosec4fjh.ipv6.telus.net)13:42
mntmnchartreuse: in the forum i wrote about this once > My unconfirmed intuition is that the glitches are some CPU/GPU buffer sharing problem. I discovered that setting dom.ipc.processCount to 1 instead of the default 8 greatly reduces the problem13:42
mntmnchartreuse: (if you have layers.acceleration.force-enabled = true)13:42
chartreuseI've already got the ipc count down to two. I had a slightly different glitchiness (rarely) before forcing wayland, though after this happens almost every time I change pages13:50
chartreuseI do have the layers acceleration force enabled at the moment. 13:51
chartreuseThe main difference was forcing wayland with MOZ_ENABLE_WAYLAND=1, which made certain things way faster but added quite a bit of flickering in places13:51
chartreuseGoing to try looking into the errors given on startup: Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: DRM device has no render node (t=0.891441) [GFX1-]: glxtest: DRM device has no render node13:53
chartreuseAnd a couple others13:53
mntmnchartreuse: i think those errors are irrelevant13:55
mntmnchartreuse: the bugs you are seeing are probably mesa/etnaviv bugs related to buffer sharing13:55
chartreuseOkay turning off the layers force acceleration got rid of the flickering, and is still running faster than when I had it on but on xwayland (the default)13:56
chartreuseAlright13:56
mntmnchartreuse: i recorded the session with apitrace (incl glitches), but when playing it back, the glitches are gone13:56
chartreuseHmm alright13:56
mntmnso it's complicated13:56
chartreuseI've seen reports of old sway issues that sound similar, though they've long been fixed13:57
mntmnthere is an interesting mesa PR that we should test soon https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/978013:57
mntmnchartreuse: yeah that's true, these kind of issues can also happen on other GPUs13:58
mntmnand it's often different stuff/causes that look similar13:58
mntmnwlroots/sway have also made bigger changes in the meantime, but we're on a bit older/more stable version. updating always needs good testing13:58
chartreuseI haven't looked much into it besides trying to enable it, but Firefox also has the WebRender as well, rather than trying to make the OpenGL renderer (layers.accelleration) work 14:01
chartreuseForce enabling webrenderer results in dozens of similar errors to the drm device ones as well as failing to create GL contexts14:04
mntmnyeah, unfortunately webrender needs some futuristic OpenGL version that we don't have ;)14:05
mntmn3.2 or something14:05
mntmnyou can try setting MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE but idk which features are missing that firefox needs14:06
mntmnfor example MESA_GL_VERSION_OVERRIDE=3.3 and MESA_GLSL_VERSION_OVERRIDE=33014:06
chartreuseAh of course that makes sense14:07
mntmnwe have the same problem with blender 2.80+14:07
mntmnthat's why i ship a special build of 2.79b14:07
chartreuseIt's wanting GLSL 1.5 so failing on that error: GLSL 1.50 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES14:07
mntmnyou can try MESA_GLSL_VERSION_OVERRIDE=15014:08
- erlehmann (QUIT: Quit: Just say no, then the virus can not enter your body without your consent.) (~erle@dynamic-046-114-032-213.46.114.pool.telefonica.de)14:08
+ erlehmann (~erle@dynamic-046-114-032-213.46.114.pool.telefonica.de)14:08
mntmnthe compiler frontend can handle any version but the question is if all required ops are supported by etnaviv14:08
chartreuseAnd now it just gives up:14:08
chartreuseUnhandled NIR tex src type: 314:08
chartreuseUnhandled NIR tex type: 414:08
chartreuseand segfaults14:08
mntmnah very interesting though14:09
mntmnso this tells us that they use unsupported texture types14:09
chartreuseIt repeats that 11 times and that's the only error (besides the same 3 DRM ones it always has)14:09
mntmnthe error comes directly from etnaviv:14:10
mntmn> gallium/drivers/etnaviv/etnaviv_compiler_nir.c:         compile_error(c, "Unhandled NIR tex src type: %d\n",14:10
mntmnthe unsupported tex src type is "nir_tex_src_offset"14:12
mntmn> An integer value that is added to the texel address before sampling14:12
chartreuseI would have thought mesa would be what's handling this rather than the kernel gpu driver. Or is that path in mesa?14:15
mntmnthat is a path in mesa14:16
mntmnthe "gallium" drivers handle the command buffer construction in mesa14:16
mntmnso that is the userspace part of the driver14:16
mntmnthat gets sent to the kernel, the kernel driver does more low level plumbing and buffer/memory handling of the gpu14:16
chartreuseMesa 21.0.0's patch notes make mention of nir_tex_src_offset "zink: use ConstOffset for nir_tex_src_offset"14:17
mntmnzink is an opengl implementation on top of vulkan14:18
mntmnso if you have a working vulkan driver you can "emulate" opengl on it with zink14:18
mntmnwe do not have vulkan though14:18
chartreuseDebian's mesa is 20.3.514:18
chartreuseAh okay14:18
mntmnthe "Unhandled NIR tex type: 4" is    nir_texop_txf,                /**< Texel fetch with explicit LOD */14:18
mntmnso etnaviv doesn't know what the TXF instruction is14:19
chartreuseiMX 8M fact-sheet lists vulcan support for the gpu, is it a matter of there not being an open or linux driver for it?14:20
mntmncorrect14:20
mntmnthe etnaviv driver is written by reverse engineering the vivante blob driver14:21
mntmnchartreuse: i wrote about this once https://www.crowdsupply.com/mnt/reform/updates/graphics-improvements-4k-hdmi-and-proper-kicad-support#2-early-z-bug14:21
mntmnlike, how reversing a single feature could be done14:22
mntmn(this earlyz and alpha test stuff is all fixed in the meantime)14:22
mntmnso, one writes a GL test case that is supposed to trigger the feature you want to see, and run that on the vivante blob driver, and then dump the command buffers and examine them if you find anything different14:23
mntmnso for example to support the TXF instruction (if it exists on the vivante gpu) one would make a minimal openGL program containing this instruction and look at what the blob does14:24
+ erle (~erle@dynamic-046-114-038-151.46.114.pool.telefonica.de)14:25
- erlehmann (QUIT: Killed (NickServ (GHOST command used by erle!~erle@dynamic-046-114-038-151.46.114.pool.telefonica.de))) (~erle@dynamic-046-114-032-213.46.114.pool.telefonica.de)14:25
mntmnchartreuse: these two errors are related, first it sets up the coordinate it wants to read from the texture and then it wants to read a pixel/texel from the texture.14:26
* erle -> erlehmann14:26
chartreuseAlright I'll look into that. Going to take some getting up to speed on my part on GL programming and driver development14:26
chartreuseHopefully not going to end up fixing that and it just then presents some unfixable error after14:27
mntmnrelated https://github.com/servo/webrender/blob/5aa779686d3b56c1b74ecb5df171a73c235c691f/webrender/res/base.glsl#L1814:28
mntmnwell adding new ops etc to etnaviv is always extremely desirable, because support for new GL versions is mostly a collection of supporting new ops...14:28
mntmnsee also https://mesamatrix.net/14:29
chartreuseOkay so a lot missing compared with other drivers mainstreamed14:34
mntmnyeah but this doesn't show OpenGL 2.1 or GLES 2 which are fully supported14:36
- chartreuse (QUIT: Quit: leaving) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net)15:15
+ wiedi (~wiedi@37.228.191.159)18:05
- S0rin (QUIT: Ping timeout: 268 seconds) (~S0rin@user/s0rin)22:10
+ S0rin (~S0rin@user/s0rin)22:13
+ chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net)23:24
+ ephase (~ephase@2a01:e0a:168:1211::885)23:29
ephaseHi23:36
chartreuseHello23:40
ephasehow are you chartreuse?23:44
chartreuseDoing alright still slowly getting used to the reform. You?23:47
ephaseThe same, I'm finishing wrinting an article about it23:59

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!