00:11 anholt: Kayden: did you ever come up with a plan for "No suitable configuration found for GL config rgb565d0s0ms0 at glcTestRunner.cpp:"?
00:14 mareko: I wonder if z16s8 is worth adding into GL(ES)
00:14 robclark: idr, btw, any major objections to https://hastebin.com/raw/onomobazok (in case you missed it on list)? That plus landing a couple freedreno patches is what is standing between me and gles31 ;-)
00:15 robclark: imirkin a-b it.. just wanted to make sure it didn't sneak thru under the radar if someone objected
00:19 idr:looks...
00:21 idr: robclark: The hastebin won't load. Is that "mesa: fix GLES 3.1 version calculation" ?
00:22 anholt: yeah
00:22 robclark: yeah, with one addition that I mentioned on thread to check for MESA integer extension
00:22 robclark: I can re-send to list if hastebin doesn't work
00:23 idr: Yeah... that should be safe.
00:23 idr: robclark: I trust the change is the obvious one from imirkin_'s suggestion.
00:23 robclark: idr, https://paste.fedoraproject.org/paste/nX4jirVpiqrlnXksYCGVvA/raw
00:24 idr: robclark: You can put Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> on that.
00:24 robclark: cool, thx
00:25 anholt: robclark: what window system are you doing conformance runs on?
00:25 robclark: I'll push that tomorrow after pushing the real msaa support bits.. and then a5xx GLES31 \o/.. and then on to GS+HS+DS+kitchen-sink :-P
00:26 robclark: x11
00:26 robclark: mostly because that is what my deqp is built for
00:26 anholt: DEQP_TARGET=x11_egl?
00:26 idr: Oh that mess.
00:27 robclark: yeah
00:27 anholt: also, are you running master deqp, or VK-GL-CTS?
00:27 robclark: (should I be trying something else)
00:27 robclark: master deqp.. as of maybe a week or two ago..
00:27 anholt: I want to figure out how to do a conformance submission, and every time I try I lose a couple of days and give up.
00:27 robclark: not 100% passing but I've made some progress.. https://hastebin.com/ilamosebep.css
00:28 robclark: I'm not really ready to do conformance submission..
00:28 anholt: that doesn't seem to render anything
00:28 robclark: but ready to stop forgetting to have to add MESA_*_OVERRIDE env vars ;-)
00:29 robclark: whether you get something on screen depends on --deqp-visibility=hidden or not
00:29 robclark: (or maybe I misunderstood the question?)
00:29 anholt: your hastebin
00:29 robclark: bleh.. hastebin must be ddos again.. one sec..
00:30 robclark: anholt, https://paste.fedoraproject.org/paste/YzHHOX~7n3zZPe2asyOjjQ/raw
00:31 robclark: (although this was before I realized that gles31 module wasn't a proper superset of gles3 module.. so I probably need to run both)
00:32 robclark: a good chunk of the fails are "you need to implement spilling" things unfortunately :-(
00:32 anholt: nice. piglit's deqp and khr_gles targets with gles31/32/ext skipped is getting >99.8% passrate for me now, so I think conformance might be close
00:32 anholt: some of the deqp fails look like things that might be disabled in proper vk-gl-cts
00:33 anholt: (#define define and stuff like that)
00:33 robclark: I should figure out what proper vk-gl-cts is.. for now I've just been running "everything that deqp_gles31 gives me"
00:38 robclark: btw, it would be nice if piglit could split up deqp into N(== # of cpu's or so) threads, and then restart things when something crashed.. for the few remaining crashers.. the process per test thing doesn't work well we/ deqp for test duration)
00:38 airlied: robclark: there was a branch
00:38 anholt: I thought mareko had stuff for that
00:39 robclark: (there is always a branch ;-))
00:39 robclark: but yeah, would be nice to see something like that merged
00:39 airlied:has been using group at at time branch for a while for vulkan
00:40 airlied: https://github.com/dcbaker/piglit/commits/submit/deqp-group-run
00:40 robclark: hmm, I'd be interested in trying it..
00:40 airlied: I think is the one I've used
00:40 robclark: ok.. I'll play with that for the next run
00:41 airlied:hasn't had much luck with piglit deqp lately, seems to be GLX related, crashes trying to generate testlists
00:41 mareko: robclark: my deqp branch has deqp without process isolation running 100 tests per process and re-starting on crashes, but it's rebased by reverting stuff from master
00:41 imirkin_: i could never get testlist generation to work
00:41 imirkin_: i just use the mustpass lists in VK-GL-CTS, that's been ok
00:41 imirkin_: that said, i haven't tried to actually run it in several months
00:42 robclark: mareko, ok.. nice.. I should try that.. is dcbaker's github branch the thing to look at or should I look elsewhere?
00:43 mareko: robclark: I'm not able to rebase it and if nobody can, it's a dead end; it however works out of the box
00:43 robclark: hmm..
00:43 mareko: it's also the only piglit branch I'm using on a daily basis
00:44 mareko: because fast deqp is something I care about
00:44 robclark: well, I mean since I'm just using piglit as deqp runner, I guess I don't care as much about piglit branch as deqp branch
00:45 mareko: for that, it's all you need
00:45 robclark: got pointer to branch I should look at?
00:46 mareko: robclark: there is not much to look at unless you are a python/piglit expert: https://cgit.freedesktop.org/~mareko/piglit/log/?h=deqp
00:46 anholt: airlied: piglit deqp, or khr_gles/gl?
00:47 robclark: mareko, thx.. well s/look at/use/ ;-)
00:47 airlied: anholt: oh maybe I used khr_gles with deqp
00:47 airlied:has tried a few different things, and just given up as I don't care enough yet
00:48 mareko: robclark: I use it all the time, in fact I don't use master
00:48 airlied:gets confused in the mess, and I think it matter how deqp is configured
00:48 anholt: airlied: with khr_gles, you need version overrides to 4.6 / 3.2 for testlist generation
00:49 anholt: I should probably actually submit that patch
00:49 mareko: robclark: the branch also handles CTS the same as dEQP, i.e. without process isolation (assuming you disable that with the piglit parameter)
00:50 anholt: our testlist generation is also absurd, since we regenerate the set of all tests on each iter_deqp_test_cases call.
00:50 robclark: mareko, thx.. I think this should be fine for now (although I guess it means seperate piglit checkouts for piglit vs deqp.. but that is fine)
00:51 mareko: the piglit results format is also changed by that branch
00:52 robclark: hmm, I already have my own patches for piglit-summary.. plus some sed scripts on top of that for deqp... but meh, I can figure that out
01:11 tarceri: Is there a date for the 18.2 branch? The release calendar only has dates from the rc which I assume is not the same day we branch https://www.mesa3d.org/release-calendar.html
01:12 airlied: tarceri: I think it normally branches on rc1
01:14 tarceri: ok cool :) I'm just wondering as that means we might have time to see GL 4.5 compat enabled for radeonsi
01:38 mareko: tarceri: FYI, I relaxed requirements for ARB_shader_viewport_layer_array
01:46 tarceri: ok
01:49 tarceri: mareko: How much work do you expect ARB_draw_indirect to be? I've skipped over that one for now as I'm not sure whats involved exactly
01:51 mareko: tarceri: if we ignore legacy render modes, it's easy
01:52 tarceri: everything else seems relativity straight forward, although ARB_vertex_attrib_64bit looks like maybe it could be more involved not that familiar with some of that code
01:54 tarceri: mareko: I guess if we do ignore some stuff we can just pull those bits out of your doc and add it to a mesa compat todo
01:56 mareko: yeah
02:00 tarceri: Anyway I'm going to do the compute display list stuff next, I should probably write some more tess tests after that before trying to enable 4.0
02:02 tarceri: although I'm not expecting any real issues with those shaders
02:04 mareko: tarceri: piglit/tests/shaders/glsl-clamp-vertex-color.shader_test is for the color clamping that also applies to GS and tess
02:06 tarceri: ok, I'll adapt that thanks
04:13 atomnuker: jekstrand: what's going on with the damn vulkan dmabuf descriptors extension? its been more than a month since you said it would be merged
04:13 atomnuker: what the hell are the people at khronos doing all day?
04:14 HdkR:imagines a Khronos company boardroom meeting of people just reading specs all day
04:15 Plagman: the people at khronos have day jobs to do all day
04:16 Plagman: because it's just people like jekstrand and all the other devs here going to khronos meetings
04:16 Plagman: there's no "khronos people"
04:16 mareko: or not going
04:23 atomnuker: right, I forgot its a consortium
04:24 atomnuker: but even we at the AOM (we've yet to complete a codec) don't take half a year to discuss and merge proposals
05:04 krh: the khronos konspiracy
05:21 Kayden: oh nice, no more var uses for call parameters
05:21 Kayden: nothing magical about them anymore
06:19 danvet: krh, jekstrand, just pondered future fences some more
06:19 danvet: I think we should call them dma_fence_promise
06:19 danvet: to make it more obvious the promise might be broken
06:19 danvet: "future" sounds to certain :-)
06:20 danvet: so dma_fence_promise would represent a promise that in the future a real dma_fence might show up
06:20 danvet: with a struct completion indicating when that actually happened
06:20 danvet: just thoughts on kernel internal implementation details really
06:20 danvet: ickle, ^^
06:32 ickle: I called it dma_fence_proxy, who hasn't done a future dma_fence?
06:35 danvet: "future" was just the name that was coined when we first discussed this
06:35 danvet: _proxy sounds good too
06:35 danvet: but _promise leads to some neat function names :-)
06:36 danvet: dma_fence_promise_await and dma_fence_promise_fulfill
06:36 ickle: too strong though
06:36 ickle: we always break our promises
06:37 danvet: that's why I like it, makes it clear you need a scheduler/reset logic
06:37 ickle: the usual downside with timeline + unknown syncpt is loss of priority inheritance
06:37 danvet: yeah, can't have everything
06:37 danvet: but as soon as the job is scheduled we should be able to do pri boosting
06:38 danvet: before that we'd need to boost the cpu I guess, to get the app to assemble the job faster
06:38 ickle: but you've lost most of the battle by that point
06:39 danvet: why?
06:39 danvet: assuming we'd boost as soon as the promise is fullfilled ofc
06:39 ickle: you're only reordering already executing tasks
06:39 danvet: which is the same point non-future fences can start boosting
06:40 ickle: you're not going back into the history to push your deps earlier so you get scheduled earlier
06:40 danvet: hm, I thought the point of these is that it makes it easier for userspace to build deep queues
06:40 danvet: so would give us more to schedule
06:41 danvet: ah, you mean for the case where
06:41 danvet: a) submit job A
06:41 danvet: s/a/1/
06:41 danvet: 2) submit job B, waiting for fence promise X
06:41 danvet: 3) long delay with other stuff
06:41 danvet: 4) userspace fullfills promise X with job A
06:41 danvet: ?
06:42 danvet: my expectation of the real world use-case is more like
06:42 ickle: don't forget the competion with task B
06:42 danvet: 1) submit job A, waiting for fence promise X
06:42 danvet: 2) lots of other stuff going on, make cpu scheduler starving
06:42 danvet: 3) submit job B, which in the same ioctl also fulfills fence promise X
06:43 danvet: upside for userspace is that it can do 1 & 3 in separate and entirely unsynced thread
06:43 danvet: *threads
06:43 danvet: kernel would still be able to boost as much as without fence promises
06:44 danvet: at least that's my understanding of why userspace wants this
06:44 danvet: haven't heard of a use case where there's a separation between submitting a job and using that to fulfill fence promises
06:44 ickle: I saw it more as not in the ioctl the promise is fulfilled, but at some later point the job B fulfills the promise from the GPU
06:44 danvet: just the desire to decouple submission of different parts in a pipeline a bit
06:45 ickle: so just syncpts along the timeline
06:45 danvet: hm
06:45 danvet: so you mean stuff like vr compositor and game renderer submit stuff in parallel
06:45 danvet: and at a later time decide how exactly to sync stuff up?
06:46 danvet: not sure how that can work (given that they'd need to switch their render targets too)
06:46 ickle: just if someone says hey, we using a timeline of seqno to coordinate jobs, that what I expect they want
06:48 danvet: so one use-case I know of is having more render jobs in-flight that buffers allocated
06:48 danvet: for tiling architectures, which have too deep queues
06:49 danvet: allows you to do the tiling before the compositor gives you back the buffer
06:49 danvet: another one I've heard of is just threads pushing out their respective parts of the overall render job as fast as possible, without syncing
06:50 danvet: with something like "for each frame you take #frame*2, I take #frame*2+1 as the slot"
06:50 danvet: or however many fences you need to get a frame done
07:29 stdint: I have a problem with
07:29 stdint: the page flip in drm atomic
07:29 stdint: the kernel would allocate a struct drm_pending_vblank_event, but I don't think a way to release it
07:33 stdint: my kernel is a little old, it is at 4.4, should I update the kernel or there is something I should do in userspace?
07:59 danvet: stdint, 4.4 is very old
08:00 danvet: not sure when, but we refactored all the vblank even handling, and now the core code takes care of allocating and freeing it
08:00 danvet: as long as the driver makes sure the even is signaled at the right time
08:00 danvet: using either drm_crtc_arm|send_vblank_event
08:17 stdint: I found the problem is in drm_event_reserve_init(), failed at if (file_priv->event_space < e->length)
08:18 stdint: is there some additional operation I should do for commit with flags |= DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK;
08:18 stdint: or anything I should do to clear the event space?
08:19 stdint: or anything I should do to clear the event space?
08:23 daniels: stdint: you need to read the event from the fd
08:23 ayankh: Can someone help to review my set of patches? https://lists.freedesktop.org/archives/dri-devel/2018-June/180124.html . I would like someone (outside my current organization - Arm) to provide comments on the patch series.
08:23 stdint: daniels, is there any example code to do that?
08:23 stdint: daniels, it is something new in atomic right?
08:23 daniels: stdint: no, it's been that way forever, including pre-atomic
08:24 daniels: stdint: you can search this https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset-vsync.c for drmHandleEvent
08:24 stdint: I check the legacy code, drmHandleEvent()
08:24 daniels: stdint: drmHandleEvent() isn't legacy, it's still used for atomic as well
08:25 daniels: ayankh: the major issue with your patchset is that there's (AFAIK) no producer for AFBC yet. in order to see it merged, we'd need to also have a real-life open-source userspace which would produce AFBC buffers
08:25 stdint: daniels, ok then drmHandleEvent() is still necessary in atomic time but not drmModePageFlip()
08:26 stdint: and would you mind reviewing this gstreamer plugins in a later time https://bugzilla.gnome.org/show_bug.cgi?id=796516
08:26 daniels: stdint: correct; if you pass DRM_MODE_PAGE_FLIP_EVENT to drmModeAtomicCommit() then event handling acts almost exactly the same as if you were calling drmModePageFlip, with the exception that it will instead call .page_flip_handler2 rather than .page_flip_handler if your drm event context version is new enough
08:27 daniels: sure, i can check gst in a bit
08:27 stdint: I would fix the page flip in that plugin and upload it later
08:28 ayankh: daniels: Do you suggest adding AFBC support in drm hardware composer? Or are you suggesting some other userspace application? Please let me know.
08:29 daniels: ayankh: i mean adding support for something which can produce (not just consume, like KMS) AFBC buffers in another subsystem, like V4L2 or GPU :)
08:30 stdint: I am sure the ARM Mali can product the AFBC memory in gbm
08:34 daniels: stdint: right, mali can produce afbc, but we need an open-source userspace for that
08:35 stdint: Let me check the vop(drm) of rockchip, it has a write back function
08:36 stdint: ok, it doesn't
09:11 stark3y: daniels: I spoke to danvet about this specifically a few times. He said no open source producer would be required
09:12 daniels: stark3y: oh right, i've misunderstood then, sorry
09:12 stdint: e->event.vbl.user_data = vblwait->request.signal
09:12 stdint: so in the atomic, the user_data for .page_flip_handler2 would be always null, and there is no such way to assign a data for it right?
09:13 stark3y: Something along the lines of drm_fourcc.h being excluded from the usual userspace requirements
09:13 danvet: stark3y, daniels yeah imo it's just a registry
09:13 danvet: wrt the implementation, meh
09:14 danvet:not picking every possible fight :-)
09:15 stark3y: Given it's a vendor namespace I'd sort of expect vendors to be able to shoot their own feet...
09:15 danvet: yeah drm_fourcc.h allocations aren't a problem
09:15 FireBurn: https://people.freedesktop.org/~imirkin/glxinfoimirkin: Are you still updating
09:15 danvet: I guess you could make a case for the actual afbc implementation in malidp
09:15 FireBurn: Grr
09:15 stark3y: That said, we would very much like to receive feedback on the approach, to understand if it's amenable to the open-source graphics stacks
09:15 FireBurn: imirkin: Are you still updating https://people.freedesktop.org/~imirkin/glxinfo
09:16 stark3y: We mostly work in an Android world, where things are quite different
09:16 danvet: I have no idea whether anyone with an open stack knows how to generate afbc
09:16 stark3y: So far, none of the other modifiers have been very similar to what we have. The BCOM SAND stuff has some similarities
09:17 stark3y: danvet: You don't need an open-source generator to use it in a weston stack - you can run closed-source Mali blob with weston
09:17 stark3y: You just need to pass around the modifier
09:18 stark3y: anyhow, point is AFBC seems to work quite differently from the other currently enabled vendor formats. We've defined a bitfield, and any thoughts the community can spare on whether that sucks or not would be really great :-)
09:21 danvet: stark3y, ask krh
09:21 danvet: he both knows afbc and has a non-android stack
09:21 stark3y: Yes, was just checking the ChromeOS patch
09:22 stark3y: krh: tfiga: Maybe you guys have some opinion on our AFBC modifiers: https://lists.freedesktop.org/archives/dri-devel/2018-June/180124.html
09:24 stdint: danvet, thank you
09:38 stdint: ok it user_data for page flip can be set in drmModeAtomicCommit()
09:43 mlankhorst: yes
10:05 nashpa: danvet: sorry for not running mancheck on the dim.rst patch. It looks like I can't have two 'status' sections though, so suggestions are welcome on that patch
10:17 danvet: nashpa, just combine them into the new one?
10:17 danvet: i.e. add the hint for what committers should do to the moved place
10:18 danvet: and remove the old status help text completely
10:23 nashpa: danvet: ok, I was playing (learning) with some explicit links to overwrite the implicit ones generated by the parser
12:09 ivyl: siqueira: hey, I'll merge two of the patches, thanks! the one with the string truncation - sorry for not being clear on the comment, but I am afraid that you have took it too literaly :P I presented the formula to get a sensible upper estimation, not to incorporate it in the code
12:09 nashpa: danvet: mlankhorst: sorry for the delay in sending v2 patch for dim.rst, but our foss.arm.com server has run out of disk space :(
12:10 nashpa: now I have to wait for IT dept to get the gears moving
12:11 ivyl: siqueira: so something like [30]; /* the longest string we write here is ... */ would be fine. snprintf with gcc 8.1 should complain anyway if the destination would be too small.
12:24 siqueira: ivyl, First of all, thanks :) About the formula, I really liked it (first time I have seen it), and then I thought that would be nice to have it in the code. Sorry for that hehehe
12:24 siqueira: btw, when I calculated it on my machine, I got just 10. Anyway, I will prepare a V3 with that fix.
12:25 ivyl: siqueira: just for that one patch, I am merging the other two right now :P
12:25 ivyl: siqueira: don't worry, and if your are in any doubt or I am not clear enough you can find me here
12:26 siqueira: ivyl, Thanks a lot. Next time I will ask you here :)
12:32 mlankhorst: nashpa: ah, I'll see if i can make IGT pass with your drivers restrictions, probably through use of try commit
12:39 robclark: imirkin, for features.txt update, does https://hastebin.com/rotuponuqi.patch look reasonable.. or am I mis-under-estimating some things?
12:40 imirkin: robclark: did you implement fma?
12:40 imirkin: (which is not the same as mul + add)
12:40 robclark: hmm, doesn't htat just come down to mad vs mul+add?
12:40 imirkin: (or actually, nevermind -- it's allowed to be.)
12:40 imirkin: no, fma generally has more precision
12:41 imirkin: the intermediate add has an extra bit of precision
12:41 robclark: hmm
12:41 imirkin: the main thing with fma() is to not do different things depending on the location of the fma() call. if you always break it up into mul + add, that's legal.
12:42 imirkin: did you really handle the ubo indices?
12:42 imirkin: this isn't indirect indexing into a constbuf
12:42 imirkin: this is indirect indexing into a *list* of constbufs
12:42 robclark: yeah, indirect indexing into the range of uniforms that have ubo addresse ;-)
12:43 imirkin: right.
12:43 robclark: that's kinda been there since the beginning
12:43 imirkin: did you really implement this? GL_ARB_compute_variable_group_size
12:43 nashpa: mlankhorst: not sure what drivers restrictions you are referring to
12:44 imirkin: this enables you to have an unknown compute group size at compile time, which implies that you have a way of getting things like the local invocation size from within the shader
12:44 karolherbst: robclark: do you have a fma vs muladd instruction?
12:44 karolherbst: or is it all fma or muladd?
12:44 imirkin: karolherbst: i believe neither ;)
12:45 robclark: imirkin, opencl has that.. actually I suppose technically some of the nir patches for that extension are still on the spirv-opencl branch
12:45 karolherbst: ahh, then fma would be problematic to implement
12:45 karolherbst: kind of
12:45 karolherbst: for opengl it would be fine
12:45 karolherbst: not for opencl though
12:45 karolherbst: well, if you care about CTS results that is
12:45 imirkin: robclark: otherwise looks reasonable
12:46 robclark: ok, I guess I should remove the GL_ARB_compute_variable_group_size part until the corresponding nir patches land..
12:46 imirkin: seems like a good idea :)
12:47 karolherbst: robclark: in case you have a native fma instruction, you have to take care of the precise flag and not merge mul+add -> fma if the mul or add is marked as precise ;)
12:47 karolherbst: but I don't think you do opts post nir?
12:50 robclark: I don't think the mad instruction is fma
12:50 imirkin: is there a mad.f32?
12:50 robclark: maybe nir needs separate opcodes for mad vs fma.. idk, I'll wory about that another day
12:50 robclark: yeah
12:50 robclark: float is 32b.. int is s24
12:50 imirkin: dunno.
12:51 imirkin: easy to check
12:51 imirkin: just have to feed it the right inputs and see what the result is
12:51 karolherbst: robclark: it doesn't really matter, because you can handle that already
12:51 karolherbst: robclark: .use_fma = false
12:51 imirkin: for something where the extra precision would matter
12:51 karolherbst: robclark: then fma is fma and mul+add stays mul+add
12:52 karolherbst: but yeah, maybe it would make sense to split it up
12:52 robclark: I mean, I don't want to *never* use mad ;-)
12:52 karolherbst: well, it depends ;)
12:52 robclark: (well, I mean for glsl)
12:52 karolherbst: if you don't have mad, just fma, then you don't always want to use it
12:52 karolherbst: even for glsl
12:53 karolherbst: there is a precise modifier which prevents mul+add -> fma merging
12:53 karolherbst: TombRaider depends on that for example
12:53 karolherbst: the reason I actually implemented it for TGSI
12:53 robclark: Not wanting to always use it != wanting to *never* use it ;-)
12:53 karolherbst: so you have to be very careful here and be 100% sure what mad.f32 is in practise
12:53 karolherbst: ahhh
12:53 karolherbst: right
12:54 karolherbst: anyway, there are games which care about that :)
12:56 robclark: without one of the variants of shader5 I think nothing in gles really cares.. and actually I guess 'precise' doesn't come in to gl until shader5?
12:56 karolherbst: my english is a bit weak here, "Rounding of intermediate products shall not occur." does it mean it isn't allowed to occur or just it isn't advised to?
12:57 robclark: I'd say not allowed.. "shall not"
12:57 robclark: (although I guess that is "should not" rather than "must not".. idk, not a spec lawyer)
12:57 karolherbst: right, that's the weak part
12:58 karolherbst: dunno
12:58 karolherbst: all I know is that english is a bit weird if it comes to those terms
12:58 ickle: https://www.ietf.org/rfc/rfc2119.txt
12:58 karolherbst: okay fma: "Correctly rounded"
12:58 robclark: I guess "should" is not as strong as "must", at least in every day speech..
12:58 karolherbst: in the spec
12:59 karolherbst: mad: "Implemented either as a correctly rounded fma or as a multiply followed by an add both of which are correctly rounded"
12:59 robclark: hmm, "SHALL" in same category as "MUST".. ok
12:59 karolherbst: :D "x * y + z": "Implemented either as a correctly rounded fma or as a multiply followed by an add both of which are correctly rounded"
12:59 karolherbst: you have to be clear about everything in the spec, right?
13:00 karolherbst: so yeah, in OpenCL fma has to be correctly rounded as it seems
13:02 karolherbst: robclark: there is also that invariant keyword
13:02 karolherbst: which means basically the same
13:02 karolherbst: or maybe precise doesn't exist really
13:03 karolherbst: ahh, invariant is for shader output variables
13:04 karolherbst: no idea when both of those were actually added to glsl
13:05 karolherbst: mhh glsl 1.20 :)
13:05 karolherbst: at least for invariant
13:06 nha_: robclark: just remember Gandalf in LOTR... you don't say "You shall not pass!" to the Balrog if you mean it as a polite suggestion ;)
13:06 robclark: heheh
13:07 karolherbst: precise was added in 3.30
13:07 karolherbst: ohh no
13:08 karolherbst: 4.00
13:08 karolherbst: so invariant: 1.20, precise: 4.00
13:08 karolherbst: 1.20 is GL 2.1, right?
13:09 karolherbst: robclark: there should be CTS tests for this though
13:10 karolherbst: robclark: "KHR-GL45.gpu_shader5.precise_qualifier"
13:11 robclark: sure, but I'm not trying to run gl45 cts yet ;-)
13:12 karolherbst: right
13:12 imirkin: robclark: s/45/31/ -- shouldn't matter
13:12 karolherbst: that's why I was telling you the one tests, so that you don't have to run it all ;) just if you are interested to figure out if it indeed works, that is
13:12 imirkin: as long as you have ARB_gpu_shader5
13:12 imirkin: (or GL 4.0)
13:12 karolherbst: imirkin: well, the CTS requires 4.4 anyway
13:12 karolherbst: kind of
13:13 imirkin: not at all, last i checked
13:13 karolherbst: I think it simply fails if you report anything lower
13:13 karolherbst: huh?
13:13 karolherbst: maybe they fixed it
13:13 karolherbst: or maybe that test is fine
13:13 robclark:not advertising ARB_gpu_shader5 (and I'm not even sure if blob supports the OES version offhand)
13:13 imirkin: if you run KHR-GL45 it desperately wants 4.5
13:13 karolherbst: right
13:13 imirkin: but if you run it as KHR-GL40 it'll just want 4.0
13:13 karolherbst: mhh, interesting
13:14 karolherbst: I am sure I tried to run those lower CTS versions at some point and it failed for this reason
13:14 karolherbst: but again, maybe they fixed that
13:14 imirkin: robclark: yeah, but you're claiming to support some sub-features of it, in which case you can just force-enable it to test
13:14 imirkin: karolherbst: yeah, a long time ago it was very broken. pretty sure there were fixes somewhere.
13:16 robclark: I'm not claming to support fused multiply/add.. I dropped that.. but I guess it might work ok if nir just gave those to me as mul+add, but I guess it isn't the thing it does currently
13:16 imirkin: oh ok
13:17 karolherbst: I think you can tell nir to split fma
13:17 karolherbst: lower_fma = true?
13:17 karolherbst: lower_ffma :)
13:17 robclark: maybe.. but like I said I still want mad when it isn't really fma
13:17 karolherbst: ohh
13:17 robclark: so probably have to teach nir about separate mad vs fma or something like that.. but it's *really* low on my priority list ;-)
13:17 karolherbst: mhh
13:18 karolherbst: no idea what nir should do if it enconters a fma in that case
13:18 karolherbst: because it would just do fma -> mad, no?
13:30 kisak: robclark: congrats on GLES 3.1
13:31 robclark: thx
13:33 kisak: I think mesamatrix.net didn't parse the two freedreno entries at https://gitlab.freedesktop.org/mesa/mesa/commit/6764aae169e5d318782292bed4fd0a689cb5fd3a#835e13c1d5068caa0da837d6f4ba70e697ad6afd_67_66 as expected. Since the older generations are explicity mentioned in the note, maybe "freedreno/a5xx (*)," would be easier for MightyCreak's parser
13:35 kisak: wow that's an ugly link ... as long as it works
13:40 robclark: hmm, doh..
13:42 robclark: actually, does that even show up on the page? I couldn't find it so I assumed the parser ignored that line
13:44 kisak: I didn't think of that, the parser might not combine multiple notes
13:47 karolherbst: robclark: geometry shader next?
13:47 robclark: well, maybe a6xx next.. we'll see..
13:47 karolherbst: ohh, right
13:48 karolherbst: well geometry shaders would give you GL 3.3 as well ;)
13:48 karolherbst: but maybe the OES version is much smaller?
13:48 robclark: geom shaders will involve a fun nir pass..
13:49 karolherbst: why?
13:49 robclark: because of the unique way the hw works ;-)
13:49 karolherbst: ahh
13:49 karolherbst: already sounds painful
13:50 robclark: imirkin did a write-up one it.. https://github.com/freedreno/freedreno/wiki/A4xx-Geometry-Shaders
13:51 karolherbst: uhhhh
14:26 daniels: +b
14:27 imirkin_: robclark: tess should be a lot easier than geom - it's a pretty direct mapping
14:28 robclark: ok, that's reassuring..
14:29 imirkin_: you'll have to track down a small handful of things, but I re'd majority of it on a4xx at least. should probably see about getting my a5xx setup up to par.
14:29 imirkin_: iirc i did do some of it on a5xx too? i forget.
14:29 imirkin_: did i write up my findings?
14:29 imirkin_: https://github.com/freedreno/freedreno/wiki/A4xx-Tessellation-Shaders
14:29 imirkin_: good job, former me.
14:30 robclark: heheh
14:31 imirkin_: i did have some questions about precisely how the whole patch buffer thing is meant to be sized
14:32 imirkin_: for each patch, you compute tess factors, which have to be fed to the hardware via a special buffer. but there's lots of patches, and presumably finite buffer size, so ... yeah, dunno how that's managed exactly.
14:32 robclark: hmm, if tess output is to gmem, presumably we need to reserve some memory for that when calculate_tiles()?
14:33 imirkin_: it's a totally separate buffer
14:33 robclark: hmm
14:33 imirkin_: PC_TESSFACTOR_ADDR
14:33 imirkin_: you do write to it via gmem, but then the hw consumes it to feed inputs into the tessellator
14:33 imirkin_: [i'd recommend reading up on tessellation before doing too much on the RE end of things...]
14:33 robclark: oh, so in system memory
14:34 imirkin_: right. sorry. global memory. not tile memory.
14:34 imirkin_: ("g"mem meaning "graphics" memory? annoying.)
14:35 robclark: I guess nv and adreno use the same word to mean two completely opposite things :-P
14:35 imirkin_: yeah =/
14:35 karolherbst: well g for global is the most obvious use of g :p
14:35 imirkin_: i think "galapagos" would be pretty obvious too...
14:36 robclark: heheh
14:38 imirkin_: robclark: it looks like i did a half-decent job of describing how tess works in the overview section there, so that'd be a good start
14:42 imirkin_: robclark: no more half-precision blits? :(
14:42 robclark: well, that only effects blits that fall back to u_blitter in the first place..
14:43 robclark: but it was breaking some deqp's..
14:43 robclark: (hmm, I probably meant for that to be a separate patch)
15:19 imirkin_: robclark: btw, in GL, you can have a MSAA buffer but multisample disabled
15:20 imirkin_: i suspect some of your msaa logic would need adjustment to handle this
15:20 imirkin_: it's not a condition that can happen in GLES though
15:40 Prf_Jakob: imirkin_, robclark: Which is a bit of a annoyance because the only way to enable MSAA on GLES is to enable the full desktop extension.
17:26 ayaka: I found flags |= DRM_MODE_PAGE_FLIP_EVENT | DRM_MODE_ATOMIC_NONBLOCK; doesn't work as I want
17:27 ayaka: I want to push a number of drm atomic req let the driver decide whether a request should be displayed or dropped
17:28 ayaka: but I found the drmHandleEvent won't report those request are dropped and it drop too many frame some times
17:29 ayaka: even making the screen stretched
17:30 ayaka: so with the page flip I should wait I got the event of the previous frame then commit a new one?
18:01 jekstrand: daniels: How is that a promise? Doesn't "promise" imply that you'll follow through.
18:01 jekstrand: danvet: ^^
18:01 jekstrand: danvet: How about "dma_fence_maybe"
18:02 jekstrand:wishes he didn't have to type a whole four letters before the tab. :P
18:45 danvet: jekstrand, maybe I'm just too much a burned child with "promises" :-)
18:45 danvet: not sure about _maybe
18:45 danvet: that makes me think of the Haskell Maybe type
18:45 danvet: which is essentially Object or Null
18:46 danvet: maybe doesn't encapsulate that it's likely to show up in the future imo
18:46 danvet: Maybe a = Just a | Nothing
18:47 Kayden: *shrug*, that's just "maybe we have an object", a special case of "maybe we'll do this, maybe we won't"
18:59 danvet: Kayden, I just like to both have the uncertain nature and the forward looking part in the name, if possible
19:38 anholt: danvet: with ba1f665f161ce112a2703649317bfdc9b6521613, we now need mode_config.funcs initialized before connector initialization. was that intentional?
19:38 anholt: vc4 was doing mode_config after the components bound, and I'm concerned about trying to reshuffle things for that commit.
19:39 danvet: hm it only checks whether the functions are there if you're atomic
19:39 danvet: if you init mode_config.funcs later I expected it all to be silent
19:39 danvet: it's not?
19:39 anholt: the atomic check looks at mode_config->funcs.atomic_commit
19:39 danvet: yeah
19:40 danvet: but if you're not atomic at that moment then the WARN_ON shouldn't ever fire
19:40 anholt: sorry, funcs->atomic_commit. and funcs is NULL
19:41 danvet: oh crap
19:41 anholt: could we check DRIVER_ATOMIC instead?
19:41 danvet: tended to not match historically
19:41 danvet: DRIVER_ATOMIC is about the uapi
19:41 anholt: ok
19:41 danvet: the other one is about the internal implementation
19:42 danvet: but yeah I totally didn't check that this can go boom :-/
19:44 danvet: atmel has the same issue
19:44 anholt: it's been a rough week for my rpi setup. kernel started oopsing, my serial cable needed resoldering and the system wouldn't boot with it connected, and my network adapter keeps wedging. I was pretty sure I'd just fried my power adapter or something.
19:50 danvet: same for msm I think
19:51 danvet: and omapdrm for sure
19:51 danvet: anholt, pls push the revert (with or without going through the mailing list to appease dim)
19:51 danvet: bit late here for me, past the point where I should push to trees :-)
19:52 danvet: but yeah sending out the revert Cc: haneen with explanation for what's going boom would be good
19:52 danvet: a-b: danvet either way
19:52 danvet: and sorry for the mess
19:53 danvet:gave up auditing git grep output after around radeon
19:53 danvet: geez do we have many drm drivers nowadays
19:54 anholt: danvet: I've got a quick fix
19:55 danvet: anholt, ah yes that should work
19:55 danvet: r-b: me
19:55 danvet: for whatever that's worth at this time of the day
19:56 danvet:going back to watching the tomato quiche bake
20:31 anholt:wishes dim's link tag would still be added when conflicts had to be resolved
20:32 danvet: anholt, dim add-link
20:32 danvet: and I thought I've fixed these, or at least once attempted
20:33 anholt: actually, this patch was sent directly to me, so I don't even have a link to add. sigh.
20:33 airlied: danvet: so the gpg spew in merges, are ppl wanting that in or out?
20:33 danvet: dim -f push
20:33 danvet: for the exceptions
20:33 anholt: ah, that's ok?
20:33 anholt: (it's a trivial vm_fault_t conversion)
20:33 danvet: occasionally
20:34 danvet: abuse of power is part of the thrill
20:34 danvet: airlied, no idea, I think it's just what git merge does by default
20:34 airlied: ah it seems to be # commented but gets left in
20:34 danvet: might need to so some key signing next xdc
20:34 danvet: airlied, yeah sometimes git does that, I haven't figured that out
20:35 airlied: cool I can just nuke it by hand anyways
20:35 danvet: anholt, if you want to fix the missing Link: tag, I did some hacks for pull requests
20:35 danvet: grep MERGE_MSG dim
20:35 danvet: I think something similar should work for apply
21:23 kallisti5: eeeeeeeee
21:23 kallisti5: so.. I was using stContext->state.framebuffer to flush a bitmap image to the screen
21:23 kallisti5: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/targets/haiku-softpipe/GalliumContext.cpp#n353
21:24 kallisti5: looks like stContext->state.framebuffer is now gone?
21:27 kallisti5: I catch it here: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/sw/hgl/hgl_sw_winsys.c#n194
21:40 jstultz: seanpaul: so.. I'm trying to understand the current Validate/Present paths better, and both reuse the CreateComposition() logic to do the Layer ordering/Import/Plan, only differing if we then call test or apply. But I'm curious why we don't save the composition we successfully test and just later apply that in Present rather then re-creating a new composition both times?
21:42 jstultz: seanpaul: https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/blob/master/drmhwctwo.cpp#L520 specifically
21:51 opendata: jstultz: what gralloc impls are supported with drm_hecomposer
21:52 jstultz: opendata: seen it work with gbm_gralloc and the hikey grallocs (based on arm reference gralloc for utgard and bifrost)
21:54 opendata: Hmm,ok
22:24 jstultz: opendata: is there a specific one your using?
22:28 tango_: 28
22:28 tango_: ergh
22:57 Kayden: anholt: I'm surprised you only saw a 2k decrease in text size from fixing the valgrind __gen_validate_value issue
22:57 Kayden: it was 36% in anv, and pretty huge in iris as well
22:57 Kayden: made __gen_uint a function call
22:58 anholt: oh, wow. my packing hasn't had any function calls in it.
22:58 anholt: all of my twiddling of packing for vc4_emit.c was only changing things by ~10%
22:58 Kayden: yeah...the code for 3DSTATE_SBE_SWIZ was massive
22:58 Kayden: without it, it was basically gone
22:59 Kayden: and I mean, emit_cmd(3DSTATE_SBE) { }
22:59 Kayden: just zeroing it
22:59 anholt: wow
22:59 anholt: Kayden: btw, did you see my question about 565 being needed in the cts?
23:01 Kayden: http://whitecape.org/paste/vg.txt (search for 3DSTATE_SBE_SWIZ, be suitably impressed... novg.txt has the other version)
23:01 Kayden: hm, no, I didn't
23:01 Kayden: 565 is required when building the CTS to use the Android winsys IIRC
23:02 Kayden: it shouldn't be required on X
23:02 Kayden: I remember there was some CTS change that made it start happening, and everything was broken, and I bisected it to a deqp framework change, and...I think we decided it was broken, but...
23:02 Kayden: I don't remember what actually changed in the end :/
23:03 anholt: there was a comment from you back in february noticing the same thing -- cts not starting with that error.
23:07 Kayden: hm, yes,
23:07 Kayden: https://people.freedesktop.org/~cbrill/dri-log/?channel=intel-3d&date=2018-02-15
23:07 Kayden: https://people.freedesktop.org/~cbrill/dri-log/?channel=intel-3d&date=2018-02-16
23:10 Kayden:tries to compile the CTS
23:13 Kayden: I wonder if I just haven't run the newer ES CTS since then
23:14 Kayden: the change I was suggesting was to edit glcAospMustpassEs.hpp and wrap the rgb565d0s0ms0 visuals in #if DE_OS == DE_OS_ANDROID ... #endif
23:14 anholt: thanks for the pointer there. that'll help.
23:14 Kayden: Yeah, it's still broken today.
23:15 Kayden: Looks like cts-runner --type=es31 requires it, but --type=gl45 doesn't
23:16 Kayden: sorry for not tracking that down :(
23:26 mareko: I'm considering switching piglit to concurrency by default, because single-threaded piglit is mostly useless
23:26 Kayden: oh, -c by default?
23:26 mareko: yes
23:26 Kayden: it isn't already?
23:27 Kayden: it definitely should be
23:27 mareko: not for deqp
23:38 siqueira: Hi. I'm trying to simulate vblank by using hrtimer. To do it, I implemented enable/disable_vblank and setup hrtimer in the enable_vblank. Additionally, I added the function to be invoked by hrtimer at the end of each period. However, I continuously get errors related to drm_atomic_helper_commit_hw_done and drm_atomic_helper_wait_for_vblanks. I added drm_crtc_handle_vblank, but I still get the same problem. I believe that I missed something
23:38 siqueira: required in the vblank process. Follows my patch and the log:
23:38 siqueira: patch: https://paste.fedoraproject.org/paste/xtSLd7CGEZ51kvzKC9HoNw
23:38 siqueira: error log: https://paste.fedoraproject.org/paste/~e-hZ61N35j20Cd9lUP2SQ