00:34 bl4ckb0ne: why is `piglit_display` executed twice?
00:34 imirkin: it's run once for each time the window is redrawn
00:34 imirkin: that's the diff between piglit_init which runs once
00:34 imirkin: and piglit_display which is run on redraw
00:35 imirkin: some piglits offer interactive options too
00:35 imirkin: none of this matters in "auto" mode of course
00:35 bl4ckb0ne: so it's my WM's fault if its ran twice and one of them fails?
00:36 imirkin: no, it's your fault for making the piglit_display function fail when it's run a second time
00:36 bl4ckb0ne: should I fix it to run the second time?
00:36 imirkin: you should fix it so that it is able to run any number of times
00:36 bl4ckb0ne: i think im having rounding issues with piglit_width divisions
00:37 imirkin: what are you doing?
00:37 bl4ckb0ne: testing my instancing extension
00:37 imirkin: if you're interested in assistance, pastebin the piglit, i can take a look
00:37 bl4ckb0ne: im using `piglit_prob_rect_rgba` to validate the screen
00:38 bl4ckb0ne: i know why, when the windows is resized, the squares are at the bottom left of the screen instead of the top left
00:38 imirkin: perhaps you're using the piglit_width/height in the piglit_init?
00:39 bl4ckb0ne: its in piglit_display
00:40 bl4ckb0ne: nothing a little googling cant fix
00:44 bl4ckb0ne: might be a missing transform for rotation
00:47 bl4ckb0ne: oh there's not rotate function in piglit-matrix.c
00:57 bl4ckb0ne: could I hardcode the rotate matrix in the shader?
01:20 bl4ckb0ne: imirkin: https://paste.sr.ht/%7Ebl4ckb0ne/b4b9e3a53c97a5b2cb144505c447bf8e5816381e could I have some help please?
01:21 imirkin: lesseee here
01:21 bl4ckb0ne: i cant rotate properly so my square is at the top right
01:21 bl4ckb0ne: i can also link you my mesa PR if needed
01:23 imirkin: nah
01:24 imirkin: so
01:24 imirkin: oh i see.
01:25 imirkin: so
01:25 imirkin: those offsets seem off
01:25 imirkin: the NDC space is (-1,1) on each axis
01:26 imirkin: should it be (vertex + pos) / 2 ?
01:27 bl4ckb0ne: could I divide vec2?
01:27 imirkin: sure
01:29 bl4ckb0ne: getting glsl errors
01:30 imirkin: what's the error?
01:30 bl4ckb0ne: > error: could not implicitly convert operands to arithmetic operator
01:30 bl4ckb0ne: > error: cannot construct `vec2' from a non-numeric data type
01:31 imirkin: what's the shader look like now?
01:34 bl4ckb0ne: https://paste.sr.ht/%7Ebl4ckb0ne/8fdc03e8ae68e09f573e44e6df8f9a08d9fdec03
01:35 imirkin: maybe 2.0?
01:35 imirkin: ES doesn't have any implicit conversion
01:35 imirkin: so i think it's picky about stuff like that
01:35 bl4ckb0ne: it works, but the square is still at the bottom right
01:37 imirkin: so ... my main recommendation would be to not write your own piglit, but instead to reuse shader_runner. you don't get the piglit_rotation stuff, but ... it's not that hard to do by hand for a 180 rotation
01:37 bl4ckb0ne: i think my rotate matrix is wrong
01:37 imirkin: you're not doing anything too complex, so it's fairly practical.
01:38 bl4ckb0ne: it seems im the only one using that function
01:52 imirkin: oh, i know which piglit you're trying to make work
01:52 imirkin: the one that rotates each successive instance a bit
01:53 bl4ckb0ne: i copied the one from arb_draw_instanced
01:53 bl4ckb0ne: and ported it from gl1 to gles2
01:53 imirkin: why not just make that one work for both?
01:54 bl4ckb0ne: i had issues porting the glFrustum etc to modern gl
01:54 bl4ckb0ne: plus i had to rewrite a major part of the shader
01:55 imirkin: ah, right
01:56 bl4ckb0ne: also a large part of the gl1 func are not present in gles2, like the rasterpos
01:56 imirkin: neither of those tests does rotation though
01:56 bl4ckb0ne: yeah
01:56 bl4ckb0ne: i also kinda wrote a different test to avoid messing with the modelviewprojection matrix
01:57 bl4ckb0ne: well there's a translate
01:57 imirkin: a shader_test would avoid all these problems tbh
01:57 bl4ckb0ne: a scale, and a frustum
01:57 bl4ckb0ne: i think i have a few shader tests
01:58 bl4ckb0ne: its the tests that goes in the "compiler" folder?
01:58 imirkin: anyways, good luck. i have a ton of NV_viewport_array2 tests to write.
01:58 bl4ckb0ne: and just checks if the shadercompiles
01:58 bl4ckb0ne: thanks for your help, and good luck with those tests
01:59 imirkin: you can do all the rendering in the shader_test
01:59 bl4ckb0ne: interessting
01:59 bl4ckb0ne: ill look into that
01:59 bl4ckb0ne: but i like that crappy test for learning opengl
06:15 sravn: pinchartl: Sorry, but no review feedback on "drm: bridge: adv7511: Implement bridge connector operations". I did not understand the changes well enough to provide any useful feedback
11:20 pinchartl: sravn: no worries. maybe that means I need to explain them better ? :-)
11:52 karolherbst: heh.. I know something you will love
11:52 karolherbst: 5.6.3
11:52 karolherbst: [ 625.367668] drm drm: swiotlb addr 0x0000000176000000+4096 overflow (mask ffffffff, bus limit 0).
11:53 karolherbst: https://gist.githubusercontent.com/karolherbst/ab31b41d600d20dc00ffa8b38d6281ab/raw/3a1395155a8119a04286683f678fc787e6dee615/gistfile1.txt
11:58 sravn: pinchartl: It is the other ~2500 loc and the infrastructure is uses that is the challenge. Actually is is just how the hotplug notify is supposed to work. I hope someone that knows this will take a look. As for the call to get_modes(), it looks redundant to me..
12:01 sravn: pinchartl: Lookign at tc358764 - how can I see what drm_bridge_funcs needs to be implmented to support DRM_BRIDGE_ATTACH_NO_CONNECTOR?
12:01 sravn: pinchartl: I took a look at this driver, as it is sometimes easier to get the full picture when you try out a little coding on your own
12:05 pinchartl: sravn: you need to implement .get_modes() or .get_edid() if the bridge supports retrieving modes, .detect() if it supports detection of the connection status, and .hpd_enable() and .hpd_disable() if it supports HPD notifications without polling (through interrupts) and the HPD notifications can be enabled or disabled on demand
12:05 pinchartl: as for .get_modes(), why do you think it is redundant ?
12:08 sravn: pinchartl: get_modes() - because I could not see what it had to do with the detect functionality
12:10 pinchartl: ah yes sorry
12:10 pinchartl:needs to wake up :-)
12:10 pinchartl: HPD in adv7511 seems very fragile
12:12 sravn: pinchartl: for tc358764 - then in other words I need to implment the functionality as part of drm_bridge_funcs that is today implmented as part of drm_connector_funcs
12:13 sravn: If this is correct then it is doable as drm_connector_helper_funcs only implments get_modes - that just forwards it to the panel
12:14 sravn: pinchartl: Needs to go, garden work calling...
12:14 pinchartl: it's nearly correct :-)
12:14 pinchartl: you should only implement the drm_connector_funcs that are natively implemented today
12:14 pinchartl: anything that is delegated to another bridge shouldn't be implement
12:15 pinchartl: for instance, don't implement operations that will just be delegated to the panl
12:15 pinchartl: instead, wrap the panel in a bridge, and let the drm bridge connector helper handle it for you
12:16 pinchartl: so no .get_modes()
12:16 pinchartl: looking at the driver, I think you don't need to implement any extra operation
12:16 pinchartl: you only need to convert it to using the drm_panel_bridge
12:17 pinchartl: and in .attach(), if DRM_BRIDGE_ATTACH_NO_CONNECTOR is set, just propagate attach to the panel, and you're done
12:19 pinchartl: in tc358764_detach(), ctx->panel = NULL; seems wrong, I think that line should be dropped
12:19 pinchartl: you also won't need to call drm_panel_detach() anymore I think
12:20 pinchartl: and I wonder if drm_connector_unregister() and drm_connector_put() are needed
14:32 jvesely: daniels: do you need someone to push the libclc patches?
14:32 daniels: jvesely: yes please, but not yet the spirv target
14:34 jvesely: ok, I'll push those other 4 later today.
15:03 daniels: thankyou!
15:54 feaneron: greetings
15:54 feaneron: what's the relation between virglrenderer and the virgl driver for mesa?
15:55 imirkin: virgl is a driver for the fake hw presented by qemu
15:55 imirkin: virglrendered is software used by qemu to help create the fake hw
15:55 imirkin: virglrenderer*
15:56 feaneron: so a guest system would need both virgl (from mesa) and virglrenderer in order to have proper 3d acceleration?
15:56 imirkin: a guest system would only need virgl
15:57 imirkin: a host would need qemu and virglrenderer
15:57 feaneron: got it
15:57 feaneron: thanks
16:51 vivijim: airlied: danvet: could you please put drm-fixes on -rc1?
16:51 vivijim: $dim rebase drm-intel-fixes v5.7-rc1
16:51 vivijim: dim: Upstream v5.7-rc1 not merged into drm-tip, aborting
16:53 danvet: vivijim, rebuilding right now
17:04 vivijim: thanks
17:21 danvet: ofc linus needs to smash MAINTAINERS through sort again
17:30 danvet: ickle, some of your patches in topic/core-for-CI probably need a rebase
17:31 danvet: airlied, mripard, drm-misc-next vs -rc1 is fun in MAINTAINERS
17:31 danvet: I stuffed something into drm-tip, but needs double-checking
17:31 danvet: might be good to do a first pull and bake that in before we forget
17:31 danvet: maybe after sfr screamed at it
17:40 mareko: jekstrand: hi, any opinion on on the MR making src/compiler not include src/mesa?
18:23 ManDay: Just to check that I don't tell nonsense there, can anyone confirm that this is properly described? https://bugs.gentoo.org/717352
18:36 sravn: pinchartl: I have something for tc58764 now. I ended up with 6 patches.. Will post tomorrow after I have looked at them with fresh eyes
18:59 jekstrand: mareko: Sorry, I haven't gotten around to looking at it yet. It's on my list though
19:03 airlied: danvet: ouch, thanks for taking that, it was on my list today :-P
19:33 pinchartl: sravn: fresh eyes are a good idea
22:29 Lyude: vivijim: poke, just noticed that it looks like 67eee7887e49ff47d0ccbfea7e4c33b26a50c3b2 ("Merge remote-tracking branch 'drm-intel/topic/core-for-CI' into drm-tip") appears to have broken kernel builds for me on drm-tip/drm-tip ( https://paste.centos.org/view/0bee34b9 )
22:29 Lyude: looks like it was the actual merge commit that broke it btw
22:37 emersion: vsyrjala: any thoughts on this? https://lists.freedesktop.org/archives/dri-devel/2020-April/261055.html
23:20 airlied: bleh cts goes fine, then you run the GTF tests
23:21 imirkin: nouveau actually did pretty well with GTF
23:22 airlied: yeah I'ev only got 12 more fails, but I feeling so close :-P
23:22 imirkin: oh yeah, 12 is probably not so bad
23:22 imirkin: in my case they were pretty legit things
23:22 imirkin: still, you can probably taste conformance... :)
23:22 vivijim: airlied: Lyude was also complaining about the rtc broken compilation as mdnavare.... it ends up that we have on topic/core-for-CI a Kconfig select +BROKEN so it might break depending on how people generate the .config
23:23 vivijim: make allyesconfig for instance is really broken on drm-tip because of this patch
23:24 airlied: vivijim: nah it's the from ci fixup
23:25 vivijim: hmmm...