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