00:38espes__: mwk: btw still think NV25 ~= NV2A?
00:39imirkin_: anything to indicate otherwise?
00:40espes__: i have no idea
00:40espes__: or rather, what are the differences?
00:52imirkin_: no clue. i can't imagine it's anything substantial
00:52imirkin_: i mean ... no vram and all...
01:58mwk: espes__: I'd say NV2A is more like NV20 than NV25
01:59mwk: ISTM the main difference is that NV2A is bolted to a northbridge
02:00mwk: the only other difference I know of so far is that it has 2 vertex processing units instead of 1, otherwise it looks very much like an NV20
02:06espes__: mwk: nice, thanks
02:36rhyskidd: starting on BIT 'd' table support
02:36rhyskidd: more to come, but imirkin, mupuf or Lyude might be interested in progress
02:36rhyskidd: there's known unique elements in that table across Kepler, Maxwell and Pascal
02:37rhyskidd: e.g. Pascal introduces 4 link speeds, given the introduction of HBR3. Kepler and Maxwell in that regard only have 3 link speed entries
05:53Lyude: rhyskidd: yeah!! that is v cool
05:54Lyude: DP info table looks like voltage stuff you might be able to apply to help make the link more stable, depending on how the laptop manufacturer does things
05:55Lyude: I don't remember the specifics but I know there's something like that on skylake; e.g. a set of voltages you program from the vbios to help prevent link loss
05:56Lyude: so we should probably figure out how to mimic what the blob does with those values
06:06Lyude: I'm gonna add a trello card for that
06:21Lyude: I remember, it was this thing! 75067ddecf21 ("drm/i915: Per-DDI I_boost override") in i915
13:29rhyskidd: Lyude: yes, there appears to be pre/post link training scripts pointed to within the table
13:29rhyskidd: i thought you'd be interested given the work you've done on DP MST and link training on i915 with mnavare
13:30rhyskidd: thanks for the pointer
13:31mupuf: rhyskidd: nice, ship it!
13:32mupuf: I worked this week end on trying nvidia's documentation for the fan issue
13:32mupuf: but I need to read up on fixed-point arithmetics
13:32mupuf: I will try to continue tonight
15:23karolherbst: pmoreau: we might not want to report this: Global memory size 1099511627776 (1024GiB)
15:23karolherbst: and I guess this is fine though: Max memory allocation 1099511627776 (1024GiB)
16:18pendingchaos: imirkin: I think I've gotten a way to control the dilation parameter from NV_conservative_raster_dilate but it makes little sense to me: https://pastebin.com/raw/8E4E6fvW
16:20pendingchaos: implementing NV_conservative_raster_pre_snap_triangles seems to require something similar
16:21imirkin_: pendingchaos: ok, so that makes calls to the grctx firmware
16:22imirkin_: that generically makes sense. normally we use nouveau firmware which doesn't implement those calls, but for gm20x+, it's there
16:22imirkin_: i suspect that the dilation is a fixed-point value there
16:22imirkin_: perhaps in a bitfield
16:22imirkin_: my guess is that the firmware "4" method writes (or masks) a value into the given register
16:24pendingchaos: couldn't the blob do that more directly?
16:24imirkin_: no, it's (probably) a context-switched register
17:06grische: Is there a place in nouveau/envytools for binary-honest structs for vbios'? The nvbios/bios.h are all a mixture of envytools and real vbios data which makes it hard to read/write them easily.
17:07karolherbst: grische: uhm.. I doubt we have binary honest structs at all
17:07karolherbst: or rather, we don't care
17:07mwk: grische: we don't, and we won't have
17:07karolherbst: grische: tables differ between versions and we try to abstract those away
17:08karolherbst: and have the same structs for all versions
17:08mwk: C structs are not entirely adequate to specify exact structs in a portable way
17:08mwk: also, there tend to be too many variable-length fields in the tables
17:10karolherbst: mwk: well with packed you can do quite a lot
17:10grische: mwk: Why are C structs not adequate? The data I found in the docs are all at least 4 bits
17:10karolherbst: but yeah, most things will make it non work
17:10karolherbst: grische: because the vbios structure won't help you here
17:10karolherbst: too many pointers
17:11karolherbst: too many non fixed width stuff
17:11karolherbst: you have to parse before you know the structure, etc...
17:11grische: Yeah, I understand.
17:11mwk: well, for one, endianness...
17:12grische: mwk: Does this mean that the current envytools does work with eitherendianess?
17:12mwk: at least, the newer parts of nvbios
17:13mwk: all >8-bit reads go through bios_le16/bios_le32 functions that always do little-endian reads
17:16orbea: imirkin_: it was mesa...somehow the author doesn't surprise me... https://github.com/mesa3d/mesa/commit/a0c8b49284efe736849c0a45920ad0a1bbd8d93d
17:23karolherbst: pmoreau: we should reduce PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE
17:23karolherbst: makes bufferreadwriterect pass
17:25karolherbst: imirkin: any idea what should be the value of PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE?
17:26karolherbst: it is used for CL_DEVICE_MAX_MEM_ALLOC_SIZE: Return type: cl_ulong Max size of memory object allocation in bytes. The minimum value is max (1/4th of CL_DEVICE_GLOBAL_MEM_SIZE, 128*1024*1024)
17:27karolherbst: CL_DEVICE_GLOBAL_MEM_SIZE: Size of global device memory in bytes.
17:27karolherbst: for Size of global device memory in bytes. we export 1ULL << 40
17:27karolherbst: maybe we should take real limits into account here?
17:28karolherbst: pmoreau: ^
17:31Lyude: rhyskidd nice :), sounds like I guessed right
17:31grische: karolherbst, mwk: If the abstraction is intentional and you really want to support both BE/LE, the "write" of the "read/write" part is getting rather hard
17:31grische: any ideas?
17:32karolherbst: grische: why is that?
17:32karolherbst: you just write the tables back, no?
17:33grische: karolherbst: as far as I understand, I basically need to duplicate the read code (from envytools) and invert it to write things back
17:33grische: As I can't just read the whole thing, edit a few things and just write the whole thing back
17:33karolherbst: well, that is the easy part, right?
17:34karolherbst: there is one problem: we don't read out the entire vbios
17:34karolherbst: grische: if you really want to modify the vbios with nvbios, you kind of need to change the approach
17:34imirkin_: orbea: erm, that shouldn't have broken anything
17:35karolherbst: grische: either we read out everything and parse everything and that also includes all unknown fields
17:35karolherbst: or we just adjust things
17:35imirkin_: karolherbst: i dunno ... what do blob drivers report? 1<<40 is the VA size
17:35karolherbst: yeah sure, but then some CTS test goes ahead and allocates 32GB of memory
17:35karolherbst: not fun
17:35orbea: imirkin_: well it did
17:35karolherbst: grische: nvbios wasn't made for modifying the vbios and I wouldn't use it for that
17:36orbea: as far as I am aware the emulator always used a core profile
17:36imirkin_: orbea: i'm sure you're right. just seems odd. feels like a wine bug.
17:36orbea: its not wine
17:36karolherbst: probably the best thing is to write something from scratch, which is completly different from an architecture point of view
17:36grische: karolherbst: yeah, I am realizing this now
17:36karolherbst: grische: what might make sense to have a XML based documentation like rnn
17:36orbea: retroarch + beetle-psx which is a playstaion 1 emulator
17:36karolherbst: or well, some file format being able to define a structure
17:36karolherbst: table.version.field... kind of thing
17:36grische: karolherbst: rnn?
17:37karolherbst: and then you can say: set table.field to 0x200
17:37karolherbst: and it automatically takes the version into account or something
17:37karolherbst: grische: our XML based database for device register documentation
17:37orbea: it could be a bug in the emulator, I'll have to talk to the main dev and see what he thinks
17:38imirkin_: orbea: like maybe they have a piece of logic that makes wild assumptions about versions and libraries
17:39karolherbst: grische: also nvbios design isn't that great either, so I wouldn't mind replacing it by something text based as well
17:39orbea: possible, might of assumed mesa would never expose a 3.1 compat profile, I'll update in here when I hear back
17:40karolherbst: orbea: well, we do now
17:40karolherbst: AMD needs it for whatever reason
17:43karolherbst: pmoreau: Preferred / native vector sizes is all 1 / 1 on nvidia :D
17:44karolherbst: Global memory size 1099511627776 (1024GiB) vs Global memory size 4238737408 (3.948GiB)
17:44karolherbst: Max memory allocation 1099511627776 (1024GiB) vs Max memory allocation 1059684352 (1011MiB)
17:44imirkin_: and how much vram on that board?
17:45imirkin_: so you have the answer
17:45karolherbst: wondering why max memory allocatiion is so small though
17:48grische: karolherbst: What do you have in mind by "something text based"?
17:51imirkin_: karolherbst: 1/4th
17:51imirkin_: if anyone wants to rewrite nvbios, i'd highly recommend trying to harmonize it with the in-nouveau stuff
17:51imirkin_: i believe skeggsb was trying to do this a while back, but never got very far
17:52grische: karolherbst: Seems like max memory/4: "The minimum value is max (1/4th of CL_DEVICE_GLOBAL_MEM_SIZE, 128*1024*1024) for devices that are not of type CL_DEVICE_TYPE_CUSTOM." ( https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/clGetDeviceInfo.html )
17:54grische: imirkin_: harmonize what kind of pieces?
17:58karolherbst: imirkin_: well 1/4 is the minimum
17:59karolherbst: grische: some way to define the structure of the nvbios and either generate code out of it or parse it at runtime
17:59karolherbst: maybe something json based and then you can just add new versions to the existing things
17:59karolherbst: I would toy around a little and see what is a nice thing
18:00karolherbst: grische: we also have a bios parser inside the kernel module
18:00karolherbst: and we might want to have the same codebase for both things
18:06pmoreau: karolherbst: No clue about that mem report.
18:11karolherbst: pmoreau: we might want to sync our limits up with nvidia
18:11orbea: I can work around the compat profile issue with: export MESA_GL_VERSION_OVERRIDE=4.5
18:11karolherbst: orbea: uhh, sounds like an application bug to me then
18:12orbea: yea, sounds plausible
18:12karolherbst: doesn't use core profiles
18:12karolherbst: on mac os x you are limited to 2.1 even, I think
18:12pmoreau: On OS X you can get OpenGL 4.1
18:13orbea: Its using a core profile, just that commit in mesa must of broke some assumption...
18:13karolherbst: pmoreau: compat profile?
18:13pmoreau: No, core
18:13karolherbst: pmoreau: yeah, I was talking about compat
18:13karolherbst: orbea: ?
18:13karolherbst: orbea: core you should get 4.3
18:13pmoreau: Ah, okay
18:13karolherbst: orbea: check glxinfo
18:14orbea: i hacked to 4.5 :P
18:14orbea: it works
18:14karolherbst: right, but you still don't get a core profile afaik
18:14karolherbst: or maybe you do...
18:14karolherbst: the application doesn't request a core profile, so it doesn't get something above 3.1
18:14orbea: OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel (git-163a29099a)
18:15karolherbst: orbea: that's not what I meant
18:16orbea:re-reads and understands
18:16orbea: yea, the program is not using a core profile now, it was before that commit though
18:16imirkin_: i wonder if it's something dumb
18:16imirkin_: like forward-compatible not being a thing until 3.2
18:17imirkin_: (i don't know if that is the case)
18:17karolherbst: orbea: ahhh
18:17karolherbst: orbea: maybe it uses a compat profile if available
18:17karolherbst: and core if not
18:18orbea: yea, possible, it shouldn't if it is :P
18:18karolherbst: imirkin_: I guess it does if(compat) use_compat(); else if (core) use_core();
18:18karolherbst: application bug
18:18karolherbst: it should check the available features as well :D
18:19imirkin_: dunno :)
18:19karolherbst: I am sure it assumes it gets a full 4.5 context if it gets a compat context
18:19imirkin_: would require analysis
18:19karolherbst: ohh, I have a good feeling for that, I am sure it is simple as that :p
18:21karolherbst: orbea: is that this libretro stuff?
18:22karolherbst: might affect all libretro stuff then
18:22orbea: no, i checked
18:22orbea: other GL cores still work as does RetroArch
18:22orbea: i should check more GL cores to be sure though
18:22imirkin_: is this a game that uses gl directly?
18:22karolherbst: seems like it
18:23karolherbst: they have their own gl symbol dispatch thing
18:23orbea: the core can either use software (still works), opengl or vulkan (can't test with nouveau)
18:23karolherbst: orbea: I am more interested in which code actually creates the context
18:23orbea: i'm not sure where that is yet...
18:24karolherbst: ahh, it uses egl
18:24karolherbst: no calls
18:26karolherbst: orbea: set a breakpoint at eglCreateContext
18:26karolherbst: and then just check the bt
18:29orbea: where exactly?
18:30karolherbst: orbea: gdb
18:30orbea: I meant what code base :P
18:30orbea: oh, I guess I just dont know breakpoints well..
18:30karolherbst: just launch it
18:30karolherbst: and set the break point :p
18:30orbea:rebuilds with debuggin symbols
18:31karolherbst: no need
18:31karolherbst: just start gdb :D
18:31karolherbst: you need debbugging symbols for loc/variables names and all that kind of stuff
18:31karolherbst: but simple breakpoints on functions should always work (except those got inlined, which usually not happens for external symbols)
18:32orbea: this is useful? :P http://dpaste.com/1W4NQPJ
18:34karolherbst: orbea: well, you wanted to rebuilt mesa, right?
18:34imirkin_: its not crashing in mesa
18:34orbea: well, I have no debugging symbols for retroarch or the libretro core either at the moment
18:34karolherbst: orbea: ;)
18:35karolherbst: mesa debug symbols are useless here
18:35karolherbst: we know the library now
18:35imirkin_: its crashing in the psx core somewhere
18:35orbea: i knew that from the start :P
18:35karolherbst: this should be enough to find the call
18:35orbea: that is the core
18:35imirkin_: karolherbst: it's a SIGSEGV, not the breakpoint
18:35karolherbst: yeah.. but I think I know what is happening here
18:35orbea: oh right, its just crashing...
18:36karolherbst: but mhh
18:36orbea: oh right, this happened already once... *clears out his mesa shader cache
18:36karolherbst: imirkin_: is there a second eglCreateContext function?
18:36imirkin_: huh? that'd be in libEGL.so
18:36karolherbst: orbea: are you sure you set the breakpoint?
18:37imirkin_: you have his full log.
18:37karolherbst: :( ahhh, I see
18:37karolherbst: yeah, something is wrong
18:37imirkin_: words of wisdom...
18:37karolherbst: orbea: can you install the debug package of mednafen_psx_hw_libretro and debug again?
18:38orbea: I alrady have backtraces for that crash, its corrupted shaders... https://pastebin.com/fucUctse and https://pastebin.com/VDM5WMuk
18:38karolherbst: imirkin_: they have their own eglCreateContext
18:39imirkin_: ok, but then it's just a random function, not eglCreateContext ;)
18:39imirkin_: the implication of eglCreateContext is that it's in libEGL.so
18:40imirkin_: oh, wait - i see what you mean :)
18:40imirkin_: i think there's a way to convince break
18:40karolherbst: fun debugging such applications
18:40karolherbst: a lot of magic
18:40imirkin_: i bet if you set a breakpoint in _start
18:40imirkin_: then you can break on the real one
18:41orbea: it doesn't seem to hit the breakpoint unfortunately
18:41karolherbst: orbea: can you give me the output of ldd /usr/bin/retroarch or whatever path?
18:41imirkin_: nothing's so simple
18:41imirkin_: i'm sure it's the backend lib
18:41imirkin_: that loads the other thing
18:42karolherbst: imirkin_: https://github.com/libretro/beetle-psx-libretro/blob/master/rsx/rsx_lib_gl.cpp#L1350
18:42karolherbst: guess you can't use glUseProgram with 3.1
18:42karolherbst: ohh wait
18:42imirkin_: sure you can.
18:42imirkin_: that function was core in GL 2.0
18:42imirkin_: and previously available with at least ARB_shading_language_glsl
18:42imirkin_: or whatever that ext was called
18:43karolherbst: right, libEGL
18:43karolherbst: imirkin_: I guess loc are out of sync
18:43imirkin_: also libGL :)
18:43karolherbst: ahh git without tags, nice
18:43karolherbst: good to work with
18:44karolherbst: you might think if you have 2k commits, it is a good idea to start using tags
18:44imirkin_: dunno where that glsm is
18:44imirkin_: but that's where the answers will be
18:44orbea: yea, with 70+ cores not very much effort has been made for releases with those cores :P
18:45karolherbst: imirkin_: by point was, it doesn't use glx, but egl
18:46imirkin_: i still haven't found that yet
18:46imirkin_: orbea: i presume you have "CORE" defined there?
18:47imirkin_: anyways, it specifies CORE but sets version to 3.1
18:47imirkin_: that's not legal
18:47imirkin_: there are no 3.1 core contexts
18:47orbea: not sure how to check fast, but seems probable
18:47karolherbst: imirkin_: https://github.com/libretro/RetroArch/blob/master/gfx/common/egl_common.c#L341
18:47orbea: im not building with opengles for sure
18:47imirkin_: there are 3.1 contexts, which may or may not have ARB_compatibility
18:47imirkin_: but you can't request a 3.1 core or compat context
18:48imirkin_: karolherbst: yes, that seems reasonable for a file called egl_common
18:48imirkin_: karolherbst: do you know that it gets used?
18:48karolherbst: imirkin_: https://github.com/libretro/RetroArch/blob/master/gfx/drivers_context/drm_ctx.c#L508
18:48imirkin_: yeah, for the drm context
18:48imirkin_: orbea: how are you running this?
18:48karolherbst: ahh right, x ctx
18:49imirkin_: karolherbst: grep for RETRO_HW_CONTEXT_OPENGL_CORE
18:49orbea: from teh command line: retroarch -L /usr/lib64/libretro/mednafen_psx_hw_libretro.so /path/to/game.cue
18:49karolherbst: I think I found it
18:49orbea: but its not easy to test since it requires a ps1 bios and game
18:50imirkin_: heh. cue/bin files. i remember those!
18:50karolherbst: orbea: can you break at glXCreateContextAttribsARB?
18:51orbea: it doesn't seem to hit it
18:53karolherbst: is there some nice way to install that on fedora?
18:53karolherbst: ohh wait
18:53karolherbst: I guess I need roms to actually debug it?
18:53karolherbst: *super sigh*
18:53orbea: yea :/
18:53orbea: building it is easy: make HAVE_OPENGL=1
18:54karolherbst: I mean, yeah right...
18:54orbea: and retroarch: ./configure && make
18:54orbea: no installation needed
18:54orbea: its the bios and content that make it hard to test...
18:54karolherbst: it is the application which makes it hard to debug
18:55karolherbst: orbea: can you install debug symbols for those libretro packages?
18:55orbea: already done
18:55karolherbst: then a crash might help
18:55karolherbst: bt should point to loc
18:57imirkin_: ok. so ACTUALLY ... i think this is a mesa bug.
18:58imirkin_: we probably see GLX_CONTEXT_PROFILE_MASK_ARB + GLX_CONTEXT_CORE_PROFILE_BIT_ARB and happily return the 3.1 compat context.
18:58imirkin_: we should not do that.
18:58karolherbst: imirkin_: you mean they request core + 3.1?
18:58karolherbst: and then we screw up?
18:58imirkin_: it's also a psx core bug, in that it should not be asking for a 3.1 core context, since that's not a thing.
18:59imirkin_: i haven't looked at the code
18:59imirkin_: but this seems plausible.
18:59karolherbst: well it makes sense
19:02karolherbst: orbea: gdb never asked "Make breakpoint pending on future shared library load? (y or [n])", correct?
19:02karolherbst: when doing break eglCreateContext
19:02orbea: karolherbst: it did ask
19:03karolherbst: I hope you answered with y
19:03orbea: Yes, I also tried n after to make sure :P
19:03karolherbst: for me it doesn't even work with eglinfo...
19:03karolherbst: something is odd
19:06orbea: imirkin_: fwiw, changing libretro-common to request 3.3 instead of 3.1 fixes it
19:07karolherbst: ahh, I see
19:10karolherbst: orbea: can you break in xegl_fill_attribs?
19:12karolherbst: bool core = version >= 3001;
19:12karolherbst: I guess that should be version > 3001
19:12orbea: Breakpoint 1 at 0x5bebae: file gfx/drivers_context/xegl_ctx.c, line 193.
19:12orbea: nothing still
19:12karolherbst: they add EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR only if they got 3.2
19:12karolherbst: orbea: you don't hit it?
19:13karolherbst: orbea: you run it on X?
19:13karolherbst: I mean, are you running on X or wayland?
19:13karolherbst: or do you not know?
19:13orbea: no wayland, just x
19:14imirkin_: if (version >= 3002)
19:14imirkin_: yeah, basically there's a lot of confusion about 3.1 without ARB_compat
19:15imirkin_: it seems like psx is asking for 3.1, getting 3.1, and then being unhappy about it.
19:15karolherbst: well, but we have compat now
19:15karolherbst: or not?
19:15imirkin_: if it wants truly core, it should ask for 3.2
19:15orbea: i can make that PR for libretro-common
19:15karolherbst: I mean, we export GL_ARB_compatibility
19:16imirkin_: i think it's psx that has problems.
19:16karolherbst: I think the issue is a bit deeper actually
19:16karolherbst: because it actually gets a 3.1 compat profile
19:17imirkin_: so what
19:17imirkin_: that's fully compatible with 3.1 core
19:17imirkin_: except it won't error out on some stuff.
19:17imirkin_: i highly doubt that's the issue.
19:18karolherbst: orbea: can you give me the loc of the first segfault?
19:18karolherbst: orbea: with plain mesa
19:18karolherbst: I want to know which line in that libretro stuff actually triggers it
19:18orbea: with the corrupted shaders?
19:18karolherbst: of course not
19:19orbea: its not crashing?
19:20karolherbst: corrupted shaders means corrupted cache or what?
19:21orbea: those are the only crashes I experienced recently with that core
19:21karolherbst: if you update meas, it the cache should be invalid
19:21orbea: and yea, the core has all sorts of otehr problems
19:22karolherbst: orbea: I mean, if you have current mesa master and run that core, does it crash?
19:22orbea: there is no update for mesa, it just makes bad shaders trying to use a 3.1 context and then crashes on them :P
19:22orbea: i removed the shaders so not at the moment
19:22karolherbst: so you mean glsl source code?
19:23karolherbst: or application shader cache?
19:23orbea: the crash is in the application
19:23karolherbst: that's not my question
19:23karolherbst: what do you mean with "corrupted shaders? specificly?
19:23karolherbst: it writes down glsl shaders on the disc and uses it?
19:23karolherbst: or it stores compiled ones?
19:23karolherbst: or the mesa shader cache?
19:24orbea: I mean it crashes until I do: rm -r ~/.cache/mesa_shader_cache/
19:24karolherbst: and when you done that, does it crasht he second time?
19:24karolherbst: like after building that cache?
19:24karolherbst: okay so why did the mesa_shader_cache got in a state that it crashes the application?
19:25orbea: it works for a while and then crashes again for some reason
19:25karolherbst: did you update mesa?
19:25karolherbst: or did your machine crash + disc in weirdo state?
19:25karolherbst: okay, so it is just a time thing
19:25karolherbst: kind of sounds like a mesa bug to me then
19:26orbea: could be, but if its only experienced when doing already incorrect behavior :P
19:26karolherbst: that's not the point here really
19:26karolherbst: if mesa produces a shader cache
19:26karolherbst: and by using the API the same way it crashes
19:26karolherbst: it is mesas fault
19:26karolherbst: that simple
19:26orbea: yea, sounds right
19:27karolherbst: why is the behavior incorrect?
19:27karolherbst: from the source it doesn't look like libretro asks for a 3.1 core context
19:28orbea: psx is requesting a 3.1 core profile when it shouldn't for obvious reasons
19:28karolherbst: where is the code for that?
19:28orbea: imirkin_ linked it earlier https://github.com/libretro/libretro-common/blob/master/glsm/glsm.c#L2207
19:28karolherbst: and how did you know it requests a 3.1 _core_ profile context?
19:29karolherbst: orbea: that's not the EGL API being used
19:29orbea: it does fix the issue though :P
19:29karolherbst: yeah sure, but why?
19:29orbea: changing it to 3.2 and it renders again
19:30karolherbst: I mean, sure maybe it says it wants a core 3.1 one, but maybe libretro is smart and drops core on the request?
19:31orbea: heh, probably just got set to 3.1 because of wanting it to be more compatible while not understanding how it works...
19:32karolherbst: orbea: can you set a breakpoint at video_context_driver_set_flags and see if you hit it?
19:33orbea: i hit it http://dpaste.com/0F3F869
19:34karolherbst: p current_video_context.set_flags
19:36orbea: (gdb) p current_video_context.set_flags
19:36orbea: $1 = (void (*)(void *, uint32_t)) 0x0
19:38karolherbst: orbea: frame 3
19:38karolherbst: wait, actually
19:42orbea: I guess the retroarch --verbose output even shows the problem http://dpaste.com/0Y0GBPH
19:43karolherbst: orbea: break * eglGetProcAddress("eglCreateContext")
19:43karolherbst: mhh, that won't work either I guess
19:44karolherbst: c again
19:44karolherbst: ohh wait
19:44karolherbst: that break failed anyway
19:46karolherbst: orbea: you said it never hit egl_create_context right?
19:46karolherbst: does it hit gfx_ctx_xegl_set_video_mode?
19:48orbea: it doesn't hit either
19:49karolherbst: orbea: can you break at _eglInitContext and restart debugging?
19:50orbea: doesn't hit it
19:52karolherbst: no idea... those breakpoint things totally doesn't seem to work
19:58orbea: is it really egl and not glx?
20:04karolherbst: orbea: I think so, there is no glx code really afaik
20:04orbea: it would be in retroarch I think
20:07karolherbst: anyway, I doubt that it actually requests a 3.1 core context
20:07karolherbst: I think the application just says: yeah core, but also at least 3.1
20:08karolherbst: but yeah, would need to know what actually gets passed into *CreateContext
20:09karolherbst: orbea: but maybe with the debug symbols the crash is actually telling us something?
20:09karolherbst: or is it still at ???? or something
20:09orbea: like I said, that crash is because of the mesa_shader_cache
20:10imirkin_: we killed ARB_shader_program_binary formats support in compat contexts
20:10imirkin_: for QT's benefit
20:10karolherbst: imirkin_: right, but this is about mesas internal shader cache
20:10imirkin_: i know
20:10karolherbst: but mhh
20:10karolherbst: yeah I could guess something goes super wrong there
20:10orbea: karolherbst: I made backtraces already https://pastebin.com/fucUctse and https://pastebin.com/VDM5WMuk
20:11orbea: the backtrace seems to differ on how content was launched, through the gui or cli
20:11karolherbst: "#0 0x00007fffb4d3ee4d in ?? " not helpful
20:11orbea: not sure why it does that
20:11orbea: it should be -g -O0
20:11karolherbst: and the latter one points to glUseProgram
20:12karolherbst: it doesn't seem to call it
20:12karolherbst: so maybe command_buffer is NULL or command_buffer->program
20:12orbea: i'll get another trace next time it happens...
20:12karolherbst: or it is the wrong loc
20:16orbea: karolherbst: I think i figured out how to reproduce it http://dpaste.com/07BDS44.txt
20:16orbea: in short I launched it to create the shader cache, closed it and then: export MESA_GL_VERSION_OVERRIDE=4.5
20:17orbea: launched it again, closed it and then launched it a third time without that environmental variable and it crashes
20:17karolherbst: I see
20:18karolherbst: the crash location is a bit odd though
20:19orbea: I think its crashed as it switches from the retroarch context to the core's context
23:33rhyskidd: Lyude: :)
23:34rhyskidd: mupuf: i've got some more work to do on that BIT 'd' branch, but thanks for the early R-b