00:15 robclark: imirkin: I think w/ cursor, it would be valid for kms driver to copy to next largest supported size.. some drivers already do that to convert format, etc..
14:00 karolherbst: dcbaker: your 53c36dfcfe3eb3749a53267f054870280afb0d71 broke GTF-GL45.gtf30.GL3Tests.sgis_texture_lod.sgis_texture_lod_basic_getter
14:07 karolherbst: soo.. lroundf(1.09951163e+12) -> 0
14:07 karolherbst: .. weird
14:07 karolherbst: sounds wrong
14:09 karolherbst: wait..
14:09 karolherbst: lroundf(obj->Sampler.MaxLod) is 0x10000000000
14:09 karolherbst: so instead of INT_MAX we return ß
14:09 karolherbst: *0
14:53 midn: It is said on Wikipedia that "Mesa provides an OpenGL API over DirectX". I found this to be confusing; does it say that Mesa can use DirectX as a backend on Windows?
15:25 daniels: midn: correct, it's not yet merged into the tree but is in development
15:57 midn: daniels: Would this let me run higher versions of OpenGL than other drivers allow usually? There's no GL3.2 driver for GM45 despite the fact the chip supports it and DX10
15:58 daniels: midn: unfortunately the driver is written against D3D12 :\
15:58 midn: Well, that sucks
15:58 midn: Oh well
15:59 midn: Thanks for the answer
17:21 mattst88: midn: GM45 does not support GL 3.2
17:22 midn: According to the Khronos wiki, DX10 is "functionally equivalent" to GL3.2 and GM45 supports DX10
17:23 mattst88: I don't know what DX10 supports to be able to respond to that
17:23 mattst88: but GM45 simply cannot do GL 3.2. GL 3.0 requires multisampling which intel hardware cannot do until Sandybridge
17:23 mattst88: I think you're the third person I've had to try to convince of this in the last two weeks. what gives?
17:25 midn: What gives is that I want newer GL versions on my laptop and have been looking all around the place in hopes of finding anything. Or I'm hoping for a bit of mock support in drivers for some features
17:27 mattst88: sorry, that hardware's pretty much tapped out. EXT_gpu_shader4 might materialize, but I doubt anything more than that
17:28 mattst88: I don't question why you want features -- I question why so many people are under the misinformed that the hardware can do more GL than we've exposed
17:28 kisak: when using broad strokes, DX10 and GL 3.x are about the same, but the hardware simply didn't have support parity back then. It's a historical artifact.
17:29 mattst88: if there's a wiki or something that I need to change to stop misleading people into thinking that we just gave up on GM45, please let me know
17:29 midn: Yes, the Khronos wiki says that DX10 is functionally equivalent to GL3.2, that's where I made my conclusion
17:29 midn: I don't remember what page exactly, though
17:31 midn: Shame that Mesa can't mock a few insignificant features like multisampling, but thanks for all you've been doing anyways, Mesa is an impressive project nonetheless. Thanks for the help
17:31 mattst88: https://software.intel.com/sites/default/files/ae/4e/15732
17:32 mattst88: > Microsoft DirectX*10 Optional Features
17:32 mattst88: > 1. MSAA support is not supported on Intel® GMA Series 3 and 4.
17:32 mattst88: so MSAA is an optional DX10 feature, evidently
17:32 mattst88: (the file is a PDF, even though it's missing the extension)
17:34 kisak: midn: while it's wrong for the driver to outright lie to you about what the hardware is capable of, you can choose to do it yourself, but if things fail it's not-a-bug. See MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE in https://www.mesa3d.org/envvars.html
17:35 kisak: (don't set those env variables globally)
17:35 midn: I wasn't sure if that option emulates some newer features in software or if the features just don't do anything, so I didn't use it
17:37 kisak: setting those env variables won't emulate anything, just bypass some sanity checks for testing purposes
17:37 midn: Ah, okay, thanks
17:52 midn: https://www.khronos.org/opengl/wiki/Selecting_a_Shading_Language#Intel_support This is where the I drew my bad conclusion
17:54 midn: Don't know if it's worth changing it though, pretty sure only I looked *that* deeply
17:56 linkmauve: midn, oh my, what a shitty article.
17:56 linkmauve: You can probably burn this page with fire, and use GLSL like absolutely everyone.
17:58 mattst88: ffs
17:58 mattst88: as an Intel employee, I don't want to touch the page
17:58 sravn: pcercuei: I assume you already reworte most of it anyway, of what matters. So drop any references to my original patch
17:58 mattst88: but I agree with linkmauve
17:58 mattst88: though I feel confident that the writer of that section was talking about the *Windows* drivers, and not Mesa
17:59 linkmauve: Yup.
17:59 linkmauve: Intel’s d3d9 driver in Mesa is actually fine. :p
17:59 mattst88: lol
18:00 midn: Well, I wouldn't burn it, maybe just specify that GLSL is the go-to now. At least I'm the kind of person that still supports things as low as 1.4 just because, but I undestand that I'm like 0.00000000001% of the community so I'll digress, thank anyways
18:01 mattst88: a historical account masquerading as current information is the problem
18:03 linkmauve: midn, you can use GLSL even on older OpenGL versions if the hardware supports it, using the GL_ARB_{vertex,fragment}_shader extensions if they are supported.
18:03 midn: Yes, I try to use extensions for most things
18:03 midn: To discriminate against features
18:03 midn: Not full-proof, though as things don't have to be exposed as extensions
18:06 linkmauve: midn, for each extension that has been made core, you should first check the version of the context, if it includes the feature you’re fine, and only then check for the extension version.
18:06 midn: One day these drivers will stop the extensions backwards compatibility, but either I, GL or all the old hardware would probably be dead by then
18:06 linkmauve: Hmm?
18:06 linkmauve: Which kind of backwards compatibility do you mean?
18:07 midn: Exposing features in both core and extensions at once
18:07 linkmauve: Ah, Apple already doesn’t do that.
18:07 linkmauve: They don’t expose any extension that is core in the version of your context.
18:08 pcercuei: sravn: ok
18:08 midn: Well, I never bothered with Apple anyway :)
18:08 linkmauve: Lucky you…
18:09 midn: Well, anyways thanks for help, everyone, I'll just stay on GL2.1 or connect some slow GPU through ExpressCard in the future, I guess.
18:10 karolherbst: but couldn't we expose GL3.0+ on those chips with 1 max samples like we do/did with llvmpipe or so?
18:14 kisak: karolherbst: reminds me of the GL 1.4 -> 2.1 emulation that was put into intel gen 3 support, which never worked quite right. It'd be less painful to just use llvmpipe for development
18:17 linkmauve: Would there be any interest in adding GLES 3.0 to features.txt?
18:17 mattst88: karolherbst: unclear what it would accomplish. what software that currently doesn't work, would work if we lied and exposed GL 3.0 to GM45?
18:17 karolherbst: mattst88: dunno, but seems like some users care for unkown reasons
18:18 linkmauve: Especially for drivers in development such as panfrost, it might be usefeul to know which driver supports it, and which are limited to 2.0.
18:18 mattst88: karolherbst: as far as I can tell the problem is "the number isn't big enough", which I'm not sympathetic to...
18:18 linkmauve: mattst88, users seem to think that a bigger GL version will magically make their hardware work better.
18:18 mattst88: linkmauve: that's what it seems to be
18:19 karolherbst: probably yes
18:19 imirkin: some software also requires core contexts now
18:19 karolherbst: ohh, good point though
18:19 linkmauve: imirkin, context profiles are a thing only starting from 3.2, would this hardware support that?
18:19 imirkin: with a LOT of development effort, afaik yes
18:19 linkmauve: (Technically 3.1 introduced core.)
18:20 imirkin: linkmauve: 3.2 introduced different profiles. 3.1 introduced GL_ARB_compatibility.
18:20 mattst88: linkmauve: technically, 3.2 introduced core. 3.1 just dropped the deprecated stuff
18:20 linkmauve: Oh right.
18:20 linkmauve: Sorry, I’m always a bit confused by those.
18:20 imirkin: it's a subtle difference
18:21 mattst88: subtle and very annoying
18:21 imirkin: with 3.1 you get what you get, with 3.2 you can choose
18:21 linkmauve: Yeah.
18:27 imirkin: mattst88: looks like an evoluation of the language since 2009
18:27 imirkin: [on that wiki page]
18:28 imirkin: https://www.khronos.org/opengl/wiki_opengl/index.php?title=Selecting_a_Shading_Language&diff=1883&oldid=1682
18:29 mattst88: yeah, not surprising :|
19:18 pcercuei: sravn: oops, forgot to Cc you on the doc update patch. But it was sent to the DRI mailing list
19:18 sravn: pcercuei: np
19:52 airlied: mattst88: glamor would ve faster if we exposed.gl3
19:53 mattst88: airlied: huh, we have GL 3.0 paths that don't work with supported extensions? probably glsl 1.30 stuff?
19:53 airlied: yeah integers
19:53 mattst88: idr added an extension that offers integers on G45 I think
19:54 airlied: he started :-)
19:54 airlied: not sure it landed
19:54 mattst88: GL_MESA_shader_integer_functions
19:55 mattst88: oh, that's different
19:55 imirkin: EXT_gpu_shader4 =]
19:56 imirkin: shouldn't be difficult to support for gen4/5, i think
19:56 imirkin: and i expect it has everything that glamor needs
19:56 airlied: yeah it would be nicer if we had a glsl 1
19:56 mattst88: that's what jason's been playing with in #intel-3d
19:56 airlied: 30 compat
19:57 airlied: but i think gpu shader 4 coild be made.work
19:57 mattst88: sounded like he was making good progress
19:57 imirkin: it's basically integer stuff + texture stuff
19:57 imirkin: (+ lots of parser stuff, but that's all done already)
19:57 airlied: if jekstrand exposes it maybe i can port glamor
19:57 airlied: drag out my ilk
19:57 airlied: and i have a gm45 but under covid loxkdown
19:58 imirkin: it's contagious?
19:58 imirkin: (the gm45, that is)
19:58 mattst88: seems to be
19:59 mattst88: at least the question of "why doesn't my GM45 expose GL3.0?" seems to be
19:59 imirkin: pretty sure it's just one person who keeps asking
19:59 mattst88: the guy in #intel-3d at least has a very different style of communication, so I think there are at least two
20:00 imirkin: hehe
20:00 airlied: imirkin: i think covid19 needs gl 3.0
20:00 mattst88: macc24 was the other guy that asked in #intel-gfx
20:01 macc24: wat wat twat
20:01 macc24: my spidey sense is tingling
20:01 jekstrand: I think there are more than two gm45 users out there
20:01 macc24: no gm45 here
20:01 imirkin: inconceivable!
20:02 jekstrand: If we can prove there's less than 10, I'll just buy them each a laptop and go back to more interesting/important stuff. :-P
20:02 imirkin: hehehe
20:02 jekstrand: But, yeah, Gen4 can do most of GL3.0
20:02 macc24: if someone makes a gallium driver for intel gpus that works on my intel machine
20:02 jekstrand: It's just a matter of how much work it is
20:02 imirkin: right
20:02 jekstrand: Like, do we really want to fake MSAA with super-sampling?
20:02 macc24: there is high possibility that i will do gl3.3 on ironlake
20:02 macc24: jekstrand: no
20:02 macc24: please don't cut performance of already slow gpu
20:02 macc24: just ignore it :D
20:02 imirkin: i think we discussed this, but MSAA and XFB are pretty annoying.
20:03 imirkin: (not to mention GS)
20:03 mattst88: macc24: sorry, gen4/g45/gen5 are all more or less the same in this regard. I didn't mean that you specifically asked about one vs the other
20:03 macc24: jekstrand: for gl3.0 4gen is missing EXT_transform_feedback
20:04 jekstrand: Yeah, MSAA and transform feedback (also called XFB) are the big ones that would be a massive pain.
20:04 macc24: jekstrand: MSAA is needed for gl3.2
20:04 macc24: https://people.freedesktop.org/~imirkin/glxinfo/#p=compat
20:05 jekstrand: No, texture_multisample is needed for 3.2, basic multisampled rendering is required for 3.0.
20:05 macc24: hmmMMm
20:06 macc24: so
20:06 macc24: this? https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_multisample.txt
20:06 jekstrand: Yes, I think that's the one.
20:06 macc24: gl1.3
20:07 jekstrand: Roughly
20:08 imirkin: the ext has been around for a while
20:08 imirkin: however GL 3.0 made it required to support at least 4x msaa
20:08 jekstrand: Right
20:08 airlied: does thie crappy geom shader extension fit the older hw any better?
20:08 jekstrand: In any case, it'd be implementable, it'd just kind-of suck.
20:09 imirkin: airlied: afaik it's a pain to implement. and it wouldn't get you GL 3.2 anyways
20:09 karolherbst: imirkin: how are we handling that with llvmpipe though? I was convinced we cheat there?
20:09 jekstrand: airlied: I don't know. We've never hooked up gen5 GS
20:09 macc24: jekstrand: well i switched to radeon machine now, so good luck with 3.0!
20:09 imirkin: karolherbst: yes, we cheat
20:09 jekstrand: macc24: I'm not planning to do 3.0; just GL_EXT_gpu_shader4 which gives you most of the shader features of 3.0 like integers.
20:10 airlied: karolherbst: currently we chera with llvmpipe, in a week or two we won't
20:10 jekstrand: And that only best-effort
20:10 airlied: as soon as I land my MR
20:11 karolherbst: airlied: ... you are not planning in passing the CTS with llvmpipe are you? :D
20:11 airlied: karolherbst: it already does
20:11 jekstrand: But, yeah, if glamor can do something better given EXT_gpu_shader4, that provides more motivation to do it.
20:11 airlied: passes GL4.5 and GLES 3.1 in my tree
20:11 jekstrand: airlied: Nice!
20:11 airlied: but it has some memory corruption issue that takes out cts runner
20:11 karolherbst: hey... let me get the nouveau bits in first :D
20:12 airlied: Vulkan 1.0 is about 40 tests left
20:12 airlied: but I reallly need to nail down the memory corruption
20:12 airlied: not sure if it's threads or llvm or llvm&threads related yet
20:12 karolherbst: probably threads
20:12 karolherbst: :p
20:13 karolherbst: I just tracked down a threads related bug in nouveau
20:13 karolherbst: well, it's a kernel bug, but triggered by threads inside mesa
20:13 karolherbst: probably the reason the CTS failed for me
20:13 airlied: valgrind/helgrind has failed me in finding it so far
20:13 karolherbst: yeah, it won't help
20:13 karolherbst: :p
20:14 karolherbst: happened way too often that I knew there was something broken but valgrind/helgrind weren't able to detect this
20:14 karolherbst: libasan is way more reliable
20:14 karolherbst: it's so reliable, that I won't use valgrind anymore for that stuff
20:15 airlied: yeah I'll try asan next
20:15 karolherbst: these days I don't even bother with valgrind anymore, it's slow and that's probably one of the reasons it doesn't find races as well
20:29 sravn: pinchartl: does it make sense for a bridge driver to call drm_helper_hpd_irq_event() if it did not create the connector?
20:30 sravn: pinchartl: For the above Q, it is in the attach() function. For example nxp-ptn3460.c
20:44 pinchartl: sravn: I think it would be best called outside of bridge drivers. drm_bridge_connector_hpd_cb() calls drm_kms_helper_hotplug_event(), maybe that's a good location
20:45 pinchartl: I've talked with Daniel about how I think HPD could be refactored, but he disagreed, saying hardware is too buggy in general and what we do currently is best
20:45 pinchartl: I still think it's too complex for drivers to implement correctly, there's way too much cargo cult in that area
20:47 sravn: For the bridge drivers do you recommend to keep it for now?
20:47 sravn: I have moved the call above creating the connectors, but I think this is wrong as they try to update the connector state
20:50 sravn: The drivers do not use drm_bridge_connector_enable_hpd() so they never call drm_bridge_connector_hpd_cb().
20:50 sravn: But I guess thats just one part of the current no-so-easy-to-use design
20:51 sravn: Anyway, will take a look at it again tomorrow. Getting late here. G'night
21:30 pinchartl: sravn: the bridges should only call drm_bridge_hpd_notify() with the new model. how to forward HPD to the DRM core should be the job of the display driver, possibly with helpers
21:30 pinchartl: bridges should do as little as possible
23:09 airlied: first use of tsan finds a bug in the vulkan loader :-(
23:17 pinchartl: airlied: another proof that we need to invest in tools :-)
23:17 karolherbst: airlied: :) told you that valgrind is not reliable :p
23:18 airlied: though tsan finds no bugs in vallium :-P
23:18 airlied: time for asan
23:18 karolherbst: maybe asan will :p
23:18 airlied:thinkgs I'll have to rebuild llvm with them
23:19 karolherbst: ohhh sounds like pain
23:20 karolherbst: airlied: some .gdbinit helper file: https://gist.githubusercontent.com/karolherbst/54b2ab53c10b6671feebeeca30a64d39/raw/0e5b09a437c8708e9d3f70325a85875e94e2c672/.gdbinit
23:20 karolherbst: comes in handy with asan
23:20 karolherbst: and doing "asan-load" in gdb sets it up
23:20 karolherbst: especially that abort_on_error=1 part is super helpful