IRC Logs of #dri-devel on for 2014-09-01

Previous dayChoose dateNext day Show menu

00:14 #dri-devel: < Kayden> man, this many applications worth of shaders and not a single isampler or usampler
00:14 #dri-devel: < Kayden> DX9 ports I guess
00:49 #dri-devel: < glennk> whompy, piglit, if any of the sample shading tests fail theres not a lot of point testing apps
00:49 #dri-devel: < glennk> for apps, unigine valley uses sample shading, and tesseract if you enable MSAA in the options menu
01:27 #dri-devel: < jekstrand> hm... Someone pinged me, but my backlog doesn't go back that far. Ping again if it was important.
01:29 #dri-devel: < Kayden> <airlied> jekstrand: btw coverity reported two memory leaks of tmp_row in texstore_rgba_integer and texstore_via_flaot
01:29 #dri-devel: < Kayden> was the last thing I saw
01:29 #dri-devel: < jekstrand> ok
01:29 #dri-devel: < jekstrand> thanks
01:30 #dri-devel: < Kayden>
01:33 #dri-devel: < jekstrand> that's useful
01:33 #dri-devel: < jekstrand> I'm also logging myself now
01:43 #dri-devel: < xexaxo> imirkin: the other solutions are quite invasive and will break Android even more :'(
01:46 #dri-devel: < xexaxo> MrCooper: libvdapu_<driver> should already be "plugin" style, and as imirkin mentioned it's meant to be consumed (dlopened) only by
01:48 #dri-devel: <+MrCooper> currently it's a shared library with SONAME
01:48 #dri-devel: < xexaxo> hmmm in that case I'm not sure what exactly you mean with "plugin style"
01:48 #dri-devel: < pq> xexaxo, re: ; the patch applies to 10.0, 10.1, and 10.2, will releases still be made from all those, and when sending to mesa-stable@, should I add any tags to the patch?
01:49 #dri-devel: <+MrCooper> xexaxo: like <driver>
01:49 #dri-devel: < xexaxo> pq: planning to make only 10.2+
01:51 #dri-devel: < xexaxo> MrCooper: I did assume that libtool's -module is the way to do the shared library vs plugin/module
01:52 #dri-devel: < xexaxo> MrCooper: the thing you're suggesting seems to be nothing move but a rename, and the object still remains as is.
01:53 #dri-devel: < xexaxo> MrCooper: the dynamic linker will not pick it up due to the lack to lib prefix, but I don't see how it makes is a plugin.
01:54 #dri-devel: < xexaxo> or perhaps I have no idea what I'm talking about :\
01:54 #dri-devel: <+MrCooper> hmm, I thought there was more difference, but maybe not
01:55 #dri-devel: < xexaxo> as mentioned -module should make the end library "dynamic linker, don't pick me up" afaik.
01:55 #dri-devel: < xexaxo> based on my understanding of the documentation. and ^^ sucks big time :'(
01:56 #dri-devel: <+MrCooper> do we need libvdpau_<driver>.so.1{,.0.0} though? Isn't the .so enough?
01:56 #dri-devel: < mlankhorst> erm we do
01:56 #dri-devel: < mlankhorst> libvdpau checks for .so.1 iirc
01:56 #dri-devel: < mlankhorst> you won't need the .so though
01:56 #dri-devel: < xexaxo> in theory we can go without the version, but in the future it will kick us in the b*lls
01:57 #dri-devel: < xexaxo> libvdpau checks the versioned, and then falls back on unversioned plugin/backends
01:58 #dri-devel: < mlankhorst> please don't go unversioned, you'll make my life harder
01:59 #dri-devel: <+MrCooper> I see, which leaves the question if libvdpau_<driver>.so.1 being picked up via the dynamic linker path instead of via the VDPAU driver path was ever a supported use case?
01:59 #dri-devel: < mlankhorst> no
02:00 #dri-devel: <+MrCooper> k, thanks for the clarification
02:01 #dri-devel: < xexaxo> MrCooper: libvdpau_<driver> is not meant to be located anywhere that the dynamic linker picks it up. up-to recently the stuff was so hardcoded that you had to rebuild libvdpau in order to use non-default libvdpau_* location
02:03 #dri-devel: <+MrCooper> I know, I suspect that's actually why some people have come to rely on it getting picked up via the dynamic linker path instead
02:07 #dri-devel: < xexaxo> unfortunately ^^ will do absolutely nothing but to annoy everyone. the backend is dlopened so I'm not sure what people expect to achieve :'(
02:08 #dri-devel: < xexaxo> for anyone interested in non default backend location - forward them to the libvdpau docs (search for VDPAU_DRIVER_PATH)
02:17 #dri-devel: <+MrCooper> well, the problem is it actually worked while the SONAME matched libvdpau_<driver>.so.1
02:28 #dri-devel: < xexaxo> indeed it worked = made the dynamic linker happy, but /some/directory/ did not get picked up :'(
02:29 #dri-devel: * xexaxo stops rambling on the topic
02:44 #dri-devel: < whompy> glennk: thanks, I'll try to test if I have time today
02:46 #dri-devel: <+MrCooper> xexaxo: not sure what you mean; of course those people would have made sure /some/directory/ is in the dynamic linker path, e.g. via LD_LIBRARY_PATH
02:47 #dri-devel: < mlankhorst> mesa rc2 seems to FTBFS
02:47 #dri-devel: < xexaxo> mlankhorst: logs ?
02:47 #dri-devel: < mlankhorst> ../../src/mesa/program/lex.yy.c:1226:5: error: unknown type name 'YYSTYPE'
02:48 #dri-devel: < mlankhorst> ../../../../src/mesa/program/program_lexer.l:122:64: error: unknown type name 'YYSTYPE'
02:49 #dri-devel: < xexaxo> mlankhorst: smells like "teen spirit" - something completely bonkers. got some info about the lex/bison/etc (pastebin would be great)
02:50 #dri-devel: < mlankhorst> ah right..
02:51 #dri-devel: < mlankhorst> error: object directory /home/mlankhorst/mesa/.git/objects does not exist; check .git/objects/info/alternates.
02:51 #dri-devel: < mlankhorst> though that was working before
02:52 #dri-devel: < xexaxo> MrCooper: (might come as a nob but ...) LD_LIBRARY_PATH does jack with the libvdpau backends - so using it is a waste of time.
02:53 #dri-devel: < xexaxo> mlankhorst: good luck. all my attempts to use git alternatives was futile :\
02:54 #dri-devel: < mlankhorst> xexaxo: it's because of a chroot
02:54 #dri-devel: < mlankhorst> but if pbuilder works I'm fine with that
02:55 #dri-devel: < xexaxo> how many builders are there in debian/ubuntu-land ? I've never heard about this one
02:57 #dri-devel: < mlankhorst> plenty :P
02:57 #dri-devel: < sjoerd> pbuilder is one of the most used ones though
03:00 #dri-devel: < xexaxo> I've been hoping to find one that works on most (all distros) and can generate packages for everyone
03:00 #dri-devel: < mlankhorst> I either use pbuilder or build in my netbootable chroot
03:00 #dri-devel: < xexaxo> so far OBS seems to fit the description but it's a bit ...
03:01 #dri-devel: < mlankhorst> debian packaging is not in the source, and won't be
03:04 #dri-devel: < mlankhorst> xexaxo: hm fails in pbuilder without git too
03:13 #dri-devel: < mlankhorst> but only the first time, it would seem
03:13 #dri-devel: < mlankhorst> I'll try building without parallel
03:13 #dri-devel: < mlankhorst> maybe you broke it with 88cbe3908f0ea08228a5ffb1808f98b6906c4416 ?
03:13 #dri-devel: < xexaxo> mlankhorst: logs or it did not happen :P btw I did try -j3 and -j6 and worked like a charm, not sure what you're doing there :)
03:14 #dri-devel: < mlankhorst> oh I'm on -j8, standard debian build though
03:18 #dri-devel: < mlankhorst> xexaxo: try an out of tree build with -j8 ?
03:19 #dri-devel: < mlankhorst> oh fails during make install..
03:20 #dri-devel: < mlankhorst>
03:23 #dri-devel: < xexaxo> mlankhorst: sure. meanwhile can you try a -j6 one ?
03:23 #dri-devel: < mlankhorst> that was a non-parallel one I think
03:23 #dri-devel: * mlankhorst retries
03:35 #dri-devel: < mlankhorst> xexaxo: non-parallel build works
03:45 #dri-devel: < mlankhorst> parallel -j8 build seems to fail on install consistently
03:46 #dri-devel: < xexaxo> build != install in my books. I would love if debian has the same distinction.
03:47 #dri-devel: < xexaxo> never tested parrallel installs and for all I know they are broken (well now it seems for sure) :P
03:48 #dri-devel: < mlankhorst> it makes a distinction, but it seems to run install in parallel if you set the build option..
03:48 #dri-devel: < mlankhorst> but yeah seems to be parallel install, still nothing should be built on install
03:49 #dri-devel: < xexaxo> yeah... /me waves to mesa's lovely build system chaos
03:50 #dri-devel: < xexaxo> the other solution is to just drop the lex/bison generated files from the tar-ball for now :\
03:51 #dri-devel: < xexaxo> perhaps the most reasonable solution until the build is fixed properly ?
03:52 #dri-devel: < mlankhorst> will that cause them to get autogenerated?
03:54 #dri-devel: < mlankhorst> xexaxo: seems to me it should have a dependency in lex.yy.c on
03:56 #dri-devel: < xexaxo> they will still get autogenerated at the normal build, but not at 'make tarball/dist' time
04:01 #dri-devel: < anpok> xexaxo: should i resend the kmsswrast patch, with the small, and to the proper lists?
04:01 #dri-devel: < anpok> *small fix for the stride ptr check
04:03 #dri-devel: < xexaxo> anpok: imho it should be fine as is.
04:04 #dri-devel: < xexaxo> mlankhorst: quite possible. I'd rather avoid adding extra duct-tape to something that does barely works, and will not be there for too long
04:04 #dri-devel: < mlankhorst> hm no that fails too
04:04 #dri-devel: < mlankhorst> maybe it's generated from 2 places at once?
04:06 #dri-devel: < xexaxo> just send out a patch, that reverts the commit and removes the files from the tarball.
04:07 #dri-devel: < mlankhorst> ok
04:07 #dri-devel: < xexaxo> imho it's not worth is nitpicking it too much as I'm planning to have 'make dist' working for 10.4, and the proposed solutions should work well enough for 10.2/10.3
04:08 #dri-devel: < xexaxo> mlankhorst: would appreciate a tested-by if the patch works for you :)
04:09 #dri-devel: < mlankhorst> sure, let me try if the revert works
04:14 #dri-devel: < mlankhorst> as far as I can tell it works
04:14 #dri-devel: < mlankhorst> so feel free to slap my tested-by on
04:36 #dri-devel: < xexaxo> mlankhorst: fence conversion - yesss :)
04:36 #dri-devel: < mlankhorst> indeed
04:45 #dri-devel: < mlankhorst> you'll need some patches on top for cross-dev sync :P
08:08 #dri-devel: < xexaxo> robclark: can I get an acked-by for ?
08:09 #dri-devel: < robclark> oh, did we still have that in the private header?
08:09 #dri-devel: < robclark> xexaxo, a-b :-)
08:09 #dri-devel: < robclark> thx
08:10 #dri-devel: < mlankhorst> oh speaking of which..
08:10 #dri-devel: < imirkin> xexaxo: fyi, i always just do "make -j8 install". why build + install when you can just install :)
08:10 #dri-devel: < mlankhorst> robclark: did you ever test fd with my changes? :P
08:11 #dri-devel: < robclark> hmm.. I think so
08:11 #dri-devel: < xexaxo> imirkin: no argument there, but note the release announcement (never officially tested so...)
08:11 #dri-devel: < robclark> pretty sure I'm using latest libdrm here.. didn't notice anything break :-P
08:11 #dri-devel: < mlankhorst> ah good
08:11 #dri-devel: < imirkin> xexaxo: yeah, just pointing that out vis-a-vis your "build != install" comment
08:12 #dri-devel: < robclark> xexaxo, hmm, I suppose I have a patch or two I should send for 10.3..
08:12 #dri-devel: < xexaxo> imirkin: hmm point taken. /me stops on the topic
08:13 #dri-devel: < xexaxo> robclark: send out the sha's, commit title and/or forward the email to mesa-stable. either one will do
08:14 #dri-devel: < robclark> yeah.. will do.. need to have a closer look at what all I should need.. when were you planning on doing next -rc?
08:16 #dri-devel: < xexaxo> normally on Fridays rc2 was an exception
08:16 #dri-devel: < robclark> k
08:16 #dri-devel: < xexaxo> if things are quiet we'll go with the original rc4=final, otherwise me may need to take a closer look
08:16 #dri-devel: * robclark assumes TGSI DDX/DDY opcodes map directly to dFdx()/dFdy()?
08:17 #dri-devel: < glennk> yup
08:17 #dri-devel: < robclark> ok.. there is one no-brainer segfault fix.. and at least one compiler fix but for latter I need to do a piglit run first..
08:17 #dri-devel: < robclark> k
08:17 #dri-devel: * robclark trying to make sense of what blob compiler does for dFdx()/dFdy()..
08:18 #dri-devel: < robclark> (since apparently google maps somehow uses those :-P)
08:18 #dri-devel: < glennk> it probably groups them with texture ops similar to r600 does
08:19 #dri-devel: < glennk> and likely its just one op for ddx, and one for ddy
08:19 #dri-devel: < imirkin> robclark: on nvidia hw, there are special instructions to do operations looking at registers of other lanes ("quadop")
08:21 #dri-devel: < robclark> yeah, they are grouped w/ texture fetch instructions..
08:21 #dri-devel: < robclark> and synchronization works same as tex fetch..
08:22 #dri-devel: < glennk> also the resource/sampler id sources are probably the same
08:22 #dri-devel: < robclark> but looks like it is doing something a bit more primitive.. and maybe returing 1/dx or 1/dy?
08:22 #dri-devel: < robclark>
08:23 #dri-devel: < robclark> (so.. bary.f is the varying fetch instruction.. guess I'll have to do a real draw to see what those constants are..)
08:24 #dri-devel: < robclark> oh, ok, I guess like texture fetch, they write multiple consecutive scalar regs..
08:27 #dri-devel: < imirkin> why doesn't it write to hr0.y?
08:28 #dri-devel: < imirkin> (which is, i'm guessing, the rt output)
08:29 #dri-devel: < robclark> it does.. that rptN flag means instruction is repeated N additional times w/ incrementing dst reg, and any src reg w/ (r) is incremented
08:30 #dri-devel: < robclark> hang on, I have a flag to disasm which makes that more clear..
08:30 #dri-devel: < imirkin> ah :) i thought it was just there for decorative purposes...
08:30 #dri-devel: < robclark> ie, like
08:30 #dri-devel: < imirkin> and is it just me or is it also getting the dfdx derivative too?
08:30 #dri-devel: < robclark> yeah, it's a way to get back some of the code-density lost by going with scalar :-P
08:31 #dri-devel: < robclark> yeah, that's what I'm trying to figure out wtf it is doing :-P
08:31 #dri-devel: < robclark> I guess I need to do some tests w/ standalone assembler..
08:31 #dri-devel: < imirkin> the real question is what's c243.w :)
08:32 #dri-devel: < robclark> right
08:32 #dri-devel: < imirkin> i bet it's 0
08:32 #dri-devel: < robclark> well, should know in just a sec..
08:36 #dri-devel: < glennk> i would expect fwidth() to emit both
08:37 #dri-devel: < robclark> imirkin, well, if it is 0, you can blame llvm :-P
08:38 #dri-devel: < imirkin> when in doubt... :)
08:45 #dri-devel: < robclark> ahh, there we go... yeah, c243=vec4(1.000000 0.000000 1.000000 0.000000) :-P
08:47 #dri-devel: < robclark> pretty awesome that it loads c0..c242 as well ;-)
08:47 #dri-devel: < imirkin> they probably wrote it to handle fwidth and dfdx/dfdy all with one sequence of instructions
08:47 #dri-devel: < imirkin> and just adjust it with cbuf values
08:47 #dri-devel: < glennk> sounds qc-ish to me
08:48 #dri-devel: < imirkin> since you know, alu ops are free
08:48 #dri-devel: < glennk> not to mention copy paste
08:50 #dri-devel: < robclark> yeah, the qc compiler does funny things from time to time.. I just blame it on llvm (although I'm sure qc is more to blame)
08:50 #dri-devel: < HdkR> hah
08:51 #dri-devel: < glennk> you can probably just emit dsy for ddy, and dsx for ddx, gallium takes care of flipping y if thats needed
08:51 #dri-devel: < robclark> hmm, yeah.. that is true.. one of the other funny cases ended up, I think, being do to handling y-flip in shader..
08:52 #dri-devel: < imirkin> nvidia does all that with constbufs too
08:52 #dri-devel: < imirkin> there's also a special register, ydir, which has a 1/-1 depending on... something
08:52 #dri-devel: < imirkin> but they don't appear to use it
08:54 #dri-devel: < glennk> fewer shader variants, their compiler is quite heavy so i guess they want to keep loading times down
08:56 #dri-devel: < imirkin> would it really be fewer in practice? i kinda figure a shader is either always used with fbo's or always used with... whatever the other thing is
08:56 #dri-devel: < glennk> these days probably
09:00 #dri-devel: < robclark> glennk, yeah, once I work out the math, looks like I can just keep dsy or dsx.. although not 100% sure why they do it as two ops (ie. 'dsy (f32)(xy)r0.x, ..' vs 'dsy (f32)(xyzw)r0.x, ...')
09:03 #dri-devel: < glennk> isn't it just one per scalar?
09:04 #dri-devel: < robclark> well.. texture fetch instructions are a bit weird.. in that they can take multiple consecutive inputs and/or outputs..
09:04 #dri-devel: < robclark> ie. so if r0.x is src, it really means r0.xy (or r0.xyw, etc)
09:04 #dri-devel: < robclark> and r1.y as dst, means r1.yz (in this case, because writemask is xy)
09:05 #dri-devel: * robclark assumes for dsy/dsx that # of src components == # of dst components
09:06 #dri-devel: < robclark> ok.. that is enough of android..
09:06 #dri-devel: * robclark boots back to linux..
10:25 #dri-devel: < zgreg_> imirkin: does your latest patchset fix vdpau getbits?
10:25 #dri-devel: < imirkin> zgreg_: yep
10:25 #dri-devel: < zgreg_> nice :)
10:26 #dri-devel: < imirkin> zgreg_: turns out it's important to return data from the chroma plane for the UV bits...
10:28 #dri-devel: < imirkin> what is the most minimal compositor out there that's enough to get prime redirection working? (i understand that xcompmgr isn't enough)
10:34 #dri-devel: < zgreg_> imirkin: compton?
10:35 #dri-devel: < imirkin> seriously? ugh. i thought that was a heavy one.
10:35 #dri-devel: < imirkin> there's no like... glcompmgr or whatever? :)
10:35 #dri-devel: < zgreg_> not that I know of
10:35 #dri-devel: < imirkin> oh, actually it doesn't look so bad
10:35 #dri-devel: < zgreg_> isn't compton rather light weight though? compared to compiz, mutter, kwin, etc?
10:35 #dri-devel: < imirkin> perhaps i was confusing it with compiz :)
10:36 #dri-devel: < imirkin> same first few letters...
10:36 #dri-devel: < zgreg_> yeah
10:37 #dri-devel: < tobijk> throwing in weston, i think it can do that now?
10:38 #dri-devel: < austriancoder> so.. i want to write a ddx driver for a render-only gpu - any good starting points?
10:39 #dri-devel: < imirkin> austriancoder: with dri3, you don't need to, i think
10:41 #dri-devel: < imirkin> austriancoder: but you can also use the modesetting driver... not sure how much modesetting stuff it actually needs, might need to fake some stuff
10:41 #dri-devel: < austriancoder> there is a ready to use kms driver in mainline kernel and there is a work
10:42 #dri-devel: < austriancoder> in progress drm driver for the vivante gpu with a working libdrm for 2d stuff
10:42 #dri-devel: < austriancoder> does this man i only need to write a DRI3 gpu driver?
10:42 #dri-devel: < CME> zgreg_, imirkin compton is way slower on my e450 than kwin
10:42 #dri-devel: < imirkin> austriancoder: they also have a gallium driver, right?
10:43 #dri-devel: < imirkin> austriancoder: gallium now has dri3 support, so it should all be ready to go... afaik.
10:43 #dri-devel: < austriancoder> imirkin, nope... at the moment there is no ready to use gallium driver (with the drm kernel driver). also it would be great to use the 2d gpu as it consumes much less power
10:44 #dri-devel: < imirkin> less power than?
10:44 #dri-devel: < austriancoder> imirkin, ahh.. DRI3 makes use of opengl(es) for DRI3
10:44 #dri-devel: < austriancoder> imirkin, less power then the 3d gpu core on the soc
10:44 #dri-devel: < imirkin> dri3 is an X interface for applications to draw into things that are displayed on the screen
10:44 #dri-devel: < imirkin> dri3 has no knowledge of 2d, 3d, drivers, or anything like that
10:45 #dri-devel: < imirkin> it's just for passing images around... afaik
10:45 #dri-devel: < xexaxo> get this image, shove it on the screen. how you get the image is up-to you(r driver)
10:45 #dri-devel: < austriancoder> dma-buf
10:45 #dri-devel: < austriancoder> okay
10:45 #dri-devel: < austriancoder> but the drawing is still done on the cpu - or?
10:45 #dri-devel: < imirkin> ...
10:45 #dri-devel: < imirkin> if you draw on the cpu, it's done on the cpu
10:46 #dri-devel: < imirkin> not sure what your question is
10:46 #dri-devel: < xexaxo> vivante draws the image, passes the fd to imx6 which displays is :)
10:46 #dri-devel: < imirkin> dri3 is just about displaying images that were drawn. it has no knowledge (or care) of how they were drawn
10:47 #dri-devel: < austriancoder> imirkin, okay.. so I do not want to write a DRI3 driver.. I want to write a simple 2d driver like xf86-video-freedreno, execpt that my target gpu is render-only (on video output)
10:48 #dri-devel: < imirkin> how do you output video?
10:48 #dri-devel: < austriancoder> there is a seperate IP on the SoC (IPUv3) which can drive LVS, HDMI...
10:48 #dri-devel: < imirkin> how is that different than any normal gpu btw?
10:49 #dri-devel: < imirkin> gpu's can draw, they can display stuff. the two functionalities are on the same chip but are totally different than one another
10:49 #dri-devel: < imirkin> i guess you need two separate card handles which the ddx probably won't like... hm.
10:50 #dri-devel: < austriancoder> imirkin, it is like on the tegra K1.
10:50 #dri-devel: < imirkin> right, i get that.
10:51 #dri-devel: < robclark> imirkin, vivante has a 2d core as well as 3d core..
10:51 #dri-devel: < imirkin> except i think on the K1 the output chip can also do some 2d stuff... not sure though
10:51 #dri-devel: < robclark> (right.. I think vivante and k1 are similar in that regard.. except 2d is via the 3d drm device instead of the modesetting device)
10:52 #dri-devel: < robclark> anyways, short version, open both drm devices, use dma-buf/prime to share the buffers between the two..
10:52 #dri-devel: < imirkin> can you do that in the ddx? i kinda assumed the x server would have already taken care of opening stuff
10:52 #dri-devel: < imirkin> (with all that privilege dropping BS)
10:52 #dri-devel: < xexaxo> robclark: nvidia cards have 2d engine which we use alongside the 3d one. that can be considered "implementation details" within the gallium driver
10:52 #dri-devel: < robclark> nope.. well.. depends..
10:53 #dri-devel: < robclark> imirkin, if you have logind stuff, the display device is opened already for you
10:53 #dri-devel: < austriancoder> should PRIME handle it (out of the box?)
10:53 #dri-devel: < robclark> then in that case you just need to open the 2nd device yourself
10:53 #dri-devel: < robclark> prime/dmabuf gives you the building blocks.. but you still need to put the two halves together..
10:54 #dri-devel: < robclark> (or at least you do if you want to use 2d accel, vs just glamor)
10:54 #dri-devel: < robclark> xexaxo, well, there isn't really a good way for gallium driver to know you are only doing 2d..
10:54 #dri-devel: < austriancoder> okay.. so my ddx driver opens the 2d core device and gets an fd from the master device?
10:54 #dri-devel: < robclark> xexaxo, so if you are going to use 2d, you might as well just implement exa directly
10:55 #dri-devel: < robclark> austriancoder, have a look at that XF86_PDEV_SERVER_FD stuff added recently.. that is the case where the display device is already opened for you.. if you are not using a 1.16 xserver you could probably ignore that and do it the old way for now
10:56 #dri-devel: < xexaxo> robclark: how well does xa fit into the whole thing - does it provide some hints if one wants to go the 2d road ?
10:56 #dri-devel: < robclark> not really..
10:57 #dri-devel: < xexaxo> so essentially it's glamor's brother
10:57 #dri-devel: < robclark> I had kinda thought about adding a pipe cap.. because *really* what I want to do for 2d is disable blending and do that manually in shader w/ src as an additional texture..
10:58 #dri-devel: < austriancoder> robclark, I have a 1.16 xserver running - so I will jump on this road
10:58 #dri-devel: < robclark> yeah.. really the only good option if you want to use 2d currently is just implement exa.. perhaps someone could invent a gl extension that glamor could use to make it a bit easier
10:59 #dri-devel: < robclark> (or perhaps it is just not worth it, and implement traditional exa w/ fallback to xa and/or glamor somehow when you don't have a 2d core)
12:04 #dri-devel: < whompy> I am very much new to piglit. How would I go about running a specific group of tests for an extension? (ARB_sample_shading in this case) Also, what type of run should I perform for regression testing?
12:05 #dri-devel: < whompy> I know some take longer than others, not sure if is necessary for that.
12:05 #dri-devel: < imirkin> -t sample_shading
12:05 #dri-devel: < whompy> imirkin: thanks
12:05 #dri-devel: < imirkin> tests/ is what i usually use
12:18 #dri-devel: < glennk> whompy, tests/quick for a full regression run, takes ~10 minutes
12:19 #dri-devel: < whompy> glennk: will do, thanks. I've finally got an excuse to figure out piglit.:)
12:19 #dri-devel: < glennk> heh, its really quite useful for developing features
12:20 #dri-devel: < glennk> now to try to find volunteers for testing cayman :-)
12:27 #dri-devel: < haagch> hm, nobody with intel graphics is using bino I guess
12:28 #dri-devel: < haagch> with dri3:
12:28 #dri-devel: < haagch> with LIBGL_DRI3_DISABLE=1 a different one
12:29 #dri-devel: < imirkin> cPriv == 0 -- that seems unfortunate
12:34 #dri-devel: < robclark> xexaxo, others, it was suggested (in a forum that chances are whoever does the next libdrm release wouldn't notice) that next libdrm be 2.5.0..
12:34 #dri-devel: < xexaxo> robclark: noticed that one, and we're not there yet. libdrm for android will build but fail miserably.
12:35 #dri-devel: < robclark> (that might be overkill, depending on what odds you give for symbol visibility to break something)
12:35 #dri-devel: < xexaxo> I'd rather avoid that for a release :)
12:36 #dri-devel: < robclark> yeah, I think the symbol visibility is a more valid (but still tenuous) reason..
12:36 #dri-devel: < robclark> tbh, I think "for the hell of it" is probably a better reason :-P
12:51 #dri-devel: < haagch> imirkin: is it a quick fix or do I make a bug report?
12:51 #dri-devel: < imirkin> haagch: dunno
12:51 #dri-devel: < imirkin> iow, file a bug :)
12:52 #dri-devel: < haagch> it's coming directly from qt, so it surely has some significance
13:25 #dri-devel: < xexaxo> robclark: the idea is great, but as I'd rather fix the final piece than naming a completely broken thing a "release" :) should be done soon (tm)
13:28 #dri-devel: < robclark> ;-)
13:37 #dri-devel: < zgreg_> imirkin: btw, can you mayb test how nvidia hw does 422 chroma filtering?
13:49 #dri-devel: < jekstrand> airlied: Seeing as you reported the bug, mind reviewing the patch:
13:49 #dri-devel: * jekstrand aparently posted the first 3 patches to the list this month. I hate insomnia...
13:50 #dri-devel: <+airlied> jekstrand: just stick in the commit msg that coverity reported it (just to make them feel useful :-)
13:50 #dri-devel: <+airlied> otherwise feel free to add r-b by me to it
13:55 #dri-devel: < imirkin> zgreg_: i can run any tests you want me to... but you have to be more specific :)
13:55 #dri-devel: < jekstrand> airlied: Sorry, I'm not particularly familiar with coverity
13:56 #dri-devel: < mattst88_> it's a static analysis tool.
14:16 #dri-devel: < zgreg_> imirkin: sure. can you please play in mplayer or mpv with vdpau video output and post a screenshot?
14:17 #dri-devel: < imirkin> with blob driver i assume?
14:21 #dri-devel: < zgreg_> doesn't that work with nouveau, too?
14:21 #dri-devel: < imirkin> i dunno, just trying to figure out what you want me to test :)
14:22 #dri-devel: < zgreg_> should be similar anyway, I guess
14:22 #dri-devel: < imirkin> we only support 4:2:0 output
14:22 #dri-devel: < imirkin> so i dunno what'll happen... there's one way to find out!
14:22 #dri-devel: < imirkin> (if i disconnect, you'll know why :) )
14:22 #dri-devel: < zgreg_> what do you mean with that?
14:22 #dri-devel: < zgreg_> output is of course rgb in the end :)
14:23 #dri-devel: < imirkin> right
14:23 #dri-devel: < imirkin> i mean the decoding
14:23 #dri-devel: < zgreg_> oh, ok
14:23 #dri-devel: < imirkin> is to a 4:2:0 surface
14:23 #dri-devel: < zgreg_> well of course
14:23 #dri-devel: < imirkin> so if it's a 4:2:2 mpeg, i guess it'll lose some bits?
14:23 #dri-devel: < zgreg_> I don't want you to test hw decoding, just presentation
14:23 #dri-devel: < imirkin> oh
14:24 #dri-devel: < zgreg_> again, I simply want to find out if the chroma sampling on nvidia hw works better
14:24 #dri-devel: < imirkin> k. gimme a sec.
14:24 #dri-devel: < zgreg_> ok, great
14:31 #dri-devel: < imirkin> zgreg_: overall, i'd say that went poorly
14:32 #dri-devel: < imirkin> i guess i'll have to look into why that hangs the gpu... ugh.
14:32 #dri-devel: < zgreg_> oh... well, thanks for testing :)
14:33 #dri-devel: < imirkin> now we know how well it works on nouveau though :)
14:41 #dri-devel: < glennk> imirkin, i guess you've implemented chroma hanging
14:42 #dri-devel: < imirkin> yes, that implementation is complete
14:42 #dri-devel: < imirkin> now i need to implement *not* hanging chroma...
14:42 #dri-devel: < zgreg_> heh
14:42 #dri-devel: < imirkin> although i'm gonna go ahead and blame mlankhorst on this one... he did the initial video stuff in nouveau
14:45 #dri-devel: < glennk> reminds me, you guys did fix vsync finally?
14:45 #dri-devel: < imirkin> claims have been made to that effect, i haven't tested
14:47 #dri-devel: < imirkin> somebody apparently *really* cared about it deeply and had a sensitive-enough application to debug it with
14:47 #dri-devel: < glennk> watching video without vsync is like watching a japanese ntsc-50hz upconverted to ntsc-60 and then pulled down to pal
14:47 #dri-devel: < glennk> horizontal pan scene = augh my eyes
14:48 #dri-devel: < imirkin> yeah, it can be annoying
14:48 #dri-devel: < imirkin> but also a giant pain to debug :)
14:49 #dri-devel: < glennk> i recommend a high speed camera, and a few leds connected to gpios that can be big banged with low latency
14:50 #dri-devel: < tobijk> "that'll take a while"
14:52 #dri-devel: < CME> zgreg_, with the blob:
14:53 #dri-devel: * maelcum is wondering why vsync has to be as fugly as it is
14:54 #dri-devel: < maelcum> there are thousands of lines of code dedicated to synchronizing frame updates between the kernel, X, and DRI clients, afaict.
14:55 #dri-devel: < imirkin> the problem is that you don't want to slow things down immensely
14:55 #dri-devel: < imirkin> so you can't just start waiting all over the place
14:56 #dri-devel: < imirkin> and also getting things right wrt when a vblank exactly occurs can be tricky
14:56 #dri-devel: < imirkin> and if you get it wrong, it can be very difficult to notice
14:56 #dri-devel: < maelcum> theoretically (and i don't know that much about it) you can always either submit or queue the update :)
14:56 #dri-devel: < glennk> it can get real fun with multiple outputs and surfaces spanning outputs with different rates or unsynchronized clocks
14:56 #dri-devel: < maelcum> ah yes, that sounds "interesting"
14:57 #dri-devel: < imirkin> yeah, with multiple outputs you're just screwed
14:58 #dri-devel: < maelcum> / ### we are screwed here
14:58 #dri-devel: < glennk> well, if they are non-integer rates and the clocks skew sure
14:58 #dri-devel: < maelcum> doesn't take thousands of lines, right? ;)
14:59 #dri-devel: < glennk> CME, looks like a higher than bicubic order filter on that
14:59 #dri-devel: < glennk> some ringing going on at least vertically
15:38 #dri-devel: < zgreg_> CME: thanks. looks like it does full filtering.
15:40 #dri-devel: < zgreg_> CME: that does not use any special hq scaling options or the like?
15:42 #dri-devel: < mattst88_> xexaxo: could you pick af13cf609 to 10.3? (af13cf609f4257768ad8b80be8cec7f2e6ca8c81)
15:42 #dri-devel: < mattst88_>
15:43 #dri-devel: < mattst88_> we definitely want it in 10.3
15:45 #dri-devel: < CME> zgreg_, oh right, hqscaling was enabled, but it doesn't look much different without
15:48 #dri-devel: < xexaxo> mattst88_: the bugreport states that af13cf609f4257768ad8b80be8cec7f2e6ca8c81 causes 10-90% perf regression. and you'd like that in 10.3 ?
15:48 #dri-devel: < xexaxo> or the commit that reverts it ?
15:50 #dri-devel: < mattst88_> xexaxo: the revert, sorry :)
15:50 #dri-devel: < xexaxo> afaics the offending commit is in 10.3. can you forward the sha of the revert to mesa-stable ? I'd rather not get that one wrong (as well)
15:50 #dri-devel: < mattst88_> sure
15:52 #dri-devel: < xexaxo> mattst88_: did you see how nicely I broke 'make -jN install' :)
15:53 #dri-devel: < xexaxo> do you have any suggestions/alternative fix ?

Written by Christoph Brill © 2007-2014

Valid XHTML 1.0 Transitional

Available in Android Market