00:35 robclark: karolherbst, hmm, glsl420, perhaps not, but I can force override glsl version and try..
00:35 karolherbst: :)
00:35 karolherbst: I just want to know if you also hit an assert
00:35 robclark: any specific piglit?
00:36 karolherbst: shader_runner: ../src/mesa/state_tracker/st_atom_array.c:595: setup_non_interleaved_attribs: Assertion `array' failed.
00:36 karolherbst: 'spec@glsl-4.20@execution@vs_in@vs-input-byte_int-double_dmat2x3-position'
00:36 karolherbst: uhmm
00:36 karolherbst: 'piglit/bin/shader_runner /home/kherbst/git/piglit/generated_tests/spec/glsl-4.20/execution/vs_in/vs-input-byte_int-double_dmat2x3-position.shader_test -auto -fbo'
00:36 karolherbst: mhh
00:36 karolherbst: needs path adjustments ;)
00:36 robclark:can handle that :-P
00:36 robclark: one min.. just got in.. need to plug in and power up..
00:37 robclark: (fwiw, I guess you should also be able to compare nir dumps to i965)
00:37 karolherbst: well
00:37 karolherbst: on i965 things usually just work
00:37 robclark: (hmm, well not mesa/st.. but at least compare the nir)
00:37 karolherbst: but...
00:37 karolherbst: right
00:37 karolherbst: mesa/st is the problem here
00:37 karolherbst: there are some passes ran as well
00:37 karolherbst: and differentt things
00:38 karolherbst: I hoped that other drivers got so far already...
00:41 robclark: karolherbst, yeah, main issue is freedreno isn't such a high gl level yet.. (although radeon is..)
00:41 karolherbst: yeah
00:42 karolherbst: but I think when the first NIR support for radeon landed, they hadn't geometry shaders supported back then as well?
00:42 karolherbst: and I doubt they cover all now anyway
00:42 karolherbst: maybe they do...
00:43 robclark: hmm.. https://hastebin.com/raw/uyaquvebug
00:43 karolherbst: I know that tesselation shaders also hit some weird asset
00:43 karolherbst: *assert
00:43 robclark:doesn't have geom/tess yet, fwiw
00:43 karolherbst: well
00:43 karolherbst: sounds like the same assert to me :)
00:44 karolherbst: I hope I can get compute shaders working without running into such issues :/
00:44 robclark: fwiw, I *do* have compute shaders already
00:45 karolherbst: mh, weird. I would assume somebody would implement geometry first and then tesselation and then compute as the last one ;)
00:45 karolherbst: but this gives me hope
00:45 robclark: well, compute came first for gles
00:45 karolherbst: ahhhh
00:46 karolherbst: this makes sense
00:46 karolherbst: still weird
00:46 robclark: (plus, there are folks interested in compute on freedreno.. and not a lot of open src games that use geom/tess.. and no steam store for arm linux yet :-P)
00:46 karolherbst: I mean, from an OpenGL point of view
00:47 robclark: one sec, I'll look at where it is complaining in a few
00:47 robclark: (but I think you can ignore gs/tcs/tes issues for now if you mainly want compute.. if piglit doesn't have enough compute tests there is deqp)
00:47 karolherbst: well there are some compute tests
00:47 karolherbst: quite a lot
00:47 karolherbst: but they just test all the built-ins mainly
00:48 karolherbst: thing is, compute needs images and ssbos
00:48 karolherbst: or the tests do
00:49 robclark: there are *some* compute tests that work with just SSBOs in deqp.. that is where I started..
00:49 karolherbst: but geomtry seems to work fine for some parts
00:49 robclark: (and then moved on to images/atomics
00:49 robclark: and barriers)
00:49 karolherbst: right
00:49 karolherbst: but I have the advantage, that we already got that covered in nouveau
00:49 robclark: so issue is, mesaAttr == ST_DOUBLE_ATTRIB_PLACEHOLDER
00:50 robclark: maybe we need double lowering
00:50 karolherbst: mhh
00:50 karolherbst: you mean the assert or the ' no 64-bit float support' message?
00:51 robclark: well, that results in the assert..
00:51 karolherbst: ahh, okay
00:51 robclark: since it makes get_client_array() return NULL
00:51 robclark: so I think that code isn't expecting to encounter doubles..
00:51 karolherbst: mhh
00:51 karolherbst: maybe after I am done with compute stuff, I get to that as well
00:52 karolherbst: there is also som weird tesselation assert, but I think just a case in a switch is missing
00:52 robclark:needs to remember option to dump nir in mesa/st (rather than after it gets to driver)
00:52 karolherbst: I was just mainly wondering if I am wrong or gallium/nir
00:53 robclark: might also be worth asking tacari..
00:53 robclark: err, taceri .. something like that
00:54 robclark: anyways, probably lowering pass that needs to be called.. I haven't really tried doubles at all yet so another thing that I haven't encountered yet
00:54 karolherbst: mhh
00:54 karolherbst: well, I already got doubles working
00:54 robclark: just not as vs in :-P
00:54 karolherbst: well
00:55 karolherbst: I had fun with doubles as fp ins :)
00:56 robclark: anyways, I'm not 100% sure how that is *supposed* to work.. timothy arceri might have an idea.. either way, probably makes more sense to work on the missing bits for compute since that side steps these issues for now
00:57 karolherbst: mhh
00:57 karolherbst: well, for me that doesn't make a difference, double inputs
00:57 karolherbst: just gets treated as 2 floats
00:58 karolherbst: for the input/slot logic that is
00:58 robclark: (hmm, well it seems tarceri is at least still on #dri-devel.. not sure if he is actually around)
00:58 karolherbst: well, starting tomorrow I guess nobody will be around much anyway
00:58 robclark: yeah
00:59 robclark: anyways, I doubt it is something in nouveau nir, as much as mesa/st not calling some lowering pass
00:59 karolherbst: yeah, most likely
01:00 karolherbst: well, ssbos sounds like fun
01:02 karolherbst: oh well, this sounds easy enough, becuase codegen lowers everything away...
01:02 karolherbst: just like with textures
01:03 robclark: from nir->ir3 standpoint, ssbo's and images weren't really that hard.. only moderate complexity for me was that image reads are actually txf's
01:04 karolherbst: we still don't support 3d images with kepler on nouveau :(
01:06 robclark: for ir3.. for images, I have to calculate the byte offset.. so 2d vs 3d is just another += (zpitch * z)
01:07 karolherbst: mhhh
01:07 robclark: (which is a bit annoying that I need to inject extra uniforms to pass the stride/layer_stride stuff, etc)
01:07 karolherbst: I tried to look into that, but I hadn't much time for that back then and it still was a bit complex
01:08 karolherbst: right
01:08 robclark: anyways, ignoring crazy hw, at least the *nir* side of SSBOs and images wasn't hard
01:09 karolherbst: well nvidia uses shaders like this for "trivial" image operations: https://gist.github.com/karolherbst/d8a3e38d2a6d5ccd200486a71dd620da
01:09 karolherbst: su* are the surface operations
01:10 robclark: what is the TGSI (or GLSL) that maps too?
01:10 karolherbst: don't have it, but it was a fairly trivial glsl shader
01:10 karolherbst: it is a CTS test
01:11 karolherbst: image load store I think
01:11 karolherbst: it basically stores an image and reads it back :)
01:11 robclark: I mean, is the if/else stuff part of lowering the load/store image intrinsic?
01:11 karolherbst: I think the TGSI is like 10 instructions top and no CFG
01:11 karolherbst: exactly
01:12 karolherbst: the TGSI is bascially: some movs, image save, image load, export
01:12 robclark: ok.. that is bizarre.. since image read should be basically same thing as texelFetch
01:12 karolherbst: ;)
01:12 karolherbst: well maybe we could use texelfetch as well
01:12 karolherbst: but I think our plan was to stick what nvidia does
01:13 karolherbst: and I think we don't even do that else branch from that
01:13 robclark: texelfetch does make munging gl state uglier.. but easier I guess for the shader
01:14 robclark: I guess the if/else stuff is to do w/ clamping image coords?
01:14 karolherbst: might be
01:14 karolherbst: anyway, each of those outer if/else things is one TGSI image operation
01:14 robclark: what does stuff like "c2[0x43]" mean?
01:14 karolherbst: might be two
01:14 karolherbst: no idea
01:14 karolherbst: well
01:14 karolherbst: c2 is the second const buff
01:14 karolherbst: and nvidia puts stuff inside it :)
01:14 robclark: k
01:14 robclark: right, ok, I guess passing image params
01:14 karolherbst: g[ is global memory
01:15 karolherbst: yeah
01:15 karolherbst: c0 is input usually
01:15 karolherbst: well uniform unput
01:15 karolherbst: *input
01:15 karolherbst: and a[ is the real input
01:15 karolherbst: like FP inputs
01:16 karolherbst: like gl_color
01:16 karolherbst: those su* operations are kind of explained in the PTX docs though
01:16 karolherbst: but more like: if you want to do this, you can use this
01:17 karolherbst: and they still get lowered
01:17 karolherbst: I think subfm isn't one of them
01:17 karolherbst: sueau is some memory offset thing or translation stuff
01:17 karolherbst: and suldgb loads stuff... I think
01:17 robclark: does tgsi->codegen go directly to that, or are there some sort of psuedo opc's for images that get later lowered to that whole mess?
01:18 karolherbst: it gets lowered somewhere deeper down
01:18 karolherbst: so I don't have to deal with that on a nir level
01:18 robclark: fwiw, ldgb is basically memory load for me
01:18 robclark: ok, then at least you don't have to care about it as much ;-)
01:18 karolherbst: SUrface LoaD GloBal maybe
01:19 karolherbst: but still
01:19 karolherbst: if I want to get that CTS for 4.5 working, I need to fix that :)
01:22 robclark: the double vs in?
01:23 karolherbst: no, 3d images
01:23 robclark: ahh, yeah
01:23 karolherbst: at least for kepler
01:23 karolherbst: I think it works on maxwell
01:23 karolherbst: never checked though
01:23 robclark: well, anyways, even just getting 1d/2d images working is enough to implement/test all the barrier and other stuff needed for compute
01:24 karolherbst: yeah
14:27 bazzy: I just started noticing these lines in dmesg that have probably been there since I've started using nouveau. I'm not sure versed in their terminology. Could someone help me recognize this better?
14:28 bazzy: [ 24.287451] nouveau 0000:03:00.0: disp: outp 02:0006:0242: no bios dp data
14:28 bazzy: [ 24.287453] nouveau 0000:03:00.0: disp: outp 02:0006:0242: ctor failed: -22
14:28 bazzy: how serious is this?
14:29 gnarface: my guess would be non-critical
14:30 gnarface: looks like it's complaining that the bios can't find data about your display panel
14:30 gnarface: but if it works anyway, i wouldn't sweat it
14:30 gnarface: but like i said, that's just a guess
14:30 bazzy: I need to correct my statement - I think I've been getting these messages since I've added the config=NvForcePost=1 to my modprobe
14:31 pmoreau: The first one is harmless I would say, but I am not sure about the second.
14:31 bazzy: or since I've upgraded my kernel
14:32 bazzy: because the message is not present in the dmesg log I put up a few days ago @ https://bugs.freedesktop.org/show_bug.cgi?id=88272
14:32 pmoreau: I think you had them even before forcing POST. I have seen the first one for quite some time on my old laptop.
14:33 bazzy: actually, the nobios complaint is in the dmesg log, but the ctor line was not present
17:24 karolherbst: wow, that's cheating
17:24 karolherbst: image index is undefined in store_image
17:46 karolherbst: meh.. I see why
17:46 karolherbst: it is simply there for the indirect.. totally ignoring how that stuff is done in ubos/ssbos/texs...
18:45 karolherbst: pmoreau: unigine heaven runs without serious issues :)
18:45 karolherbst: some blue flickering, but kind of rare
18:46 karolherbst: fog or MS is a bit broken
21:32 NSA: after updating my mobo firmware i had 2 days of uptime until something crashed again https://gist.github.com/Nothing4You/8fd72a3ac9bf36f6b3e393c0a744c03a
21:43 pmoreau: karolherbst: \o/ Nice!
21:44 karolherbst: now I am fighting with those image formats...
21:44 karolherbst: of course I get the GL_ constants in
21:44 karolherbst: pmoreau: last piglit run: 30728/37878 :) nearly there
21:46 pmoreau: Getting there indeed!
21:47 karolherbst: apperantly GL_RGB10A2UI is wrong..
21:50 karolherbst: duh... GL_RGB10_A2UI
21:50 karolherbst: being consistent is very important
21:56 karolherbst: pmoreau: big item is tesselation still. the gallium code can't really handle that when going from glsl directly into nir
21:56 karolherbst: maybe it's fixed in seconds, maybe days
21:56 karolherbst: no idea
21:57 pmoreau: No clue either
21:58 karolherbst: well, no gallium driver is even near where we are now with nir.... maybe AMD, but I really don't know how far they got