Post B4S8vOKHQa1NcGA9uS by q66@gts.q66.moe
(DIR) More posts by q66@gts.q66.moe
(DIR) Post #B49P7hwUEBKZC1gpc0 by q66@gts.q66.moe
1 likes, 1 repeats
it's always fun to see someone with a big endian computer come in and be like "hey this doesn't work and that doesn't work and that doesn't work, how can i make it work"sorry but i'm afraid i don't have the resources, motivation, or interest to track down and fix assorted bugs that there is always a never ending amount of and i get very little out of itwe provide builds of stuff that are mostly built from upstream (with occasionally some patches that haven't made it into a release etc.) and if there is a community of people running these machines that want things to work, well, they need to put in the effort because noone else is going to do it for themand if they don't, it's never going to work wellso i guess it's actually never going to work well because so far i barely see anyone fixing stuff that is not in the interest of niche business cases eg s390x mainframes, on client machines it's only been getting worse and more broken over the yearsmaybe it's time to retire ppc64+ppc in near future
(DIR) Post #B4AdNsiBY3hzk8ZCpE by mirth@mastodon.sdf.org
0 likes, 0 repeats
@q66 Something that requires that level of ongoing testing and diffused code changes seems like it has to be managed upstream. Chimera + QEMU might make some nice tooling to do differential testing but ultimately someone has to decide what platforms they want to support.
(DIR) Post #B4AdNswMhL3ES7CWvY by koakuma@uwu.social
0 likes, 0 repeats
@mirth @q66 On the other hand, upstream are much less likely to care about your causes if you don't show up and do some work on it, however littleThe want is there but the effort is (severely) lacking, many of the folks who state that they want the state of affairs to be better also seem to be unwilling to put the action needed to actually get there, to say it mildly...
(DIR) Post #B4RzaM69cHZP2PRxiq by q66@gts.q66.moe
2 likes, 0 repeats
btw since i announced that i'd be retiring these archs in a few months, the general response has been like "oh, that's sad, i'll have to switch to something else" but no indication that anyone would actually want to help in any waywell have fun switching to something else once all your options are gone
(DIR) Post #B4S3U4aSD4E4o4slWq by karolherbst@chaos.social
0 likes, 0 repeats
@q66 that's going to be fun to watch honestly. Like I'm seeing the same thing happening. Like making GPUs work for big endian is just painful, because most GPUs don't even support it natively.Nvidia used to have a flip to switch the GPU into "big endian mode", but then it didn't do it completely and random things were just broken (mostly modern GL features like mapping GPU memory)And like.. people always start to fix it up and then give up, because apparently it's a full time job 🙃
(DIR) Post #B4S3U4lnWtIfNGBpD6 by q66@gts.q66.moe
0 likes, 0 repeats
@karolherbst well you don't really need native support to get things working but it does mean things are always going to be slower due to needing the driver to handle intermediate buffers to present things in native endian to applications(which also means lots of zerocopy stuff is out, but to the application it *should* still be transparent)i don't think big endian on user devices is really viable anymore (because of this, and fun stuff you wouldn't normally even think of, such as javascript on remote websites now being occasionally endian-dependent due to typed arrays exposing this) but it's still a shame because code makes way more endian assumptions than it really needs to
(DIR) Post #B4S3U4xqo4wPydpRzs by karolherbst@chaos.social
0 likes, 0 repeats
@q66 > i don't think big endian on user devices is really viable anymore Somehow people get really defensive if you say that..but yeah.. nouveau still supports big endian mode on GPUs, I just don't know how broken it is... probably a lot broken, but also.. it's just really low priority to fix any of itBut yeah.. Mesa makes assumption about endian for some vectorization optimization llvmpipe is doing.
(DIR) Post #B4S3U588BrAGUWdf1M by q66@gts.q66.moe
0 likes, 0 repeats
@karolherbst ime nouveau never really worked right, eg. the geforce 6600 in my powermac straight up doesn't boot since some kernel when you try to use it, and when it semi worked, some pixel formats were terribly broken and whatnot, which meant you could run a desktop but not much else without the colors being fucked
(DIR) Post #B4S3U5IlYJfh1Vc9b6 by karolherbst@chaos.social
0 likes, 0 repeats
@q66 yeah.... I think that's related to modern GL features, but also probably weird bugs here and there. I _think_ it's a lot better if the desktop is limited to GL 2.1Though that GPU only supports 2.1 in the first place I think...but also that GPU had bugs that weren't related to big endian..
(DIR) Post #B4S3U5TOumB7YUaeAq by q66@gts.q66.moe
1 likes, 0 repeats
@karolherbst eg i dug up some old pictures back when i was maintaining void-ppc and the kernel still worked (nouveau vs radeon, hd3670 iirc, in a powermac g5)the radeon could do opengl up to 3.3, which is less than on little endian (on LE it exposes afaik 4.1)nvidia was limited to 2.1 but that's just what the hardware can do
(DIR) Post #B4S6e8BG0GxAi6aHvk by q66@gts.q66.moe
1 likes, 0 repeats
i think there are zero gpus that have worked on big endian ppc* with upstream mesa (requiring use of the ancient amber branch) in at least the last two years or so...
(DIR) Post #B4S6lc9AzGzPg1BB6e by fiore@brain.worm.pink
0 likes, 0 repeats
@q66 consoomer mentality
(DIR) Post #B4S6xKolF7d7PEDdia by wyatt@soc.megatokyo.moe
0 likes, 0 repeats
@q66 i see being forced to use debian jessie in my future :(
(DIR) Post #B4S6xL1sSM7c3uM7A8 by evv42@donotsta.re
0 likes, 0 repeats
@wyatt @q66 the more i see of linux, the less i want to work on anything related to it :/the bsds will still be there on the long run i'd guess
(DIR) Post #B4S6xLB5u5UiWUfTWq by q66@gts.q66.moe
1 likes, 0 repeats
@evv42 @wyatt most of what's actually broken is the same on bsd...
(DIR) Post #B4S83FBhBjU3dVKOxc by karolherbst@chaos.social
0 likes, 0 repeats
@q66 not even llvmpipe works perfectly, though I did look into fixing 565 color formats, because VNC needed it with 16 bit resolutions 🙃 and colors were wrong in a _wild_ way
(DIR) Post #B4S83FPANeG8JHd9xQ by q66@gts.q66.moe
1 likes, 0 repeats
@karolherbst tbf llvmpipe only really works on a limited set of archs in the first placethe stuff that first regressed big endian a couple years ago is not specific to any driver though, it was when mike blumenkrantz haphazardly refactored things as a part of the dril work
(DIR) Post #B4S8vNnJP9eLy0jpWS by wyatt@soc.megatokyo.moe
0 likes, 0 repeats
@q66 the radeons in late powerbook g4's? I don't think I'm using amber for those
(DIR) Post #B4S8vO04dhrGbai1Pk by q66@gts.q66.moe
0 likes, 0 repeats
@wyatt well i dunno what version you're using but i do have a late powerbook with radeon 9600 and i can definitely say it's just as broken as the others with current mesa in chimera (i don't remember which version broke it, i think maybe 21? 22? or something, there are issues filed for it etc) and the only way out is a sufficiently old one (we picked amber because it effectively provides support for all gpus that were already working before, and those can be built without llvm dependency)
(DIR) Post #B4S8vOAi0AMh8ZgVzU by wyatt@soc.megatokyo.moe
0 likes, 0 repeats
@q66 tbh i stopped keeping up with updates religiously so it's quite possible nothing i installed recently has required a mesa upgrade.The last few years have been so rotten for so much software on big endian (gnome stuff especially) that I've been running out of steam as well to keep things going.i 100% agree with using amber, even on x86 it's necessary for my old dell latitudes now
(DIR) Post #B4S8vOKHQa1NcGA9uS by q66@gts.q66.moe
0 likes, 0 repeats
@wyatt funnily gnome worked really well on BE at some point, it was the only wayland compositor that could draw without *any* color or other errorsit broke in some version though (don't remember which one, maybe 47 or 48), there were lots of mutter color refactors in that onemost of the stack still works fine, but the desktop itself doesn't
(DIR) Post #B4S8vOUCpfxe72o5Ng by wyatt@soc.megatokyo.moe
0 likes, 0 repeats
@q66 oh, yes, i agree. For a while it was strangely a holdout.But it too fell eventually. now even renPy stuff has colour errors during fade transitions and I'm somewhat sure it's a GDK thing that broke it (could be wrong).
(DIR) Post #B4S8vOdmG5cKajHjIe by q66@gts.q66.moe
0 likes, 0 repeats
@wyatt it was a fairly short period actually, before 40 (i think) it was busted entirely, then got fixedbut either way i don't think they're opposed to fixing it now either, it's just that these days things kinda just break by accident and then noone fixes them, because almost nobody uses it and the community has a massive aversion to using up to date things and reporting or ideally fixing things as they gowhich makes everything pile up to the point where it becomes unmanageable and even those few that try lose any kind of motivation
(DIR) Post #B4S8vOmzhozR3Jb5fM by wyatt@soc.megatokyo.moe
1 likes, 0 repeats
@q66 my experience reporting bugs to gnome is that they say "we aren't working on GTK3 anymore so even your simple two line patch to fix your pen digitizer being seen as a touch screen won't be accepted, get fucked"