01:08 jekstrand: jenatali: It means that no optimization is allowed to be performed which would cause a bit-for-bit change to that value.
01:09 jekstrand: jenatali: For instance, an exact x * 1.0f, you may have to keep the multiplication on the chance that it flushes denormals. (Not actually sure if that example holds.)
01:10 jekstrand: jenatali: A better, more obvious example would be x * 0.0f. If it's not exact, you can replace it with 0 but you can't if it's exact because NaN and Inf will both throw it off.
02:12 imirkin_: jekstrand: at least on nvidia hw, denorm flushing happens on input into the op rather than on output
03:19 jenatali: jekstrand: Thanks, makes sense
07:19 danvet: tzimmermann, there's quite a pile of patches in -fixes, plus I pushed a regression fix
07:19 tzimmermann: danvet, yes i want to send them out today
07:19 danvet: good to check once a week during -rc phase for these and push them out
07:19 danvet: ok, sounds all good
07:19 danvet: and yeah Thu is the deadline because airlied is ahead of everyone else :-)
07:20 tzimmermann: i'm currently test-building them
07:20 tzimmermann: sorry about being late
07:20 danvet: probably also good to roll forward to -rc3 when it's out
07:20 danvet: ah no worries
07:21 danvet: tzimmermann, if you want to make sure you don't forget things during -rc phase
07:21 danvet: calendar reminder to fast forward on Mon morning after latest -rc is tagged and pull request on Thu
07:22 danvet: but generally there's not that much going on
07:22 tzimmermann: good idea :)
07:22 tzimmermann: but don't worry, i did not forget about this
07:23 danvet: tzimmermann, yeah only reason I pinged is because of the regression patch I pushed
07:24 tzimmermann: danvet, we should have a policy about using __ at the beginning of function names. your patch does that. i recently had a similar function name, but sam and emil where not happy about the __
07:26 danvet: __ means "internal" or "dangerous"
07:26 danvet: pretty common in the kernel at least
07:26 danvet: in userspace __ means "libc namespace" because C headers and fun stuff like that, so there you can't use it afaiui
07:26 danvet: or not so much
07:26 tzimmermann: exactly. i don't have strong feelings about naming, but others do
07:27 danvet: imo naming matters a lot more for non-static functions
07:27 tzimmermann: if drm follows the overall kernel style, i'm happy to continue with __
07:29 tzimmermann: i cannot find the rsp discussion on dri-devel anymore
07:37 mlankhorst: danvet: there's a pile of -fixes queued up, remind tzimmermann today to send out a pull request ;)
07:37 tzimmermann: nlankhorst, i'm on it already
07:38 tzimmermann: mlankhorst ^
07:38 danvet: mlankhorst, thx
07:38 danvet:already did :-)
07:38 danvet: tzimmermann, not sure there is much of an overall kernel style
07:39 danvet: it's pretty common in dri-devel and other places at least
07:39 danvet: but there's parts of the kernel that look totally different
07:39 tzimmermann: i see
08:01 danvet: agd5f_, [RESEND] [PATCH v6 0/8] do not store GPU address in TTM <- I'm assuming könig will do last few missing reviews and then push this all to some tree?
08:01 danvet: imo has been floating around often enough that we don't need to further stall this on driver maintainer acks
09:45 danvet: mlankhorst, we might want a backmerge because of the amdgpu conflict that's now resolved in drm-next
09:49 danvet: also just to catch up with the merge window
10:13 pq: danvet, are you looking for us to add more compositor people to CC about the lid vs. connector question?
10:16 pq: jadahl, https://lists.freedesktop.org/archives/dri-devel/2020-June/270393.html - does mutter have any weird code for that?
10:17 emersion: would be nice to document better what the connector status means
10:17 emersion: maybe in drm_mode.h?
10:18 emersion: though nobody from user-space will read that one
10:19 daniels: you do realise that you two are the DRM userspace documentation maintainers, right :P
10:21 pq: ha! I don't even have any push rights so I can't be!
10:22 pq:runs before someone gives the rights
10:25 emersion:can't run anymore!
10:41 ccr: you can run, but you can't hide ..
10:45 danvet: pq, we can fix that reeeeaaaaal quick
10:45 danvet: emersion, for connector status docs, maybe just in the property docs?
10:45 danvet: hard to find, but at least you guys now where it is now :-)
10:45 danvet: and maybe eventually we can duplicate that entire section into drm-uapi.rst somewhere
10:45 emersion: but status isn't a prop?
10:45 danvet: it's not?
10:46 emersion: it's a drmModeConnector field
10:46 danvet: uh
10:46 danvet: hm yeah
10:46 emersion: maybe it _should_ be a prop
10:46 danvet: maybe time to start document the uapi structs for real?
10:46 emersion: yeah
10:47 emersion: some things are already duplicated between structs and props, e.g. gamma size
10:47 danvet: emersion, for those I think we can just add a rst reference to the property docs
10:47 danvet: pq, if there's more compositor people who care about uapi docs, pls pull them in
10:48 danvet: emersion, just noticed, we pull in the uapi headers already
10:48 emersion: hm, but iirc gamma_lut_size in the struct should be used with drmCrtcSetGamma, and GAMMALUT_SIZE prop should be used with the GAMMA_LUT prop
10:48 danvet: so would boil down to just documenting that field
10:48 emersion: danvet: i believe the struct is duplicated in xf86drmMode.h
10:49 emersion: in libdrm
10:49 danvet: well probably need to doc the entire struct
10:49 danvet: yeah
10:49 emersion: all right, will do
10:49 danvet: I'm somewhat tempted to just pull the kms side of libdrm into the kernel and have one place for docs :-)
10:49 pq: jadahl, uapi docs ^
10:49 danvet: slight version bump from 2.4.whatever to 5.8 or so :-)
10:50 pq: I don't know others
10:50 emersion: oh, synchronizing the libdrm version with the kernel version would be interesting
10:50 jadahl: pq: we add a bunch of default modes yes
10:51 pq: jadahl, do you infer lid state from connector status? That's more the question.
10:51 pq: or do you rely on connector status to reflect lid state
10:51 emersion: i also guess we could remove the libdrm definition in xf86drmMode.h and #include <libdrm/drm_mode.h> (latter is already done iirc)
10:52 emersion: ah but the struct names are different
10:52 emersion: i think? need to double check
10:52 jadahl: the laptop lid? we get that from upower
10:52 emersion: libinput also has laptop lid support
10:53 emersion: that's what we use in wlroots
10:53 emersion: but maybe upower somehow uses that too
10:53 jadahl: upower doesn't use libinput as far as I know
11:53 st3r4g: Do you know if anything besides xorg is using /usr/lib/pkgconfig/dri.pc to discover the dri drivers directory? Isn't it supposed to be an internal detail of mesa?
12:42 MrCooper: st3r4g: Xorg has its own DRI driver loader which needs to know where to look for them; I'm not aware of anything else
12:51 st3r4g: so I assume it was made specifically for xorg and nothing else needs it
12:52 kusma: MrCooper: Do you think we can land https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5469 soon? If not, would you mind taking it off my hands? I'm asking because I'll be away on vacation next week, and I have some deadline-stuff to deal with, so my time is running a bit low.
12:53 kusma: I think what's there is at least better than what we have now, but that bar might not be too high ;)
12:56 agd5f_: danvet, yeah, I think Christian will commit to drm-misc
13:03 danvet: dj-death, do you have drm-misc commit rights? if not I guess you can ask könig or mlankhorst to push for you
13:05 dj-death: I guess König will pick it up
13:09 danvet: dj-death, can you pls ping him after ci passes and approves too?
13:10 dj-death: sure
13:39 MrCooper: kusma: I'm busy this week as well, but I can take it over next week if it hasn't landed yet
13:45 mripard: tzimmermann: simplekms \o/
13:52 danvet: dj-death, I thought I asked könig to document why timeline is strictly ordered, but I can't find it in the docs
13:52 danvet: maybe it was in a commit message only?
14:19 dj-death: danvet: not sure, we should document it though
14:29 emersion: danvet: ae2a6da876298 says "There are no separate #defines for the uapi!" about enum drm_connector_status
14:49 MrCooper: speaking of docs, something like https://gitlab.freedesktop.org/wayland/weston/merge_requests/318 might be nice for Mesa as well
14:49 gitbot: wayland issue (Merge request) 318 in weston "WIP: Documentation preview from CI" [Documentation, Opened]
14:52 kusma: MrCooper: Cool, thanks. The docs-preview seems like a nice idea aswell :)
14:54 thaytan: Lyude, confirming that the TCON brightness control works here too with a hacked up version of that patch applied to Linus' tree
14:54 thaytan: https://gist.github.com/thaytan/7cba2e4170dcd16119bc2c4f82426566 is the patch I'm testing
15:19 clever: mripard: are you about?
15:23 mripard: clever: ?
15:29 clever: mripard: ive been working on the rpi display pipeline lately, and was wondering if you could help with some questions
15:30 j4ni: I'm getting this while regenerating drm-tip http://paste.debian.net/1153820/
15:30 j4ni: feeling a bit clueless with the amd conflicts
15:30 mripard: clever: shoot
15:31 clever: mripard: on the rpi4, PLLH (i think) is failing to lock, and none of the hdmi hw comes online
15:31 clever: rpi3*
15:31 clever: on the rpi4, ive tried bringing DPI up with baremetal, but no sync pulses come out of it yet
15:33 clever: let me boot the pi up
15:36 danvet: j4ni, ask mlankhorst to figure it out I think?
15:36 danvet: also könig didn't resolve it when pushing
15:38 clever: mripard: https://gist.github.com/cleverca22/e6089adde0331af6721b4726ee443ee5 shows that plla and plld arent locking, and the hdmi hw depends on plld
15:38 danvet: j4ni, I kicked the right thread
15:39 danvet: agd5f_, maybe needs you or hwentlan not sure könig is still around
15:39 danvet: mlankhorst, ^^ double check with amd before doing that backmerge
15:40 clever: mripard: would you be able to help with getting the hdmi hw online, without the firmware helping out?
15:41 j4ni: danvet: I did a drm-next backmerge to dinq
15:41 j4ni: danvet: can't get the drm-tip rebuild done after that now
15:41 danvet: uh
15:42 danvet: ok, then I'm not going to hit send on this one :-)
15:42 j4ni: however the conflict is *before* it gets to dinq merge to drm-tip, so I think the amd conflict is underlated
15:42 danvet: yeah
15:42 danvet:resurrects draft
15:43 mripard: clever: so that's without the firmware ?
15:44 clever: mripard: yeah
15:44 clever: mripard: custom firmware, that isnt aware of how to init the display pipeline
15:44 mripard: I know that one of the thing the firmware does is changing the voltage of the PLLs
15:44 mripard: based on the frequency that they're supposed to be running at
15:45 clever: ive not seen any sign of that yet
15:45 mripard: so that's probably what you're missing
15:45 danvet: j4ni, hopefully agd5f_ or hwentlan can fix it up, otherwise könig tomorrow I guess :-/
15:45 mripard: but I don't have any knowledge on the clock tree, so I can't really help you more than that :/
15:45 clever: mripard: this cmd lets you view the entire clock tree: https://gist.github.com/cleverca22/2c3bd998e08a2d2c282bc735494792e3
15:46 clever: that output is from under the official firmware
15:47 clever: mripard: i could try running PLLD at lower clocks, to confirm/deny if its just clocked too fast for the voltage..., something i should try this weekend
15:51 clever: mripard: seperate from the PLL issue, do you know much about the DPI interface, does it support 0 vsync length?
15:52 mripard: I haven't tested DPI yet :/
16:00 clever: let me pastebin the other code i have...
16:01 clever: mripard: i tried this on an rpi4, and it doesnt create any sync pulses yet, https://gist.github.com/b42e8e36239407f511424053a0dc47bf
16:20 agd5f_: danvet, I think Christian fixed it up. Let me know if you need me to take a look
16:22 danvet: agd5f_, lgtm, thx a lot
16:27 j4ni: +1
16:44 shadeslayer: anholt_: re DRM Labeling patches, just so that we're on the same page, once I hook up glLabel'ing, do you think that's a good enough userspace coverage with the IGT tests, along with the label'ing functionality that I've already in mesa?
16:44 shadeslayer: I just want to make sure that spending time and effort on this would lead to this moving forward
16:53 shadeslayer: *would lead to the drm patches moving forward
17:17 emersion: mattst88: hi, would it be possible to get a new glvnd release? that would help with https://gitlab.freedesktop.org/mesa/mesa/-/issues/2102
17:17 mattst88: emersion: yeah. let me take a look
17:22 mattst88: emersion: I assume it's https://gitlab.freedesktop.org/glvnd/libglvnd/-/commit/4acb9be27db57413b18f25c6483b3451ba41d7e4 that fixes the issue?
17:22 emersion: mattst88: yes!
17:24 mattst88: ffs. kyle turned on -Werror. definitely going to have to rip that out
17:25 emersion: distros generally turn it off
17:26 emersion: but yeah, better not to have any warning if it's enabled
17:26 HdkR: and then your build environment changes, new warnings come up, and the world breaks :)
17:27 emersion: it's fine if it breaks for people building from source
17:28 emersion: people will just send some patches to fix it
17:28 emersion: (distros can turn it off via the CLI -- no need to patch the meson file)
17:30 mattst88: emersion: how does one turn it off without modifying the meson file?
17:30 emersion: meson build/ -Dwerror=false
17:30 anholt_: default -werror is always wrong. you should -werror in your ci, you shouldn't any end user deal with "my compiler failed to analyze these specific return paths to determine this variable is always set"
17:31 emersion: anholt_: depends, we treat our end users as contributors, so we're fine with it
17:31 mattst88: agreed. I don't think it's fine if it breaks for people building from source since the set of warnings is dependent on at least compiler, compiler version, optimization level, CPU architecture, and dependency headers
17:31 emersion: "end user building from source" isn't exactly everybody, too
17:31 mattst88: just distros, whose lives we're happy to make harder then? :)
17:32 emersion: distros need to change the defaults anyway
17:32 emersion: to set optimization level and so on
17:33 mattst88: and when a new compiler version comes out, they should reinvestigate every new warning that has been turned into an error? :)
17:33 emersion: distros should turn werror off
17:33 emersion: just like distros shouldn't use the default optimization level
17:33 mattst88: and for autotools that means patching out configure.ac and regenerating the stuff in the tarball
17:33 emersion: yeah, autotools is different
17:34 emersion: disclaimer, i don't know how autotools works
17:34 pzanoni: maybe developers that want werror could have a way to enable it for their environments if they want... forcing it on everybody is counter-productive
17:34 emersion: pzanoni: why counter-productive?
17:34 Lyude: emersion: disclaimer - no one knows how autotools works
17:34 Lyude: we just hope we do
17:34 emersion: ahah
17:34 mattst88: emersion: counter-productive because everyone doesn't want to drop what they're doing to fix warnings that shouldn't have been errors
17:35 mattst88: (e.g., right now I was going to make a release for you, but here I am)
17:35 emersion: as a maintainer, i want people to do this
17:35 pzanoni: emersion: because someone with an old compiler may commit something that I will fail to build because I have a different/newer one, and now I'll be blocked from doing the stuff I was originally doing because this new error preventing me from building the source
17:36 emersion: to be fair, i'm not arguing you should all default to werror
17:36 emersion: just saying it's not nuts to enable it by default, it just depends what your priorities are :)
17:36 mattst88: emersion: my experience contributing to wayland a few months ago was entirely consistent with the position that you don't care about distros, so yeah :)
17:36 emersion: it has nothing to do with distros
17:37 emersion: since distros change the defaults
17:37 emersion: (i don't remember what our discussion from a few months ago was about…)
17:37 airlied: emersion: it's hostile to enable it by default, anywhere outside CI
17:37 emersion: not hostile, it just asks people to send patches
17:37 airlied: no it's actively hostile
17:38 pzanoni: it blocks people from working because not everybody uses the same cmpiler
17:38 airlied: esp if people are building from releases etc
17:38 emersion: if people use my software, i want to encourage them to contribute
17:38 airlied: emersion: that isn't how you do it
17:38 emersion: maybe their build options make it so something dangerous is happening, not caught in CI
17:38 airlied: you encourage people to contribute by making software people wnat to contribute to, not my enabling -Werror outside CI
17:38 emersion: airlied: well it has worked _very_ well so far
17:39 mattst88: I understand the sentiment -- I really do, but it's /not/ what people want to spent their time doing
17:39 airlied: it also totally fails distros, who do rebuilds with newer compilers
17:39 emersion: again, keep it disabled for you projects, i;m not asking anything :P
17:39 mattst88: and distros don't want to have to take an interrupt to fix every new warning
17:40 emersion: again, distros have -Dbuildtype=release and a bunch of other things
17:40 emersion: it's trivial to add -Dwerror=false
17:40 airlied: emersion: most distros do stuff with macros, adding hurdles is a bit silly
17:41 airlied: I think for glvnd we can kill it
17:41 mattst88:is writing the commit message for that patch
17:41 emersion: macros?
17:41 emersion: yeah yeah feel free to kill it
17:43 airlied: emersion: they have a default meson macro at least I think rpm does or it will soon, and it provides a bunch of distro options across all packaegs, I suppose it could add -Werror=false to the system-wide macro but seems excessive
17:44 emersion: why would it be excessive?
17:45 airlied: might not be, just have to see if it would be painful
17:46 emersion: i wonder if it's ever a good idea to enable it for a distro
17:48 mattst88: airlied: https://gitlab.freedesktop.org/glvnd/libglvnd/-/merge_requests/229
17:49 mattst88: emersion: upon conclusion of that MR I'll tag a v1.3.2
17:49 emersion: mattst88: many thanks!
17:51 mattst88: emersion: btw, are we looking at a new wayland release anytime soon? (just curious, since I'll need to rework stuff in gentoo for the wayland-scanner changes)
17:51 emersion: mattst88: yeah, i need to prepare the schedule
17:51 emersion: will do tomorrow, thanks for the heads-up
17:52 mattst88: cool, thanks :)
18:01 Lyude: anholt_: btw, going to work on the intel backlight stuff now
18:06 thaytan: Lyude, I pinged you earlier, in case you missed it
18:06 Lyude: thaytan: oh! just noticed it in my highmon, that's good to hear
18:08 thaytan: cheers
18:09 Lyude: btw thaytan, if you pm me your email I can cc you on the patches as well
18:23 daniels: mattst88: the problem wasn't distros, it's that you were needlessly raising reasonable conversations into aggression. the fact you've come past for more drive-by shitting on people does definitely reinforce the number of times I looked at those issues/MRs and then closed them because I had better things to do with my life than get into the world's most pointless confrontation.
18:23 daniels: (we've already known about the -Werror thing for years, which is why Wayland and Weston don't enable it by default, and do enable it in CI. and wlroots isn't Wayland. but you knew that already.)
18:23 mattst88: sorry, that wasn't intended as drive-by-shitting
18:25 mattst88: I don't recall a confrontation wrt wayland, but I do recall an extraordinary amount of explanation to multiple people about something I explained to dcbaker in 5 minutes
18:25 mattst88: so, yeah, I'll certainly admit a lot of frustration
18:28 mattst88: but tbh, I think that was from you guys being far too quick to dismiss my requirements and as a result didn't really want to listen :)
18:28 daniels: ok :)
18:38 mdnavare: hwentlan: I am not able to merge the Revert patch in amdgpu tree through drm-misc since the hdcp related changes in amdgpu tree are not pulled into the drm-misc tree, should i ust merge the drm core patch for now and the madgpu patch gets merged later after the rebase in the amdgpu tree directly?
21:03 Lightkey: anholt_: I looked into the v3d driver capabilities because dhewm3 runs out of the box and to my surprise saw it advertising GLSL 3.30 when features.txt shows something very different. A few days ago support for GL_NV_primitive_restart was even reverted, which is part of OpenGL 3.1 because the hardware can't do it.
21:04 Lightkey: https://gitlab.freedesktop.org/mesa/mesa/-/commit/6c8edcb89c1264c43f5e98444551edb8df2f91f9 I found this commit and was wondering if this is done the same for other drivers, is the advertised OpenGL level going to stay there or will it be matched with reality?
21:14 kisak: what's wrong with supporting a GLSL feature set higher than the typically paired desktop GL version?
21:32 mdnavare: agd5f_: Any suggestions on this merge conflict since the amdgpu changes not pulled into drm-misc?
21:40 agd5f_: mdnavare, whatever is easier for you. If you want to merge the core stuff, I can add the revert once the branches are aligned.
22:12 mdnavare: agd5f_: Yes lemme do that , I am merging the core patch now
22:12 agd5f_: mdnavare, sounds good
22:38 mattst88: emersion: libglvnd-1.3.2 is out :)
22:54 mdnavare: agd5f_: Thank you, done merged the drm core patch
23:46 jekstrand: jenatali: I feel a bit dirty after reviewing your patches. Not that your code is bad. It's just... printf... :-/
23:46 jenatali: jekstrand: Just don't look at the runtime bits ;)
23:47 jenatali: jekstrand: Thanks for looking
23:47 jekstrand: jenatali: BTW, if you can come up with a good interface (array of format string + id pairs or something), that seems like a fine sort of thing to have in NIR common code so karolherbst can wire it up for clover.
23:48 jekstrand: Assuming karolherbst cares, of course.
23:48 jenatali: Right now it's [buffer size][format string pointer][arg1][arg2][format string pointer][arg]...
23:49 jenatali: And the runtime converts the pointers into strings (since they're constants) and parses them to figure out how many args to load and how big they are
23:49 karolherbst: jekstrand: you mean for the runtime printf stuff?
23:49 jekstrand: karolherbst: yeah
23:49 karolherbst: I'd would have at least the format string + param stuff inside common code
23:49 karolherbst: the buffer handling I don't care as much about
23:50 jenatali: You mean the lowering pass from printf intrinsic to SSBO ops?
23:50 karolherbst: jenatali: no, the CPU side
23:50 jenatali: Ah, got it
23:50 jekstrand: jenatali: Right. What I meant was that you'd return an array of type struct nir_printf_format { uint32_t id, char *str } from the lowering pass and then the runtime code could do whatever it wanted with that.
23:50 karolherbst: like after you parsed your buffer
23:50 karolherbst: of course we could also have the same buffer format
23:50 jekstrand: And then just have a comment somewhere that says "the buffer is laid out as follows"
23:50 karolherbst: then we can share even more
23:51 karolherbst: jekstrand: maybe something that has a void* input and a char** output?
23:51 karolherbst: jenatali: ^
23:52 karolherbst: + buffer size or something
23:52 jenatali: jekstrand: I know the format string has to be __constant, but I'm not sure that the pointer selection needs to be static. I.e. could use one of two format strings, or one of two string args
23:52 jekstrand: jenatali: Yeah, that has me worried
23:53 jenatali: And the way we do pointer -> string lookup in the runtime is specific to the addressing modes we're using, the 32bit_buffer_id_offset_pack64
23:53 karolherbst: jenatali: uff...
23:53 jekstrand: jenatali: You do have the types, though, because you have the number of arguments embedded in the SPIR-V opcode.
23:53 jekstrand: jenatali: Ugh... Yeah.
23:53 jenatali: jekstrand: Right, the promoted types at least
23:53 karolherbst: the fuck..
23:53 karolherbst: wait..
23:54 jekstrand: jenatali: Right... That's why you're storing the string pointer and not a more generic id.
23:54 jekstrand: Hrm...
23:54 jekstrand: That's annoying.
23:54 jenatali: Yep, exactly
23:54 karolherbst: ufff
23:54 jekstrand: I guess if you could some how ensure that the strings landed in the nir_shader::constant_data, we could take advantage of that somehow.
23:54 karolherbst: yeah.. that is annoying indeed
23:55 jenatali: jekstrand: My first thought was to just use the SPIR-V val ID, but that didn't seem right to go through NIR, and then I realized there might be logic to select one of many
23:55 karolherbst: jekstrand: constants* are kernel inputs though
23:55 jenatali: karolherbst: I believe all strings do have to be inline consts at least
23:55 karolherbst: jenatali: can you pass in a kernel parameter?
23:55 jekstrand: Wait, you can have an arbitrary kernel input as a format string?????
23:55 karolherbst: " int printf(constant char * restrict format, ...);" is the definiiton at least
23:55 jenatali: jekstrand: No, all strings (format strings and %s vals) need to be inline constants
23:56 karolherbst: "As format is in the constant address space it must be resolvable at compile time and thus cannot be dynamically created by the executing program, itself."
23:56 karolherbst: mhhhhh
23:56 karolherbst: that's not.. explicit enough for me
23:56 jenatali: Oh, you're right
23:56 karolherbst: the kernel can't creat them.. right
23:56 karolherbst: but...
23:57 jenatali: karolherbst: My compiler bits could handle that but my runtime would fall over right now. Though it's totally handleable with just a bit more code
23:57 karolherbst: jenatali: yeah...
23:57 karolherbst: but then we need everything inside the buffer
23:57 jekstrand: From the OpenCL C spec: The format is in the constant address space and must be resolvable at compile time, i.e. cannot be dynamically created by the executing program itself.
23:57 karolherbst: so you have even less options to be smart
23:57 jekstrand: Oh, karolherbst just quoted that
23:57 karolherbst: yeah...
23:58 karolherbst: but yeah.. at compile time we
23:58 jenatali: karolherbst: Yeah, at least the pointer to it, not necessarily the data. The data has to be retrievable either from the shader or the kernel args, you don't need the GPU to write the full string
23:58 karolherbst: jenatali: uhm...
23:58 karolherbst: you have to
23:58 karolherbst: if else code and shit
23:58 jenatali: Right, to select a pointer
23:58 karolherbst: you could even do this:
23:59 karolherbst: if (some_cond) fmt = some_input; else fmt = &default_kernel_fmt; printf(fmt, ...._
23:59 karolherbst: or not?
23:59 jenatali: karolherbst: Yep, I believe so
23:59 karolherbst: well
23:59 karolherbst: the runtime could pass in an id...
23:59 karolherbst: but uff
23:59 karolherbst: then we need to know how the stuff is used
23:59 karolherbst: and it could be used for something else
23:59 karolherbst: so yeah.. we'd need to copy the full string