03:46 xmnm: Hello, and sorry if this shouldn't go here, but only 2g is connecting right now and irc is basically the only thing that loads. I have an AMD HD 7770 (sea islands) and am using the amdgpu driver (I don't know if the kernel driver affects radeonsi at all). I'm experiencing problems with a single windows game called exanima, even in the main screen framerate won't go over 12fps, being full screen or not doesn't affect it, disabling compositing on kwin
03:46 xmnm: doesn't really help either
03:47 xmnm: Using gallium HUD I could notice that CPU utilization remains at 10% per core, GPU utilization at 3% and vram utilization at under 200mb. I don't know what could be causing this under use of hardware. The game is opengl so radeonsi is being used
03:50 xmnm: Oh and I'm on Mesa 20.0.4 and Linux 5.6.4
03:51 imirkin: could be bad synchronization, i suppose. try running with vblank_mode=0
03:51 xmnm: Is that a kernel parameter
03:57 xmnm: Well I treated it as one, as I expect envs to be all caps
03:59 xmnm: No change beside vram going from 189 to 209 mb
04:01 HdkR: Maybe that game is actually just that rough on such an old GPU?
04:01 xmnm: I should maybe note that at the very start of the game, when it displays the logo, GPU utilization is considerably higher at 24% but goes down immediately when the transition to main menu starts, now, as the game has a single logo I don't know if the GPU usage comes from the fact that the game just started
04:02 xmnm: The game actually ran better on my pre Intel HD igpu, so I don't think that's it
04:04 HdkR: Depends on the Intel iGPU I guess. Latest gen is about as powerful as that dGPU :P
04:05 xmnm: As I said, it's previous to Intel HD, we are talking integrated into motherboard old
04:05 xmnm: I think the model is g45 but I might be wrong
04:07 HdkR: Fun
04:09 imirkin: xmnm: env var
04:12 xmnm: Well, a blackout, I can't do more testing
04:12 xmnm: But I tried vblank as an env and there was no change
04:12 xmnm: Beside GPU usage going from 3 to 2% sometimes
04:19 HdkR: Considering it is rated platinum on protondb, definitely something wrong with it
04:20 xmnm: It's been playable on wine since a long time before proton. It's one of those rare games with no DRM so it's trivial to run it directly with wine
04:21 xmnm: (No measurable difference between running it on wine or proton, though)
04:24 HdkR: Protondb is really just a good database for user reports, wine's appdb has a higher barrier to entry :P
04:25 xmnm: It's better that the user can't force a platinum rating when there are issues, the system prevents it
04:25 xmnm: Too bad you have to link you steam account now, though
04:46 xmnm: Well, this blackout wasn't that long. I could test stuff again
04:49 xmnm: I can put everything on Max and the metrics don't change meaningfully after loading, same framerate and utilization
04:49 xmnm: Only sypersampling changes things
04:50 xmnm: GPU usage still low but framerate lowers even further
04:53 xmnm: I just remembered that radeontop is a thing I have installed, everything there is single digit percentage except vram which is at 17% and clocks which are at 100%. So no apparent bottle neck here
04:56 xmnm: At this point I'm out of ideas of what to try
06:34 daniels: dschuermann: np!
07:09 MrCooper: TD-Linux: there's not really a "frame" concept in X, it's just a stream of drawing requests
07:50 TD-Linux: MrCooper, yeah, but presumably opengl requires one, hence why I was asking :)
07:51 MrCooper: not for frontbuffer rendering, which is what glamor uses
08:45 daniels: after all the excitement of our infrastructure work over the weekend, we might have some failures remaining. i won't be able to keep an eye on every MR and job today, so please let me know if you're seeing any spurious CI failures so we can investigate. thanks.
08:52 xmnm: I don't know why but I don't seem to be able to boot into radeon kernel anymore
08:53 xmnm: I added it to mkinitcpio module list and removed amdgpu, and regenerated the image
08:54 xmnm: I removed the grub kernel parameters that disable radeon and enable amdgpu, but xorg is still trying to load amdgpu
08:56 MrCooper: tomeu: consider manually triggering only the CI jobs you need, instead of just all of them
08:57 MrCooper: xmnm: can you pastebin the dmesg output?
08:59 tomeu: MrCooper: ack
08:59 MrCooper: thanks
09:00 xmnm: Well give me a moment...
09:12 xmnm: Sorry, connection is so terrible I'm having trouble uploading
09:13 xmnm: What I can say is that it first enables radeon
09:13 xmnm: And several seconds later it enables amdgpu
09:13 xmnm: For whatever reason
09:14 xmnm: Let me reboot phone, maybe connection will improve a bit
09:22 xmnm: And still nothing
09:25 MrCooper: anyway, amdgpu will only bind with amdgpu.{cik,si}_support=1 , so it sounds like that and the corresponding radeon parameter are still getting passed in somehow
09:26 xmnm: They are not on/proc/cmdline however
09:38 xmnm: Even when black listing, it tries to load amdgpu
09:43 xmnm: Even moving the xorg amdgpu library doesn't prevent it from loading it even seems to show compilation information, so unless that's cached
09:43 xmnm: It's somehow still loading it
09:44 xmnm: Or maybe I should have taken it off xorg's folder altogether
09:45 shadeslayer: Hey, is there a ioctl to find the '/dev/dri/' path of the primary GPU?
09:46 MrCooper: xmnm: it's all up to the kernel, Xorg just has to follow suit
09:46 MrCooper: xmnm: maybe the parameters are in /etc/modprobe.d/ or so
09:47 xmnm: There were just a handful of files, nothing related to amd
09:47 xmnm: Except for my amdgpu blacklist
09:48 emersion: shadeslayer: what do you mean by "primary GPU"?
09:48 shadeslayer: emersion: the DRM master I suppose
09:48 emersion: the DRM master is a process
09:48 emersion: the wayland compositor for instance
09:49 emersion: a wayland compositor can open multiple devices
09:50 emersion: wayland compositors perform composition on a single GPU now, but that may change in the future
09:50 emersion: wayland compositors may scan-out the client's buffer on a different GPU
09:50 xmnm: /usr/lib also has a modprobe folder
09:51 emersion: so, what do you need? the GPU used for composition? the device where the buffer will be displayed?
09:51 xmnm: But nothing related to amd either
09:51 shadeslayer: emersion: hm, no, then I'm not explaining it correctly, I'm trying to find out how to get the kernel to return '/dev/dri/card0' if we're using that GPU? . Does that make sense?
09:51 emersion: shadeslayer: maybe it would be easier if you explained your use-case
09:51 emersion: what are you trying to do? why do you need this information?
09:51 xmnm: Unless options bonding max_bounds=0 somehow causes this
09:52 emersion: who is "we"?
09:52 shadeslayer: emersion: https://gitlab.collabora.com/Fahien/gfx-pps/-/blob/b6305c2b3a5b167ef08f20e5cf987392f330c44b/src/gpu/panfrost/gpu_ds.h#L102 < I'd like to get rid of hardcoding '/dev/dri/card0' here
09:52 emersion: > You need to sign in or sign up before continuing.
09:52 shadeslayer: ugh
09:58 bshah: shadeslayer: re: I think what you mean is in case of lima/panfrost/etnaviv where one card is the drm card, and other is render node, you want to pick up the drm node?
09:59 shadeslayer: bshah: I suppose, I'm just trying to find the right ioctl that can give me the DRM node path
10:00 emersion: shadeslayer: do you have a render node FD?
10:00 emersion: if so, you can drmGetPrimaryDeviceNameFromFd
10:01 shadeslayer: not that I'm aware of, this is essentially a perfetto data source that will enable panfrost counters by calling IOCTL's on /dev/dri/card0, except we hard code that path right now, and I'm trying to figure out how to not hardcode it
10:02 emersion: there's no ioctl that just returns /dev/dri/card0
10:02 emersion: you need to figure out what is the correct card to use
10:02 shadeslayer: how'd you do that?
10:03 bshah: I am trying to find a code , but I do believe a wlroots had a code somewhere which did drmGetInfo on available cards and if it did not return error it used it or something :s
10:05 emersion: well, you need to answer the question: what card do you want?
10:05 emersion: is it a card tied to a render node? a card with a specific manufacturer?
10:05 emersion: a card with a specific PCI ID or platform?
10:06 shadeslayer: emersion: well, I suppose we can filter it out by the kernel module
10:06 emersion: the kernel can't guess for you
10:06 shadeslayer: so let's assume we're trying to find the path for a panfrost device
10:07 emersion: drmGetDevices might help, then
10:07 bshah: shadeslayer: does this code help? https://github.com/swaywm/wlroots/blob/master/backend/session/session.c#L337
10:07 emersion: this will give a list of devices
10:07 emersion: drmGetVersion will give you the driver name
10:08 emersion: but i'm not sure filtering by driver name is the right thing to do in your situation
10:09 ascent12: If you already have an fd describing the device, you can just compare major/minor numbers to the devices you get from drmGetDevices
10:09 emersion: if you already have an FD opened, drmGetPrimaryDeviceNameFromFd
10:10 shadeslayer: I don't think perfetto will be able to provide that info
10:15 xmnm: Mkinitcpio -v doesn't show amdgpu, so something else is pulling it in
10:18 xmnm: Even blacklisting from kernel parameters has the module being loaded I don't understand anything
10:23 xmnm: Taking ANY suggestions, I'm completely stumped. I want to load my gcn 1.0 card with radeon instead of amdgpu, which should be easy as radeon is default for this card, but after radeon loads, amdgpu tries to load and xorg crashes
10:24 xmnm: Modprobe.d doesn't have amdgpu listed, I don't have the kernel parameter that enables amdgpu, and I tried to blacklist it from kernel parameter and modprobe.d
10:24 xmnm: But it still loads
10:25 xmnm: Is there any way to know if another module is calling for it?
10:29 pq: shadeslayer, so what does perfetto actually have to help identify a device?
10:29 shadeslayer: @pq I'm not sure, I'm looking into it
10:30 shadeslayer: From my understanding so far, perfetto will let you write a data source for whatever, it's up to the data source to identify the device afaict
10:31 pq: shadeslayer, and what do you mean about DRM ioctls and counters? Is it doing DRM ioctls from a process other than the one that is actually rendering?
10:31 shadeslayer: @pq yeah, the data source producer fires off some ioctls to enable performance counters
10:32 pq: shadeslayer, is that... a good design to begin with?
10:32 pq: or should it just enable those on all devices it can find?
10:32 shadeslayer: @pq well the IOCTL is panfrost specific ```DRM_IOCTL_PANFROST_PERFCNT_ENABLE```
10:33 shadeslayer: so I guess we can just fire it on all devices, and ignore the errors as long as there's one success?
10:33 pq: sure, so all Panfrost devices, and not just one particular device
10:34 pq: shadeslayer, the major point here being: you don't want to find any specific DRM device. You wan to find all devices driven by Panfrost. Is that so?
10:34 shadeslayer: pq: correct
10:34 pq: ok, then the suggestions of... whatwasit...
10:34 shadeslayer: drmGetDevices?
10:34 emersion: yeah
10:34 emersion: + drmGetVersion
10:35 pq: yes, and filter by be driver name - drmGetVersion I guess?
10:35 emersion: aye
10:36 shadeslayer: makes sense
10:37 shadeslayer: @pq @emersion thanks!
10:37 emersion: np
10:38 kusma: sravn: thanks :)
11:29 tzimmermann: danvet, will you merge my PR for drm-misc-next into drm-next? or is this going elsewhere for now?
12:43 karolherbst: anybody any idea what "0.007843" is for a magic number?
12:44 ickle: 1 / 127.5
12:45 karolherbst: I see it in many shaders in different forms: 0.007843, 0.00784313772f, 0.00784314
12:45 karolherbst: ickle: mhh, okay.. but mhh
12:45 karolherbst: I was more wondering from a high level point of view why anybody would like to use this number
12:46 ickle: 2 / 255., might make sense as 'smallest measurable error'
12:46 ickle: if you leave 1/255. for HW variation
12:47 karolherbst: mhhh
12:47 karolherbst: yeah.. might make sense
12:47 lynxeye: karolherbst: s8 to normalized -1.0f..1.0f float conversion?
12:47 karolherbst: lynxeye: those are magic numbers inside shaders
12:47 karolherbst: like glsl code
12:47 ickle: or that could explain it :)
12:48 karolherbst: but yeah..
12:48 karolherbst: I mostly have those shaders which aren't readable :)
14:27 haasn: Anybody got example code using EGL_MESA_platform_surfaceless? I'm trying to get it to work but it doesn't seem to. Maybe I'm missing something. This is my code http://dpaste.com/0ASD5QR.txt, it prints "Initialized EGL v1.5" followed by "GL_VERSION: (null)"
14:29 pq: haasn, Weston's headless backend uses it, but it's not exactly simple code.
14:29 haasn: I'll try taking a look at that then
14:30 pq: haasn, at least you are missing eglBindAPI() and eglMakeCurrent() calls, I think.
14:30 pq: eh
14:30 pq: no
14:30 pq: hm, BindAPI maybe?
14:38 haasn: I don't see weston doing much different from my code, except some extra logic when choosing the config to make sure it's compatible with certain formats
14:38 haasn: I tried adding eglBindAPI but it didn't change anything
14:38 haasn: the default API is already bound to OPENGL_ES, and changing it to OPENGL doesn't change anything
14:39 daniels: yeah, you need to BindAPI before CreateContext, then call MakeCurrent, and also you need to pass the API version into the context, and set EGL_RENDERABLE_TYPE in your config call
14:39 haasn: hmm
14:39 daniels: haasn: OPENGL_ES != OPENGL_ES2
14:40 haasn: ah, that was my mistake; I had the eglBindAPI in the wrong place. If I eglBindAPI(EGL_OPENGL_API) before eglCreateContext it works
14:40 haasn: OPENGL_ES2 doesn't seem to be a valid string for eglBindAPI: https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglBindAPI.xhtml
14:40 haasn: I guess it's because I specify EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT
14:41 haasn: Yeah if I remove that requirement it works with the default eglBindAPI too
14:41 haasn: problem solved, thanks!
14:43 haasn: .. which is weird because EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT seems to be the default value of EGL_CONTEXT_OPENGL_PROFILE_MASK
14:43 haasn: but actually commenting that out from the attrib list makes the code I pasted work
14:43 haasn: Clearly that is *not* the default value
14:47 MrCooper: EGL_CONTEXT_OPENGL_PROFILE_MASK is probably only valid for EGL_OPENGL_API
15:13 xmnm: Hello, I have a gcn 1.0 card and I've been using amdgpu for a long time. I wanted to go back to radeon to test something but I've been unable to as xorg attempts to load amdgpu after loading radeon and then crashes
15:14 xmnm: First thing I tried was simply removing the kernel parameters that allow amdgpu to be used on sea islands cards
15:14 xmnm: I checked my modprobe.d files to make sure I wasn't loading it there
15:14 xmnm: Even, I'm blacklisting it now and also tried to blacklist it from kernel parameters
15:14 xmnm: Mkinitcpio isn't loading amdgpu either
15:16 MrCooper: we need to see the dmesg output and/or Xorg log file to be able to help
15:18 xmnm: Well, the xorg log doesn't show amdgpu loading, my guess is that when it tries to load amdgpu it makes a new file
15:19 MrCooper: nope
15:20 MrCooper: maybe you're looking at the wrong log file, e.g. /var/log/ vs ~/.local/share/xorg/
16:27 xmnm: My inability to even provide logs are making me consider dropping the whole radeon thing, I don't even know if it'll be of any use. Mrcooper are you a Mesa Dev? Do you know if there should be any important difference on how radeonsi behaves based on whether we're using radeon or amdgpu?
16:30 MrCooper: mareko & pepp are the radeonsi devs here, but yes, some features are only supported with amdgpu, and the kernel drivers themselves may behave differently
17:19 haasn: ..huh, apparently glReadPixels for rg16 generates a GL_INVALID_OPERATION error, but the same code works fine for r8, rg8, rgba8, r16 and rgba16. I don't even know what could trigger that error, none of the conditions from the documentation of glReadPixels seem to apply
17:19 haasn: Is there any way I can debug this in mesa?
17:19 haasn: I forgot to specify this only happens on a GLES context, on core desktop it works fine
17:20 Kayden: that does not surprise me at all.
17:20 imirkin: ES has much more stringent rules
17:20 imirkin: it will do zero conversion
17:20 imirkin: how are you creating the FB you're trying to read?
17:20 Kayden: my guess is that read_pixels_es3_error_check in src/mesa/main/readpix.c is pitching the error
17:20 imirkin: i wonder if we look at TexFormat instead of the internalFormat to determine the thing
17:21 imirkin: there's already a bug like that in the CopyPixels checks
17:21 haasn: imirkin: nothing special http://dpaste.com/0BEHD32.txt
17:22 imirkin: haasn: and the texture's format is GL_RG16?
17:22 imirkin: [in the fail case]
17:22 haasn: and the glReadPixels call is http://dpaste.com/3RCK4AF.txt, in which most of the special cases don't get hit
17:23 imirkin: which driver is this with?
17:23 imirkin: i bet it doesn't support RG16 and it gets upgraded to RGBA16
17:24 haasn: imirkin: internal format is GL_RG16 yes
17:24 haasn: driver ver is OpenGL ES 3.2 Mesa 20.1.0-devel (git-adeef43d15)
17:24 imirkin: :)
17:24 haasn: on Radeon RX 560 Series (POLARIS11, DRM 3.36.0, 5.6.3-gentoo, LLVM 10.0.0)
17:24 imirkin: ah, that's more useful. let's check...
17:26 haasn: side note it also fails for rgb8 on GLES but I decided to focus on the rg16 case first because 3-component textures are notoriously wonky
17:26 haasn: and in the worst case I'd just blacklist 3-component textures, but rg16 really ought to work
17:27 imirkin: hm. seems supported with radeonsi...
17:28 imirkin: well, rgb8 definitely gets upgraded to rgba8
17:28 imirkin: anyways, check the function Kayden pointed out
17:28 haasn: what makes me lean slightly towards not-a-bug-in-my-code is that the code works fine on desktop GL, even with rgb8
17:28 haasn: sure
17:28 haasn: I guess I could step through that function
17:28 imirkin: since it's definitely where the error is being generated
17:28 imirkin: (almost definitely)
17:29 Kayden: any time you get a GL error, just throw a breakpoint in _mesa_error and step up through the call chain until you find the spot
17:29 Kayden: or if you want to breakpoint in glFoo, break in _mesa_Foo
17:30 haasn: oh that's a good tip
17:31 imirkin: Kayden: welcome back btw :)
17:31 Kayden: hiya imirkin! how goes?
17:32 Kayden: thank you :)
17:32 imirkin: fantastic =] except, you know, for all the terrible things.
17:32 Kayden: yeah, I'd ask if the world exploded while I was gone, but that kind of goes without saying, so...
17:33 imirkin: one of those rare times when the answer is definitely 'yes'
17:33 Kayden: it's nice to be back, it's been a while
17:36 haasn: so that function read_pixels_es3_error_check simply doesn't even have a case for GL_RG
17:36 haasn: the comment leading to it points out that http://dpaste.com/2C1ANMZ.txt
17:36 haasn: so it seems like whether RG16 should work or not is implementation-defined
17:36 haasn: and mesa happens to decide "no"
17:37 haasn: ...which is weird considering this is OpenGL ES 3.0
17:37 imirkin: haasn: well, look at the call site
17:37 imirkin: it shouldn't even be hitting that case
17:38 imirkin: it should be in the first "everything matches" case of the if, i'd think
17:38 imirkin: (clearly, not everything matches)
17:38 imirkin: https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/readpix.c#n1078
17:38 imirkin: [note API == GLES2 means "not gles1"]
17:39 robclark: Kayden: o/
17:39 imirkin: could be that mesa_get_color_read_format/type just need a bit of fixing
17:40 Kayden: hey robclark! :)
17:47 haasn: imirkin: _mesa_get_color_read_format(ctx, NULL, "glReadPixels") returns GL_RGBA != GL_RG
17:48 haasn: not entirely sure what the logic behind that check is
17:48 imirkin: mesa_get_color_read_format should probably return GL_RG
17:48 imirkin: i don't remember exactly how that stuff works
17:48 haasn: it doesn't depend on the framebuffer
17:49 imirkin: o
17:49 imirkin: what does it depend on?
17:49 haasn: oh nvm
17:49 haasn: if (!fb) fb = ctx->ReadBuffer
17:49 imirkin: =]
17:49 haasn: I'm just not used to how stateful OpenGL is, lol
17:49 imirkin: lol
17:49 imirkin: it's just missing the UNORM16/SNORM16 cases
17:50 imirkin: ohhhh because you don't get GL_R*16 in unextedned ES
17:50 imirkin: that requires GL_texture_norm16 or whatever
17:50 Kayden: yep
17:50 imirkin: so at the time this function was written, it must have just been left out
17:50 haasn: yeah
17:50 haasn: I do have the ext though
17:50 imirkin: yeah, just dump those 2 cases in
17:51 imirkin: and the good times will roll!
17:51 imirkin: and SINT/UINT16 too
17:51 imirkin: oh wait, those are covered
17:51 imirkin: so yeah, just the SNORM8, [SU]NORM16 cases
17:55 haasn: MESA_FORMAT_RGB_UNORM16 doesn't seem to exist, even though MESA_FORMAT_RGB_SNORM16 does
17:55 haasn: what's up with that
17:58 haasn: do you know what (if anything) adds SNORM8?
17:58 imirkin: RGB isn't a thing
17:58 haasn: it doesn't seem to be EXT_texture_norm16
17:58 imirkin: nothing supports RGB
17:58 haasn: why does MESA_FORMAT_RGB_SNORM16 exist then?
17:58 imirkin: always gets upgraded to RGBA
17:59 imirkin: heh
17:59 imirkin: good question
17:59 imirkin: there's been some amount of format rework
17:59 imirkin: looks like there is a PIPE_FORMAT_R16G16B16_UNORM
18:00 imirkin: so i'd expect there to be an equal MESA_FORMAT
18:00 haasn: :shrug:
18:00 Kayden: it may just be an array format
18:00 imirkin: it is an array format
18:00 imirkin: but e.g.
18:01 imirkin: mesa/main/formats.h:#define MESA_FORMAT_RGB_SNORM16 PIPE_FORMAT_R16G16B16_SNORM
18:01 ElBarto: Hello
18:01 imirkin: but the same thing for UNORM16 is missing. you could add it.
18:01 ElBarto: manu@FreeBSD here
18:01 imirkin: anholt_ may remember why. probably just a simple omission.
18:01 imirkin: ElBarto: and a simpsons fan, presumably?
18:01 ElBarto: is Eric Engestrom or Emil Velikov spend time here ?
18:02 imirkin: eric_engestrom: xexaxo1 --^
18:02 ElBarto: imirkin: I was yes, the nickname stucked :)
18:02 ElBarto: I wanted to get input on what I need to do to have https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/41 merged
18:02 ElBarto: everything sound correct on my side
18:02 anholt_: imirkin: what's the question?
18:02 xexaxo1: ElBarto: been sidetracked with other stuff
18:03 imirkin: anholt_: why is there a MESA_FORMAT_RGB_SNORM16 but no MESA_FORMAT_RGB_UNORM16
18:03 xexaxo1: will get to those first thing tomorrow.
18:03 ElBarto: xexaxo1: awesome thanks
18:03 anholt_: probably something like "accum buffers are snorm and so they got defined but nothing defined high bit depth unorm buffers"
18:04 imirkin: anholt_: could be framebuffers, right?
18:04 imirkin: this is in the context of extending mesa_get_color_read_format
18:04 imirkin: so that ReadPixels(GL_RG16) works when the fb is backed by a GL_RG16 texture
18:05 imirkin: [in ES]
18:05 haasn: if RGB always gets upgraded to RGBA then could I conceivably emit them from _mesa_get_color_read_format() because it can never actually be a color read format?
18:06 haasn: I guess it makes sense given that RGB8 etc. also aren't there
18:06 imirkin: haasn: well, there's a difference between what's done internally and what's presented to the API
18:07 haasn: in which case we may have a problem, since e.g. the rgb8 case failing indicates to me that perhaps this function returns GL_RGBA based on the internal mesa_format, but checks it against the iformat provided by the user (GL_RGB)
18:07 haasn: which may be fine if GLES doesn't support rgb8 glReadPixels. I'd have to check the spec
18:07 haasn: (and any extensions that may exist.. fun)
18:08 haasn: in theory GLES3 should support rgb8 though
18:09 imirkin: yeah, it should
18:09 imirkin: there's a similar problem around CopyPixels when texture formats get upgraded to renderable ones
18:09 imirkin: the checks are done based on TexFormat and not internal format
18:09 anholt_: imirkin: sounds like you could just drop it in the switch statement in _mesa_get_color_read_format.
18:10 imirkin: so you can end up allowing copies between two formats that you shouldn't
18:10 imirkin: anholt_: yeah, that's what i suggested. but then it turned out the define was missing :)
18:10 imirkin: haasn: so yeah, just add defines for missing things in mesa/main/formats.h
18:12 anholt_: I don't think we have anything that lists out what you need to do to define a new MESA_FORMAT, but it'll probably include updating switch statements in formats.c and the mesa-side format csv.
18:13 imirkin: anholt_: hm, i wonder what it does now then without it being defined
18:13 imirkin: since it's all == PIPE_FORMAT...
18:13 austriancoder: anholt_: do you never need/want to power down the DUT for your fastboot infrastructure?
18:13 imirkin: oh, but this is RGB. not RG.
18:13 imirkin: the RG unorm/snorm16 ones *are* there
18:14 haasn: could also add the GL_RGB checks to read_pixels_es3_error_check
18:14 haasn: that may be the better place to add the norm16 stuff as well, since it has existing logic for _mesa_has_EXT_texture_norm16
18:15 haasn: what's more worrying to me is that MESA_FORMAT_RG_SNORM8 is missing from the same switch, which I'm not sure if it should be or not
18:15 anholt_: austriancoder: we reboot with a usb-controlled relay between each run
18:16 anholt_: austriancoder: did you end up making any progress on an x86 image for baremetal?
18:16 austriancoder: anholt_: have seen this.. but what if there are no runs for hours?
18:17 austriancoder: anholt_: yup.. got alos fastboot over network working
18:17 anholt_: I'm leaving the boards on. I suppose I could turn the relay off at the end
18:17 anholt_: nice!
18:17 haasn: https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_color_buffer_float.txt does introduce GL_RGB8 as a renderable format though
18:19 haasn: I'm slightly confused as to why that switch (format) has a switch (internalFormat) inside the GL_RGBA case
18:19 haasn: which has its own cases for GL_R16, GL_RG16 etc.
18:19 haasn: how can you read GL_RGBA from a GL_R16 texture?
18:19 austriancoder: anholt_: k.. I think I want to power down my devices to save power :) Will cleanup my wip stuff and create a MR afterwards
18:19 anholt_: austriancoder: we'd be happy to have that behavior too
18:23 haasn: " Only two format/type parameter pairs are accepted. For normalized fixed point rendering surfaces, GL_RGBA/GL_UNSIGNED_BYTE is accepted. For signed integer rendering surfaces, GL_RGBA_INTEGER/GL_INT is accepted. For unsigned integer rendering surfaces, GL_RGBA_INTEGER/GL_UNSIGNED_INT is accepted. The other acceptable pair can be discovered by querying GL_IMPLEMENTATION_COLOR_READ_FORMAT and
18:23 haasn: GL_IMPLEMENTATION_COLOR_READ_TYPE. The implementation chosen format may also vary depending on the format of the currently bound rendering surface. "
18:23 haasn: sigh
18:23 haasn: so the bottom line is that even with GLES3 and norm16 support you still can't actually read GL_RG or GL_RGB
18:24 haasn: what's weird though is that GL_R works
18:24 haasn: I guess that's just a mesa implementation-specific
18:25 imirkin: well, whatever the implementation color read type is
18:25 imirkin: which is what that function returns
18:25 imirkin: ES is annoying.
18:36 anholt_: daniels: weird windows fail: https://gitlab.freedesktop.org/rantogno/mesa/-/jobs/2355423
18:38 haasn: so I guess the bottom line is that 1) there's a bug in my code (failing to check GL_IMPLEMENTATION_DEFINED_foo*) and 2) there's a limitation, not a bug, in mesa (not setting rgN and rgbN's implementation-defined formats to the corresponding GL_RG / GL_RGB)
18:43 daniels: anholt_: I wonder if that's the special corner case - usually reserved for robclark's wip - of creating a branch called foo, deleting it, then creating another called foo/bar (or vice versa)
18:44 dschuermann: jekstrand: as you intel guys have a much better work schedule, I assume you have plenty of time ~one week before branch point :) May I ask you to have a look at !4062 ?
18:47 imirkin: haasn: sounds right
18:47 imirkin: this makes writing single tests for both es and desktop when read pixels is invovled quite a pain
18:48 haasn: I decided to work around the issue by just failing texture creation when the GL_IMPLEMENTATION_DEFINED_* does not match the expected values :)
18:49 haasn: at least now I can sleep at night knowing the source of this headache
18:49 anholt_: daniels: saw a couple fails for windows today and just looked at that one -- doesn't have the usual "couldn't find my ref" type failure for the thing you're talking about
18:49 anholt_: other failure was https://gitlab.freedesktop.org/rantogno/mesa/-/jobs/2354852
18:49 haasn: imirkin: what's actually causing my tests to fail is lack of rgb16f / rgba32f support in GLES..
18:49 haasn: which is weird considering rgba16f seems to exist, actually.
18:49 haasn: oh it's not color-renderable
18:50 haasn: although it should be.
18:50 anholt_: haasn: expect anything "rgb" not "rgba" to be unsupported basically anywhere.
18:51 jekstrand: dschuermann: Ha!
18:51 jekstrand: Wait, we're branching soon?
18:52 haasn: (that was a typo, I meant rgba16f)
18:52 bnieuwenhuizen: jekstrand: 4-29
18:52 bnieuwenhuizen: which is next wednesday I think
18:52 jekstrand: Oh, I should try to land the CFG refactor
18:53 jekstrand: Which means figuring what it's doing to SotTR
18:53 imirkin: haasn: rgba16f should be renderable with EXT_color_buffer_float
18:53 imirkin: rgba32f needs another ext iirc
18:54 imirkin: EXT_color_buffer_float_no_really_i_want_rgba32f or whatever
18:55 haasn: another bug in my code, I was testing the GLSL ver not the GL ver by typo
18:55 haasn: and the GLSL ver on GLES != the GL ver
18:55 haasn: this is all rather annoying :(
18:55 eric_engestrom: ElBarto: sorry, I had completely forgotten about that MR
18:56 eric_engestrom: ElBarto: I've just reviewed it again and there one thing to fix but once that's done it's all good to merge from my side
18:56 krh: Kayden: hey, welcome back
18:57 ElBarto: eric_engestrom: thanks, I will address your comments tomorow !
18:57 Kayden: hey krh! how's it going? :)
18:57 imirkin: hm, looks liek RGBA32F is actually renderable with EXT_color_buffer_float
18:57 imirkin: i wonder what i was thinking of... maybe blending?
18:57 eric_engestrom: ElBarto: I'll let xexaxo1 review it tomorrow as he said, but unless he finds something I'll merge your MR :)
18:57 ElBarto: eric_engestrom: cool, thanks for the good news :)
18:57 imirkin: hrmph. no. i was just crazy then.
18:58 krh: Kayden: stuck in my bedroom
18:58 eric_engestrom: ElBarto: np, and sorry for the unnecessary delay :(
18:58 jekstrand: dschuermann: Ugh... this is going to be a "fun" review....
18:58 ElBarto: eric_engestrom: meh you know, life blah blah ...
18:59 eric_engestrom: :]
18:59 ElBarto: eric_engestrom: as long as it's merged at one point it's fine for me
18:59 eric_engestrom: krh: go crazy! move your laptop to your living room!
19:00 dschuermann: jekstrand I know, sorry, but I don't really know who else to ping about :/
19:00 Kayden:is usually in his bedroom, that's where the portal to virtual worlds is
19:00 jekstrand: dschuermann: fair enough
19:00 krh: eric_engestrom: I do have a laptop here without working wifi, and the router is in the bedroom...
19:00 dschuermann: worse, it's a pure refactoring :P
19:00 jekstrand: dschuermann: You can always ping cwabbott :P
19:01 jekstrand: krh: Get a longer cable
19:01 jekstrand: krh: Or setup a p2p network between that machine and one that does have WiFi and teather it.
19:02 jekstrand: krh: Also, you work for Google. How do you own a computer that doesn't have WiFi? How do you own a computer that has a wired cable.
19:02 jekstrand: ?
19:02 krh: jekstrand: the other issue is that the rest of the house has little people in it...
19:02 jekstrand: krh: Yeah, well, there is that. :D
19:02 daniels: anholt_: blegh, was too late and now the repo is in a good state now. i honestly have absolutely nfi how that would happen, given that D:\ is just a completely regular drive
19:02 krh: jekstrand: early hw
19:03 daniels: (and has 250GB available)
19:03 krh: hehe, D:\
19:03 anholt_: daniels: ok. just want to keep information flowing about intermittent failures.
19:03 krh: daniels: did you check autoexec.bat?
19:03 daniels: krh: i'm passing _loads_ of options to himem.sys and now nothing works anymore
19:03 daniels: anholt_: it's super helpful, thanks so much for letting me know
19:04 Kayden: lol, I see the day that #dri-devel is talking about autoexec.bat and himem.sys and not making a joke has arrived :)
19:04 jekstrand: *sigh*
19:04 daniels:closes the PowerShell session to the GitLab CI runner ... and opens another PowerShell session to the other laptop on his desk
19:05 jekstrand: With all these people porting GNU userspace to various other kernels, who knew that NT would become the new hotness?
19:05 krh: daniels: try pressing the turbo button
19:05 jekstrand: and... there's the joke... ^^
19:05 krh:presses jekstrand buttons
19:06 ccr: change the load order of drivers, to free up more base memory!
19:06 Kayden: so... apparently we have Windows testing now? without appveyor?
19:06 Kayden: I heard a rumor about apitrace rendering testing too?
19:07 daniels: jekstrand: you forgot the inverse bit - PowerShell runs on Linux, and (even as a 15+-year zsh zealot) it >>>>>>> all other shells
19:08 daniels: Kayden: yeah, atm we have one runner hosted on EC2 (which, to be clear, Collabora is paying for rather than fd.o) which is doing the builds and also the basic 'ninja test' suite
19:08 Kayden: that's awesome, thanks so much for doing that!
19:09 daniels: that uses the VS2019 toolchain so you'll see the same failures that jrfonseca would usually fix a couple of weeks later
19:09 daniels: itmt, i've been doing some hat-juggling between fd.o/Collabora talking to Microsoft OSS people about getting Windows sponsorship - either flat-out free Azure VM time, or at least some free licenses that we can run on Packet machines - so we can extend that to do the same testing as on our other drivers
19:10 daniels: you can do llvmpipe testing on the EC2 runner, but it'd probably DoS other builds
19:10 daniels: unfortunately you can't do testing of the D3D12-backed driver on the EC2 runner because there is so little GPU support in its VM that even the llvmpipe equivalent (WARP) doesn't work when inside a container
19:10 daniels: so hopefully when we get to running the server on real hardware, we'll be able to test that
19:11 daniels: Kayden: no thanks required, I got paid for it :P
19:11 daniels: though arguably there is no amount of money high enough to compensate for dealing with LLVM builds on Windows
19:11 jekstrand: daniels: Running the D3D12-backed driver on WARP would be interesting
19:11 daniels: jekstrand: yeah, that's what we do locally for testing
19:11 Kayden: what's this d3d12 backed driver?
19:11 daniels: and we have very very definitely not found even a single bug in WARP in the process
19:11 Kayden: I've heard mention of it but it must be new
19:12 robclark: Kayden: it's a strange new world you've returned to :-P
19:12 daniels: Kayden: currently it lives at gitlab/kusma/mesa - it's pretty much Zink but backing on to D3D12 rather than Vulkan
19:12 Kayden: interesting
19:12 Kayden: and they use OS/2 WARP as a software rasterizer? :D
19:12 Kayden:hides
19:12 daniels: heh
19:12 jekstrand: daniels: Oh, I'm sure WARP is perfect.
19:13 kusma: Kayden: :D
19:13 daniels: jekstrand: oh yes, extremely
19:13 Kayden: is it a program? then it is perfect and has no bugs. clearly :D
19:13 kusma: jekstrand: just don't try to shift 64-bit values!
19:14 jekstrand: kusma: Why would anyone want to do that?
19:14 daniels: jekstrand: to be fair to WARP, the bug I found was already fixed in the Insiders builds by the time I discovered it ... the upgrade did, however, completely brick my user profile and I had to re-do everything from scratch. including building LLVM.
19:14 jekstrand: :(
19:14 daniels: that's pretty much what I said at the time, yeah
19:15 kusma: jekstrand: Nobody. Not at all to emulate global variables by smuggling SSBO buffer-indices and offsets in the high-low words, that's for sure!
19:15 kusma: eh, global memory
19:15 jekstrand: Yeah, I can't imagine anyone doing that.
19:15 kusma: Anyway, nobody does that.
19:16 daniels: good times
19:17 daniels: I would also like to note that our captors are treating us very humanely and we have no desire to return home
19:18 daniels: (the other good news is that there are also no bugs in vtn for CL SPV)
19:21 karolherbst: daniels: sure there are no bugs? I know a few.. except somebody fixed those in the meantime and I just didn't saw it...
19:21 karolherbst: I saw some pointers being created wthout strieds
19:21 karolherbst: *strides
19:21 karolherbst: messing up lower_explicit_io
19:22 daniels: karolherbst: the bit about the Gallium D3D12 driver being Zink-but-DX, and the bit about the Insiders build was true. also everything about the EC2 runner. most everything else was not
19:24 krh: the bit about himem.sys was true too
19:25 daniels: haha
19:25 daniels: honestly tho, PowerShell is _so_ good
19:26 karolherbst: compared to cmd.exe?
19:26 karolherbst: what is _worse_ than cmd.exe?
19:26 daniels: compared to literally everything else
19:26 daniels: it's sort of like a mash-up of Python and a shell, but in a really good way and not in a waf way
19:42 austriancoder: anholt_: where can I find e.g. shader-db.txt result files of a pipeline run?
19:44 anholt_: austriancoder: meson-gallium job (e.g. https://gitlab.freedesktop.org/anholt/mesa/-/jobs/2329440) hit "Browse" on job artifacts.
19:48 austriancoder: anholt_: thx
19:59 xmnm: MrCooper, http://sprunge.us/VmBvZ4 finally, here's the dmesg
20:10 airlied: anyone else seeing fails with dEQP-VK.spirv_assembly.instruction.graphics.opspecconstantop.shiftrightarithmetic_i64_vert
20:10 airlied: seems wierd that I'd be seeing driver fails there (though I haven't dug too deep)
20:50 anholt_: jekstrand: put up an MR dropping lower_to_source_mods from freedreno. etnaviv and lima look like they don't have a copy prop that could fold in neg/abs. thinking maybe we would need a little helper for "take my alu src, and generate a new alu src plus negate/abs out flags by walking through SSA defs"
20:51 jekstrand: anholt_: I suspect a little helper would help them greatly
20:53 ElBarto: eric_engestrom: I went ahead and resolved the issues tonight, I'll handle the follow up (if any) tomorow, thanks again
20:55 hakzsam: airlied: yeah, these fails with RADV as well, I haven't investigated
20:55 airlied: hakzsam: cool thanks!
20:55 airlied: must be a bug in the spec constant stuff
20:55 hakzsam: (they pass with AMDVLK IIRC)
21:06 Kayden: jekstrand, anholt_: I was thinking about the non-SSA nir_search stuff in idr's series...one thing I was reminded of...was that we'd been talking on and off about reworking registers to be load_reg / store_reg intrinsics
21:06 Kayden: which is a huge change, but ... then the result of load_reg would be SSA, and the operand of store_reg would be SSA, and it might eliminate the need for that stuff.
21:07 Kayden: while also taking the IR in a direction we wanted togo
21:08 jekstrand: Kayden: Yeah, anholt_ and I talked about that
21:08 anholt_: Kayden: that came up, too! v3d and freedreno would be pretty down for regs as intrinsics, I think.
21:09 anholt_: we could probably start with something that lowered existing reg load/stores in src/dst to new intrinsics to see what the damage was.
21:09 airlied: would fit nicely with how llvmpipe works also
21:23 xmnm: hello, I'm trying to see if I can collect any useful information about a game that's running badly, 12fps, cpu usage at 10%, gpu usage at 3%, plenty of ram and vram available. Gpu has its clocks running at 100% but it's like it's doing almost nothing as per gallium hud, the game uses opengl
21:23 haasn: Hmm. With LIBGL_ALWAYS_SOFTWARE=true in the environment, my glGetString(GL_VERSION) returns NULL again :(
21:25 Kayden: xmnm: what driver/hardware?
21:25 xmnm: Kayden, I have an amd hd 7770 running with amdgpu, mesa 20.0.4, linux 5.6.4, as the game is opengl radeonsi must be in use
21:26 Kayden: ah
21:32 xmnm: this is what radeontop gives right now that I'm not running the game https://a.uguu.se/7LkCBe6mzSqs.webp
21:33 xmnm: this is the game with gallium hud, note that the peak of usage at the very start plummets when the logo transitions into the main menu https://a.uguu.se/GkE4F604sSL4.webp and this is radeontop right now with the game open https://a.uguu.se/gJ41WmQWSmTB.webp
21:53 haasn: culprit seems to be enabling EGL_CONTEXT_OPENGL_DEBUG
21:53 haasn: which fails if (disp->Version < 15)
21:54 haasn: ah, I only get EGL v1.4, my bad
21:54 HdkR: Don't enable debug context?
22:04 xmnm: is there a way to make it so integrated intel graphics are used in a desktop rather than the amd ones without removing the amd card? I want to test something
22:08 kisak: xmnm: usually that's handled by an X config and physically connecting the monitor to the motherboard's video outputs or using DRI_PRIME
22:09 xmnm: I thought DRI_PRIME was only for laptops, I have to make it so i965 drivers are loaded first though
22:10 bnieuwenhuizen: xmnm: laptops, desktop with an igp, same thing really :) (well at least for this purpose ...)
22:11 xmnm: ==> ERROR: module not found: `i965' uh oh
22:12 kisak: the kernel module would be called i915, on the X DDX side, I expect it'd either be "intel" or "modesetting"
22:12 xmnm: should I be using i915 instead?
22:13 xmnm: oh, almost at the same time
22:15 jekstrand:tells marge to kill the noise function \o/
22:23 xmnm: well, so much for that idea
22:23 xmnm: I think igpu's output is toast
22:23 xmnm: no output even during bios phase
22:24 imirkin: frequently bios will disable igpu if there's a dgpu installed
22:24 bnieuwenhuizen: xmnm: maybe a BIOS option to switch boot GPU?
22:25 xmnm: can't be bothered, I doubt this would have been useful in debugging that game anyway
22:32 xmnm: suggestion welcomes about how to get any useful information out of this opengl game,using an amd card so radeonsi is in use