00:00Kayden: the problem with i915 is that both drivers are crap
00:00Kayden: they have a venn diagram of piglit results
00:00Kayden: both crash I believe
00:00Kayden: i915g is way slower than i915c at some things
00:01Kayden: i915c is way slower than i915g at some things
00:01mareko: i915g now crashes always
00:01Kayden: oh, again?
00:01tarceri: Kayden: It would have been much easier to do my refactoring last year without those classic drivers around https://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=r200 00:01mareko: Kayden: hopefully this time nobody will fix it
00:01Kayden: my job would be much easier too if I stopped caring about other hardware
00:01tarceri: I wouldn't be hugely surprised if they were broken and noone noticed
00:02airlied:rebooted his 945 the other day
00:03mareko: tarceri: I guess the outcome of the discussion is that no classic drivers are going to be removed now, you can try it next year
00:03krh: Kayden: sometimes that's a reasonable tradeoff
00:04Kayden: having worked on meta code that's trying to be shared between i965/gen8+ and r200...it was miserable.
00:04Kayden: honestly I think I'd be fine with those drivers fading off into the sunset
00:04Kayden: I'm just saying I haven't heard a compelling argument for doing it.
00:05Kayden: "it doesn't even do DRI2" was pretty darn compelling
00:05Kayden: you couldn't even run a compositor properly
00:05airlied: esp when dri1 meant ums
00:05Kayden: that too
00:06mareko: radeon and r200 are pretty old though, r200 is much older than i915 I think
00:06mareko: same for classic nouveau
00:06Kayden: and they aren't even full GPUs
00:07tarceri: Kayden: my sole argument is "I'm about to make another update that required me to either update or hack around hardware I don't own and is pretty much not in development" and that was enough for me
00:07tarceri: if that's not go enough I'll just move on and hopefully not break anything
00:08robclark: tarceri, well, I guess we can always branch mesa-ancient-drivers off of an older commit in mesa.. if you break the old driver and no one notices for 6mo then that is one more argument ;-)
00:08mareko: tarceri: you can also send a proposal for driver removal to mesa-dev and see what happens
00:29airlied:can confirm i915 segfaults on clears
00:34airlied: looking for a fragment shader when none are bound
00:39MegWATTT: The breakage of i915g should be recent. It was fine on mesa 17.0
00:43robclark: well 17.0 branch-point is nearly 5 months ago.. I mean I guess that is "recent" in some time scales.. but it was a while ago..
00:45MegWATTT: From an old hardware point of view, it might be considered as recent
00:47tarceri: proposal sent, lets see what people think :)
00:48robclark: sure.. although from an old hw PoV you might want the option of a driver that is not broken when you upgrade to new version of distro.. I mean it isn't straightforward, the tradeoff comes between risk of breaking old drivers and not noticing till it is too late vs potential duplicate maintenance for upgraded dependencies (which mesa has few), compiler versions, CVEs (which I guess few)..
00:55airlied:wonders what broke it, it really hasn't seen a lot of commits
00:56airlied: ah probably mesa state updates changes
00:57airlied: okay one revert and I think gears is working
00:58tarceri: airlied: my proposal was to stop working on old driver not start :P
00:59tarceri: what is the most recent version of opengl r300 supports?
00:59airlied: on r500 hw GL2.1
00:59MegWATTT: tarceri: btw, you forgot NV30 in your proposal
00:59MegWATTT: airlied: 2.1 on R300 too
01:00tarceri: MegWATTT: right, thanks
01:00airlied: oh indeed
01:02airlied: been broken since e027935a795ecf546f3e4abcc25655766f9615ac
01:03tarceri: MegWATTT: NV30 is that a gallium driver
01:03MegWATTT: tarceri: yes
01:04tarceri: Is that 2.0/1 too?
01:07MegWATTT: tarceri: Not totally sure, but I think it's 2.1 on NV4x and 1.5 on NV3x
01:32airlied: oops said it on wrong channel
01:32airlied:wonders if I should walk upstairs to make sure i915g is rendeirng
01:32airlied: anyways I should go do something more productive
01:36MrCooper: mareko: FWIW, there can be GPU bottlenecks for draw call throughput as well
01:37MrCooper: Frogging101: my question about the shader cache zlib thing is, why do the symbols get resolved to the copy statically linked into the app, and can we do something about that?
01:38Frogging101: I don't know, and the only solution I found was to statically link zlib to mesa
01:39MrCooper: not a good solution
01:40Plagman: dlopen zlib with LOCAL?
01:40airlied: zlib would need symbol versioning
01:40Plagman: if the game statically linked zlib and exports its symbols, it could be argues its build system is buggy
01:42MrCooper: right, but maybe we can be more robust wrt that
01:44Plagman: it's another one of these things that would be solved by the bubblewrap steam runtime ™ⓇⒸ
01:46MrCooper: sounds good; is that in any way related to Endless' Steam flatpak?
01:46Plagman: no, i don't know what that is but i suspect it doesn't solve much
01:47Plagman: the idea is just to recreate the fs view of the app with namespaces before it runs
01:47Plagman: such that it doesn't see anything from the host, just from the runtime (which it was built against, so that much makes sense)
01:48MrCooper: that doesn't directly affect symbol resolution though, does it?
01:48Plagman: and for any host libraries that we have to pick up, we pick them up from a mounted copy of the host on the side, like /host
01:48Plagman: and dlmopen through libcapsule, which is something we wrote specially for this
01:48Plagman: https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/ 01:49Plagman: there's still a lot of work but the collabora guys are running glxgears punched through an environment like that now
01:49Plagman: (they wrote the library too; collective we)
01:50Plagman: so in the case you're talking about the two zlibs should be completely disjoint
01:50Frogging101: <Plagman> such that it doesn't see anything from the host, just from the runtime (which it was built against, so that much makes sense)
01:50Frogging101: What about libGL and the things it is compiled against?
01:50Plagman: read after
01:51Frogging101: mm, right
01:51Plagman: that's definitely the whole point, being able to isolate all of libGL's stuff from the app'sruntime
01:52MrCooper: hmm, would it also help if the zlib symbols are in the game executable itself?
01:53Plagman: i would hope so
01:53Plagman: the game executable and its symbols would be in the default loader namespace
01:53Plagman: all of libGL's stuff and everything libGL depends on wuold be in a new loader namespace
01:53Plagman: and the only view through that would be libGL's exported API
01:54Frogging101: And this wouldn't require explicit support from games?
01:54Plagman: they would just think they're running in a steam runtime "chroot", and their libGL would be funky
01:54Frogging101: aside from being built against the "standard" runtime, anyway
01:55Plagman: even if it wasn't actually built against it, as long as it run in it, the idea is that if a dev tests it there, they should at least have confidence it's not going to randomly break depending on the host environment
01:55Frogging101: that is important
01:55Plagman: that was the point of the runtime to begin with and it did a lot of that
01:55Plagman: eg. you didn't see all games on steam break when distros switched from udev 0 to udev 1
01:55Plagman: which was good
01:55Plagman: but it was a bit primitive in its execution
01:56Plagman: of course the runtime wouldn't be required if every dev was a linux packaging expert that included all the dependencies it didn't statically link, etc
01:56Plagman: but i don't think that's a reasonable ask
01:57Frogging101: that's basically what is done on windows though, isn't it
01:57Plagman: there's os runtimes too that are registered through the sxs system
01:57Plagman: like all the c++ runtimes, dx runtimes, etc
01:57Plagman: the sxs system being basically like a very fine grained versioning for libraries
01:59MrCooper: well, I saw Steam itself break many times due to udev 1 vs 0 :) But this seems a thing of the past with the recent change to how runtime vs host libraries are handled
01:59Plagman: Frogging101: for random third party libraries though, people do build them and put them in their steam depots yeah
01:59Plagman: MrCooper: because you disabled the runtime, surely
01:59Frogging101: Sorry if this is too many questions, but what of updates to the steam runtime? is the runtime versioned?
01:59Plagman: because otherwise it wouldn't even start because of libstdc++ on both ends
02:00Frogging101: so that old games don't break if something changes?
02:00Plagman: Frogging101: the runtime is technically versioned, although there is only one version currently and all games on steam use that one
02:00MrCooper: Plagman: I could swear it happened even before I tried that; I might misremember though, and anyway doesn't matter anymore
02:00Plagman: Frogging101: it's always been updated in a backwards compatible way so far
02:01Plagman: eg. when devs need new versions of stuff, we make sure it doesn't break older games
02:01chrisf: Plagman: the udev thing was a nightmare on arch at least-- are you suggesting that arch did something lame with the packaging of steam?
02:01Plagman: i think they just disable the runtime across the board
02:02Plagman: at least they used to
02:02Plagman: now they have something cooler, which is 'steam-native-runtime'
02:02Plagman: which means that they rebuild every library from the runtime against their distro
02:02Plagman: which is great
02:02Plagman: but it used to be that steam on that platform would just start 'naked' because of the libstdc++thing affecting open driver users
02:03Plagman: which i assume they cared about more than other distros and motivated that choice
02:03Plagman: so users would be on their own when it comes to resolving dependencies of games
02:03Plagman: and udev 0 is probably the first thing that screws you in that situation
03:55padovan: seanpaul: ok, I'll push them all.
03:59mrc3: xexaxo1, i submitted a few patches some days ago. shall i send a pingmail about them if they look all right? re: piglit and surfaceless mesa
08:33danvet_: airlied, https://patchwork.freedesktop.org/patch/158340/ 08:33danvet_: good enough?
08:33danvet_: I hope it passes the angry gregkh stable checker bots