<_whitenotifier-9>
[solvespace] BrettDikeman commented on issue #376: Please issue a release. - https://git.io/fjOQx
mauz555_ has quit [Remote host closed the connection]
balrog has quit [Quit: Bye]
balrog has joined #solvespace
<_whitenotifier-9>
[solvespace] whitequark commented on issue #376: Please issue a release. - https://git.io/fjO7T
<_whitenotifier-9>
[solvespace] whitequark edited a comment on issue #376: Please issue a release. - https://git.io/fjO7T
<_whitenotifier-9>
[solvespace] whitequark unassigned issue #240: In certain lathe groups, triangle normals get flipped - https://git.io/fjO7G
<_whitenotifier-9>
[solvespace] whitequark commented on issue #240: In certain lathe groups, triangle normals get flipped - https://git.io/fjO7Z
<cr1901_modern>
It's a pity, but I say discontinuing OS X support is the correct decision in light of Apple's insistence of a walled garden. Not to mention Vulkan (well modern gfx really) is horrifying
<whitequark>
Vulkan maybe makes some sense to support
<whitequark>
Metal, nope
<cr1901_modern>
My laptop is too old to run Vulkan so I haven't spent much time looking into it
<whitequark>
hm, does it run solvespace fine then?
<cr1901_modern>
Sure, solvespace itself works wonderfully
<whitequark>
so in principle if i use ANGLE as a backend on every platform, it'd be possible to use solvespace on d3d, vulkan and opengl platforms
<whitequark>
it's not a super excellent idea for a variety of reasons
<whitequark>
but it does have a number of benefits even beyond that
<cr1901_modern>
Oh I'm sure there's a bunch of tradeoffs, and I'm only one sample point, but I've never had any trouble w/ Solvespace _running_ using ANGLE (compilation is still a bit fucky so I have to cross compile, but that's not a big deal)
<swivel>
both my x61s and x220 are too old for vulkan but run solvespace just fine. If solvespace went pure vulkan it would alienate a substantial swath of classic GL-capable thinkpads w/integrated graphics
<cr1901_modern>
^This is also my use case
<cr1901_modern>
My mainboard on my Thinkpad has been replaced once. I _suspect_, but can't prove, that using discrete gfx only shortened the life of the mainboard. So I switched to integrated after the mainboard replacement. Going on 4.5 years without problems.
<whitequark>
swivel: yeah, I was under impression that vulkan is more compatible than that
<cr1901_modern>
I still have to use Optimus for dual monitor (b/c Lenovo didn't pass thru the integrated gfx to the external monitor), but I'm quite alright w/ someone saying "you're on your own" in that scenario
<cr1901_modern>
Optimus doesn't really work anyway
<whitequark>
since there's no way i would maintain *both* the OpenGL and Vulkan backends it leaves ANGLE as the only option
<whitequark>
kind of depressing, really
<whitequark>
cr1901_modern: optimus works very well for me, and did for a long time
<whitequark>
i use bumblebee with my thunderbolt egpu setup
<whitequark>
wait, you mean on windows, do you
<cr1901_modern>
yes
<whitequark>
cr1901_modern: btw, you don't NEED to use ANGLE with SolveSpace on Windows
<cr1901_modern>
Oh, I didn't know that
<whitequark>
if you have your vendor's OpenGL drivers it will work just fine without ANGLE
<whitequark>
but we can't redistribute a single binary because if you *don't* have your vendor's OpenGL drivers all I get is OpenGL 1.2
<whitequark>
which is too old
<whitequark>
it would definitely work better without ANGLE
<whitequark>
in terms of performance
<cr1901_modern>
>binary because if you *don't* have your vendor's OpenGL drivers all I get is OpenGL 1.2
<cr1901_modern>
What's wrong w/ requesting a specific openGL version and dying if the user doesn't have it?
<cr1901_modern>
(to distribute a single binary)
<whitequark>
cr1901_modern: because then everyone who just installed windows on their PC gets fucked
<whitequark>
without downloading the junk from nvidia website
* cr1901_modern
nods
<whitequark>
microsoft redistributes the directx drivers itself but not opengl ones for the same GPUs
<whitequark>
because no one likes opengl
<cr1901_modern>
So, I can't speak for swivel, and all things being equal, I would prefer GL support be kept in, but when Windows 7 reaches EOL early next year I will likely upgrade my hardware
<swivel>
whitequark: to be fair the intel devs on #intel-gfx said at least the x220 class machine could be supported if someone developed drivers (on linux), they just don't have the resources to bother.
<cr1901_modern>
either that or: get a new hard drive and max out the RAM, and then use this laptop til it dies (which was the original plan)
<whitequark>
swivel: i mean, people still complain that i don't support *Radeon R600*
<whitequark>
it'd be literally cheaper for me to give him enough money to buy a real GPU instead of fixing those bugs
<cr1901_modern>
whitequark: I'm still waiting for Hercules support... you run the Console on your CGA monitor and the model is displayed on the monochrome monitor
<whitequark>
cr1901_modern: that's doable
<whitequark>
like, unironically
<swivel>
llvmpipe
<cr1901_modern>
Really? ._.
<whitequark>
the macos vm i use uses the software renderer, linux can do it too with llvmpipe
<whitequark>
yep
<dalias>
isn't anyone doing a libGL that just translates to apple's new idiotic thing?
<whitequark>
it's not idiotic
<whitequark>
it's far less idiotic than libGL
<dalias>
well it's idiotic that it's gratuitously incompatible and that they dropped support for the only portable api
<cr1901_modern>
Would've figured that Linux drivers didn't expose the CGA/Hercules memory spaces
<whitequark>
the problem is that instead of going with vulkan they went with their own thing, which i can't blame them for either because vulkan didn't exist then
<dalias>
vulkan seems also worse -- harder to program for, only helpful to gaming type applications, harder to emulate on top of other APIs since it's lower level
<whitequark>
dalias: Metal dates back to 2014, Vulkan to 2016
<dalias>
the opengl api is of course bad
<cr1901_modern>
Okay, that _does_ put some perspective on things (while the end result still stinks)
<whitequark>
Vulkan isn't an OpenGL replacement
<dalias>
but a higher-level replacement that doesn't suck would be preferable to lower-level ones
<whitequark>
Vulkan : OpenGL :: syscalls : libc
<dalias>
what is it then? that was my impression
<whitequark>
we do need something like vulkan, and it was never intended to be something that applications would use directly
<whitequark>
it is an OpenGL replacement in the sense that graphics drivers would expose it instead of OpenGL
<dalias>
if it's just a layer between libGL and the hardware, that's not so bad
<cr1901_modern>
>it was never intended to be something that applications would use directly <--unless you're a game programmer or just downright curious (nothing wrong w/ that IMO)
<whitequark>
it's basically moving the GL state tracker from the graphics drivers and into your application, which is unquestionably a good idea, because GL state tracker sucks
<dalias>
but it seems like it's been marketed for direct use by games....
<swivel>
it's what OpenGL should be implemented on top of in the future, if it continues to exist
<cr1901_modern>
The Vulkan tutorial website even says "being curious and for fun is a decent reason to learn Vulkan"
<whitequark>
cr1901_modern: most applications
<whitequark>
something like solvespace is definitely not intended to be programmed against vulkan
<whitequark>
or even something like team fortress 2
<cr1901_modern>
ahhh
<whitequark>
a game *engine* might use it directly
<whitequark>
unfortunately, no one implemented usable OpenGL on top of Vulkan, because OpenGL fucking sucks
<whitequark>
looks like the Mesa project did that a few months ago
<whitequark>
which is unsurprising, Mesa is uniquely positioned to do so
<cr1901_modern>
My biggest exposure to "OpenGL fucking sucks" was how the glium writer threw in the towel when they realized that drivers just don't implement the spec correctly and are bug ridden (or perhaps the spec is bug-ridden)
<whitequark>
all of the above
<cr1901_modern>
The majority of their time was spent coding workarounds so drivers didn't crash (in an effort to expose a safe API). I don't blame them for needing to step down. But, like you said, it's depressing that this is the current state of affairs.
<cr1901_modern>
whitequark: What is Bumblebee besides a cute pun?
<whitequark>
cr1901_modern: optimus for linux
<whitequark>
well, the software package
<cr1901_modern>
Oooooh! Okay, for some reason I thought Linux provided the driver for that as a proprietary module
<whitequark>
nope, it's all open-source, except the actual GPU driver
<whitequark>
i mean
<whitequark>
you technically can use nouveau, i don't know why you would want to
<whitequark>
my use of bumblebee is kind of boneless bc i only use the render offload capabilities
<whitequark>
no actual power state switching, because well, it's just pcie
<cr1901_modern>
It's pretty cool you can run discrete gfx across a cable like that, even _after_ understanding how fault tolerant pcie is
<whitequark>
indeed bc fault tolerance is not enough
<whitequark>
i want performance
<whitequark>
i want 60 fps on my 3k screen with framebuffer transfers
<whitequark>
(i get ~50 fps)
<whitequark>
(mostly because dell cheaped out and i only get a PCIe x2 link to the TBT contrller, not x4)
<swivel>
i did something similar with my x230; RX480 egpu attached through an mpcie dock
<swivel>
but it effectively turns the machine into a desktop
<whitequark>
that's why i use render offloat
<whitequark>
*offload
<whitequark>
i can just unplug it and go wherever
<whitequark>
surprise unplug can get the blob driver confused but i patched it to work around that, now it just leaks memory instead
<whitequark>
which is okay
<dalias>
re: mesa & gl on vulkan we were just talking about this on #musl
<dalias>
our interest is getting driver fully out of application core
<dalias>
so you can ship static binaries
<swivel>
whitequark: well in my case it's more because the the dock is wired to an internal mpcie socket so there's a cable snaking out from under the palmrest on one side, requires disassembly to fully remove
<_whitenotifier-9>
[solvespace] whitequark commented on issue #347: Build an AppImage targeting Xenial - https://git.io/fjO7y
<whitequark>
dalias: fully out?
<_whitenotifier-9>
[solvespace] whitequark commented on issue #376: Please issue a release. - https://git.io/fjO7H
<dalias>
yeah
<dalias>
my interest is also privsep
_whitelogger has joined #solvespace
<_whitenotifier-9>
[solvespace] probonopd commented on issue #347: Build an AppImage targeting Xenial - https://git.io/fjO56
<_whitenotifier-9>
[solvespace] whitequark commented on issue #347: Build an AppImage targeting Xenial - https://git.io/fjO5i
<_whitenotifier-9>
[solvespace] probonopd commented on issue #347: Build an AppImage targeting Xenial - https://git.io/fjO5P
<_whitenotifier-9>
[solvespace] probonopd edited a comment on issue #347: Build an AppImage targeting Xenial - https://git.io/fjO5P
<_whitenotifier-9>
[solvespace] probonopd edited a comment on issue #347: Build an AppImage targeting Xenial - https://git.io/fjO5P
<_whitenotifier-9>
[solvespace] whitequark commented on issue #347: Build an AppImage targeting Xenial - https://git.io/fjO5X
<_whitenotifier-9>
[solvespace] probonopd opened pull request #396: Add a lookup for ../share/solvespace - https://git.io/fjO5Q
<_whitenotifier-9>
[solvespace] CLAassistant commented on pull request #396: Add a lookup for ../share/solvespace - https://git.io/fjO57
<_whitenotifier-9>
[solvespace] probonopd edited pull request #396: Add a lookup for ../share/solvespace - https://git.io/fjO5Q