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