Oregon, US



Last active 9 months ago


Last active 1 year, 4 months ago


Last active 2 years ago

#292 Older intel CPU vulkan corruption a month ago

Comment by ~craftyguy on ~eliasnaur/gio

On Thu, 14 Oct 2021 23:04:41 +0000 ~eliasnaur outgoing@sr.ht wrote:

Setting GIORENDERER=forcecompute should enable the compute renderer.

Ah, so it does not happen if I set GIORENDERER=forcecompute.

#292 Older intel CPU vulkan corruption a month ago

Comment by ~craftyguy on ~eliasnaur/gio

yes, there's the same warning about Ivy Bridge (since I'm still using that GPU). My comment about Haswell was actually that Haswell and earlier aren't fully compliant with vulkan, but ANV in Mesa will try anyways even though things might not work as expected.

I could not reproduce this issue on my other system with a Coffee Lake / gen9 GPU, which does actually support vk 1.2. I don't know if "the gpu is not vk conformant" is actually the problem here or not with this particular issue, but I generally still think you might want to ignore vulkan (and use GL) on these intel gpus that don't fully support vulkan...

Anyways, I'm not sure how to test the compute renderer... is there a simple 'hello world' for that I can build/run?

#287 don't use vulkan on intel gpus with incomplete support for it a month ago

Comment by ~craftyguy on ~eliasnaur/gio

Sounds good to me, thank you for the quick fix!

Also, thanks a lot for the detailed explanation and sharing your skepticism. I think I agree with your assessment :)

#287 don't use vulkan on intel gpus with incomplete support for it a month ago

Comment by ~craftyguy on ~eliasnaur/gio

I wasn't able to reproduce the crash after trying ~20 times (before it would happen about once every 3-5 attempts), so it's either solved or a lot more stable :)

I still think you might want to query the conformance version and fallback to GL if it's < I believe some other drivers set it to 0 when a gpu partially supports vulkan, and I hope to land a patch soon in mesa to do the same for the intel driver. Unless you plan to drop GL support entirely, it doesn't seem worth risking possible breakage due to incomplete vk support in the GPU when GL probably works perfectly fine instead (ignoring for a moment that this particular failure was not because of that :D)

#287 don't use vulkan on intel gpus with incomplete support for it a month ago

Comment by ~craftyguy on ~eliasnaur/gio

On Fri, 08 Oct 2021 21:49:09 +0000 ~eliasnaur outgoing@sr.ht wrote:

The crash is a Go panic, so I'm curious what causes that not to be caught earlier.

I can try to provide that info, but I'm not entirely sure how to get it yet.

I'd like the backend choice to be deterministic, but from your MESA patch it sounds like we need ugly string matching on the device string.

Well, without the mesa patch, you'd do ugly string matching, or querying vk features (I'm not sure if there are features that these older gpus don't support, that would be reliable to query...).

With the patch, you should be able to query the vk conformance version using the vulkan API, without any ugly string matching: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkConformanceVersion.html

#287 don't use vulkan on intel gpus with incomplete support for it a month ago

Comment by ~craftyguy on ~eliasnaur/gio

On Fri, 08 Oct 2021 07:58:30 +0000 ~eliasnaur outgoing@sr.ht wrote:

You're probably right, but how can Gio tell the difference?

The anv driver in Mesa has a check in it, which is responsible for generating the warning I mentioned earlier: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/vulkan/anv_device.c#L770

So it turns out that the Intel vk driver advertises vk conformance on any gpu that can successfully init a vk device, even if the gpu is technically not conformant. My naive attempt to fix that is here:


Then you should just be able to query the conformance version, and use vk if it != 0.

Can you help track the source of that nil value? That may reveal a missing error check that allow us to fall back to GL.

Hmm, I'm not sure that would work. The crash is intermittent, most of the time it works, so then gio would intermittently use GL vs VK on some gpus if that nil value showed up. Seems like you'd want the choice of backend to be more deterministic?

#287 don't use vulkan on intel gpus with incomplete support for it a month ago

Ticket created by ~craftyguy on ~eliasnaur/gio

Intel GPUs older than haswell / Gen7 do not have complete support for vk 1.0. I suspect this is why I get random crashed in Gio on my Ivy Bridge laptop (using a gen6 gpu):

❯ go run .
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
panic: interface conversion: driver.Texture is nil, not *vulkan.Texture

goroutine 20 [running, locked to thread]:
gioui.org/gpu/internal/vulkan.(*Backend).BeginRenderPass(0xc00043c000, {0x0, 0x0}, {0xa, {0x0, 0x0, 0x0, 0x0}})
        /home/clayton/go/pkg/mod/gioui.org@v0.0.0-20211006074027-3c34a39d88bc/gpu/internal/vulkan/vulkan.go:985 +0x288
gioui.org/gpu.(*gpu).frame(0xc0003ca000, {0x0, 0x0})
        /home/clayton/go/pkg/mod/gioui.org@v0.0.0-20211006074027-3c34a39d88bc/gpu/gpu.go:432 +0x384
gioui.org/gpu.(*gpu).Frame(0xc0003ca000, 0x10, {0x0, 0x0}, {0x2, 0x0})
        /home/clayton/go/pkg/mod/gioui.org@v0.0.0-20211006074027-3c34a39d88bc/gpu/gpu.go:390 +0x48
gioui.org/app.(*Window).render(0xc000080800, 0x70, {0xc00019c0c0, 0x1})
        /home/clayton/go/pkg/mod/gioui.org@v0.0.0-20211006074027-3c34a39d88bc/app/window.go:215 +0x11b
gioui.org/app.(*Window).validateAndProcess(0xc000080800, {0xc0000c7e30, 0x1, 0xc94f40}, {0x0, 0x1}, 0x0, 0x0)
        /home/clayton/go/pkg/mod/gioui.org@v0.0.0-20211006074027-3c34a39d88bc/app/window.go:181 +0x3e5
gioui.org/app.(*Window).run(0xc000080800, {0xc0000d41c0, 0x4, 0x4})
        /home/clayton/go/pkg/mod/gioui.org@v0.0.0-20211006074027-3c34a39d88bc/app/window.go:579 +0x59c
created by gioui.org/app.NewWindow
        /home/clayton/go/pkg/mod/gioui.org@v0.0.0-20211006074027-3c34a39d88bc/app/window.go:118 +0x42f
exit status 2

Gio should use GL on these older GPUs instead of trying to use vulkan.

#285 Scrollbar missing on flexed content with ridid siblings a month ago

Comment by ~craftyguy on ~eliasnaur/gio

It doesn't seem to be limited to rigid children, if there's any second child in the flex with the flexed that contains the list, the list won't show scrollbars.

I narrowed it down to layout.Flex{ Alignment: layout.Middle }, if the alignment is set to the default, the scrollbar shows up.

Unfortunately I don't know how to build gio from source and configure Go to use it in order to poke around more... (are there instructions somewhere on how to do that?)

#248 Mechanism for autostarting arbitrary group of apps 7 months ago

Comment by ~craftyguy on ~mil/sxmo-tickets

XDG autostart spec: https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html

I found some implementations of this that might be good to use here:

xdg-autostart (very few dependencies, but written in vala.....): https://github.com/fabriceT/xdg-autostart

i3-autostart (written in go...): https://github.com/cking/i3-autostart

Fluxbox xdg autostart app (might be too specific to fb?): https://github.com/paultag/fbautostart

xdg-autostart-launcher (claims no external dependencies, written in C++): https://github.com/sandsmark/xdg-autostart-launcher

dex (python...): https://github.com/jceb/dex

Rather than writing a new tool for this, maybe one of these would work? (or something else I haven't found in the ~30min I searched around)

#248 Mechanism for autostarting arbitrary group of apps 7 months ago

Ticket created by ~craftyguy on ~mil/sxmo-tickets

It looks like all of the things that sxmo needs to run on startup are launched in sxmo_xinit.sh, which is fine for the sxmo essentials.

However, some devices (librem 5) need some extra apps running (e.g. wys for routing call audio). In other UIs in pmOS, we put a .desktop link to those in /etc/xdg/autostart, and those UIs honor the xdg autostart spec. Has there been any thought about having a utility in sxmo that would autostart things according to the xdg autostart spec too, so that distros (like pmOS) that install apps that some devices need to be running on startup could do that without having to make changes to sxmo_xinit.sh each time?