07:35pmoreau: karolherbst: Yes sorry, I thought I would have had time under the weekend to look at it, but sadly did not. Having a 4-day weekend this week, so definitely looking into it.
08:36pmoreau: karolherbst: I just had a quick look at it and left some comments, mostly about the style.
08:36pmoreau: Still some parts where I need to have a closer look at the overall code, but for now I need to work so I’ll do that later.
09:17karolherbst: pmoreau: that's fine
09:19karolherbst: thanks for the feedback
16:34karolherbst: imirkin: mind checking/thinking about if this patch could break video decoding on nv30? https://github.com/karolherbst/mesa/commit/2fab1dea3d096a43efe2bede0d9acbc5d7ad50af
16:34karolherbst: no idea why I say video decoding
16:34karolherbst: I only see NOUVEAU_BUFFER_STATUS_USER_MEMORY used in nv30_vbo.c
16:34imirkin: i don't have a nv3x/4x plugged in
16:35imirkin: in various cases we store resource data in user memory
16:35imirkin: coz it doesn't need to be bo-backed
16:35karolherbst: but we also attach fences to it as it seems_
16:35karolherbst: I had to change nouveau_buffer_destroy
16:35imirkin: not to user objects... dunno
16:35karolherbst: but not quite sure why again
16:36karolherbst: but I moved the nouveau_fence_ref calls
16:36karolherbst: but I also throw in bunch of asserts to assert .. I think I need to think about this more carefully as well
16:38karolherbst: and maybe I should use nouveau_user_buffer_create as well? mhh
16:38imirkin: you want bo's backed by user memory
16:38imirkin: which is different
16:43karolherbst: wondering if we should treat those as different things alltogether actually
16:44imirkin: diff things altogether imo
22:54dllu_: I have an OpenGL 2.1 program that works perfectly on linux amdgpu mesa, linux nvidia 440, windows nvidia 445, macOS catalina with intel gpu, and even ubuntu guest in vmware on macOS, but it doesn't display correctly in nouveau
22:55dllu_: here is a screenshot on amdgpu where it displays correctly: https://pics.dllu.net/file/dllu-sc/rZ88sPewWJp5QQYE.png
22:55dllu_: on nouveau (as an example; it's a different frame): https://pics.dllu.net/file/dllu-sc/q43K_2a_tAZlSGZZ.png as you can see, the purple points in the middle are gone
22:55dllu_: here's the apitrace: https://lawrence.lu/public/simple_viz.trace (92 MB)
22:56dllu_: the points that are missing were supposed to be drawn with these calls: https://pics.dllu.net/file/dllu-sc/Jx4_ENnb9GZnpja3.png
22:57dllu_: the gpu is a GTX 750 Ti with mesa 18.0.5
22:58dllu_: on ubuntu 16.04
22:59dllu_: glxinfo: https://www.dllu.net/public/glxinfo.txt
22:59karolherbst: ohh, interesting
22:59karolherbst: I can actually reproduce this on gp107
23:01karolherbst: and with mesa master
23:01karolherbst: maybe imirkin has some ideas though
23:03karolherbst: dllu_: mind filing a proper bug against mesa for this?
23:03karolherbst: just so that it doesn't get lost
23:13imirkin: dllu_: obviously no ideas off the top of my head, but i'll take a look
23:15imirkin: looksl ike frame 4 in the trace is the first frame that's supposed to have the purple stuff in the middle?
23:15imirkin: and it appears to come from a draw of 65536 points?
23:16imirkin: call #11166
23:17karolherbst: imirkin: could be some texture flushing issue
23:18imirkin: dllu_: pretty sure your shader is bad
23:18imirkin: dllu_: you have GL_PROGRAM_POINT_SIZE = GL_TRUE
23:18imirkin: dllu_: however the vertex shader doesn't write gl_PointSize that i can see
23:21dllu_: oh good point
23:21dllu_: I made the mistake of glEnable(GL_PROGRAM_POINT_SIZE) but then I set the point size via glPointSize
23:24imirkin: from the GL 4.6 spec: https://hastebin.com/pegofoxeha.coffeescript
23:25imirkin: the GL 2.1 spec didn't mention that it was undefined explicitly
23:26dllu_: yeah probably around 100% of openGL programs in existence have some sort of undefined behaviour
23:27dllu_: I'll remove the glEnable(GL_PROGRAM_POINT_SIZE) line and let my friend with the nouveau computer test it
23:27imirkin: sounds like some drivers ar enicer about this
23:27imirkin: if you generate an apitrace trace without it, happy to check it out too
23:38dllu_: oh it works!!!!!!!
23:38imirkin: sometimes the bug isn't in nouveau :)
23:38dllu_: yeah but everyone else seems to be nicer about it :)
23:47karolherbst: dllu_: see it as a service, we point out bugs in applications :p
23:48karolherbst: but actually wondering what other drivers do
23:48karolherbst: or if the hw just defaults to something there
23:48dllu_: I bet other drivers just default to the global point size because changing the point size globally via `glPointSize` seems to work
23:48imirkin: well, it's whatever the hw does
23:49imirkin: one could detect that the last vertex stage never outputs a gl_PointSize and auto-flip that off
23:49imirkin: but that seems dodgy, imo
23:49imirkin: of course dodgy is nvidia blob driver's middle name, so ... makes sense they'd do it
23:50imirkin: and in other hw, it might just work out "for free"
23:50imirkin: alternatively you could insert a gl_PointSize = driver uniform which is the current point size into any vertex stage program
23:51imirkin: but that also seems wasteful
23:51karolherbst: imirkin: or just insert in the shader and dce it once it gets overwritten :p
23:52karolherbst: it's a normal vertex output, isn't it?
23:53imirkin: but what if it's never used with points in the first place?
23:53imirkin: wasted shader export.
23:57karolherbst: mhhhh... true