IRC Logs of #dri-devel on irc.freenode.net for 2017-01-24


Previous dayChoose dateNext day Show menu

00:54 #dri-devel: <+airlied> chadv, lostgoat : going to be rebasing the internal vr branch btw, bit messy
00:55 #dri-devel: < chadv> airlied: thanks for doing the gruntwork. i pushed patches a few hours ago, btw. i'll stay away from the branch until you're finished rebasing.
00:56 #dri-devel: < lostgoat> thanks airlied
00:56 #dri-devel: < lostgoat> that should bring compute support in (which I think wasn't there before)
00:57 #dri-devel: < lostgoat> btw, the linux.conf.au talk was fun
00:59 #dri-devel: < kisak> imirkin_: I'm starting to think perf doesn't like me, but it's probably my fault
01:07 #dri-devel: <+MrCooper> kisak: why do you think it doesn't like you? What's the issue?
01:11 #dri-devel: < imirkin> kisak: yeah, perf tends to have lots of highly personal opinions about the individuals running it :)
01:15 #dri-devel: < kisak> I'n getting no usable output from perf report, I was thinking it was that I forgot to tell it what to track, but now I got it to give me Samples: 835K of event 'cycles:u' and still nothing of value after it
01:15 #dri-devel: < imirkin> weird.
01:16 #dri-devel: < imirkin> i generally just run 'perf record -g' and then look at perf report output. never had issues.
01:16 #dri-devel: < kisak> yup, user error
01:17 #dri-devel: < kisak> I was running perf report perf.data and that was a bad idea
01:18 #dri-devel: < imirkin> ah heheh
01:44 #dri-devel: < imirkin> glennk: is the zero_wins mul difference on r600 MUL vs MUL_IEEE? if so, looks like we already use the non-ieee version...
01:46 #dri-devel: < imirkin> i also see a bunch of *_CLAMPED instructions
01:48 #dri-devel: < imirkin> yeah. looks like that's it... should probably be using MUL_IEEE in the common case...
01:56 #dri-devel: <+airlied> chadv, lostgoat : okay new vr branch pushed internally, I can run stuff still with it, hopefully anv works okay
01:58 #dri-devel: < Plagman> there's anv bits with the vr stuff in the same khronos tree now?
02:00 #dri-devel: <+airlied> not sure if it's all there, but yes we are attempting to share the branch
02:09 #dri-devel: < mattst88> xexaxo1: https://mesa.freedesktop.org/archive/12.0.6/ is 404?
02:09 #dri-devel: < mattst88> something happened to the upload?
02:11 #dri-devel: < xexaxo1> mattst88: ack, ty
02:20 #dri-devel: < imirkin> mannerov: patches on list for r600g zero wins - looks like zero has been winning on there this whole time :)
02:35 #dri-devel: < jekstrand> :-/
03:36 #dri-devel: < imirkin> why is libdrm_amdgpu required to build radeonsi :(
03:36 #dri-devel: <+airlied> because radeonsi needs it?
03:37 #dri-devel: < imirkin> shouldn't it be totally fine with libdrm_radeon?
03:37 #dri-devel: * airlied hit the wayland version bump this morning
03:37 #dri-devel: <+airlied> no it needs both
03:37 #dri-devel: < imirkin> let me rephrase -
03:37 #dri-devel: < imirkin> couldn't it be totally fine with just one of them? :)
03:38 #dri-devel: <+airlied> if you had an option to only build supprot for half of it
03:39 #dri-devel: < imirkin> all that code is pretty well-isolated i thought
03:39 #dri-devel: <+airlied> we don't say build radeonsi except for VI hw
03:39 #dri-devel: < imirkin> either way, wtvr. libdrm_amdgpu isn't such a heavy dep, i just built it
03:40 #dri-devel: * imirkin wrote some horribly hacky code... going to see if it compiles
03:40 #dri-devel: <+airlied> building radeonsi without it is a bug
03:40 #dri-devel: <+airlied> we'd never want that in the real world
03:41 #dri-devel: < imirkin> k
04:05 #dri-devel: < imirkin> https://github.com/KhronosGroup/VK-GL-CTS/tree/master/external/openglcts/modules
04:05 #dri-devel: < imirkin> is this the real GL CTS?
04:07 #dri-devel: <+airlied> yes
04:07 #dri-devel: <+airlied> modulo some older tests
04:08 #dri-devel: < imirkin> awesome, thanks =]
04:08 #dri-devel: <+airlied> it should at least have the sburoutine tests that nouveau gets stuck on for ages
04:13 #dri-devel: * imirkin will look at crashes first
04:13 #dri-devel: * imirkin doesn't like crashes
04:14 #dri-devel: <+airlied> I think there was some spilly problems, not sure how many crashes
04:14 #dri-devel: < imirkin> i "fixed" those spill issues iirc
04:14 #dri-devel: < imirkin> aka made the compiler eliminate one of the args to the tex instructions which made the RA work :)
04:14 #dri-devel: <+airlied> https://people.freedesktop.org/~airlied/piglit/si-nv-cts/cts_gl45/gl45-cts@arrays_of_arrays_gl@interactionfunctioncalls2.html
04:15 #dri-devel: <+airlied> but yeah there was one or two crashes in there
04:15 #dri-devel: < imirkin> that's a long time.
04:16 #dri-devel: <+airlied> yeah I have to switch on the mbp to dig up the last run
04:16 #dri-devel: <+airlied> but now yhou can make your own runs :)
04:16 #dri-devel: < imirkin> of... course... X operation 155:34 failed: GLXBadFBConfig
04:16 #dri-devel: < imirkin> ugh.
04:17 #dri-devel: < imirkin> any advice off the top of your head?
04:18 #dri-devel: <+airlied> oh wow don't remember seeing that before, just running the glctx?
04:18 #dri-devel: <+airlied> glcts?
04:18 #dri-devel: < imirkin> yeah
04:19 #dri-devel: < imirkin> i remember getting that error when i was first getting deqp up and running
04:19 #dri-devel: < imirkin> had to make a bunch of patches to the X server to support various context versions
04:22 #dri-devel: <+airlied> okay no idea then if you had to hack X server
04:23 #dri-devel: <+airlied> might be some deqp patches need pulling in
04:23 #dri-devel: < imirkin> heh, no - those are all in X server now
04:23 #dri-devel: < imirkin> this was a while back
04:23 #dri-devel: * airlied builds it
04:23 #dri-devel: < imirkin> https://hastebin.com/onujolefih.sql
04:24 #dri-devel: < imirkin> oh!
04:24 #dri-devel: < imirkin> it wants GL 4.5
04:24 #dri-devel: < imirkin> heh
04:25 #dri-devel: < imirkin> much better. false alarm!
04:26 #dri-devel: <+airlied> imirkin: oh that makes more sense
04:41 #dri-devel: < imirkin> gr. the copy_image thing is annoying.
04:41 #dri-devel: < imirkin> the texture ends up as bgra4, while the renderbuffer ends up as rgba8
04:43 #dri-devel: < imirkin> because we can only sample from bgra4, not render.
04:45 #dri-devel: <+airlied> does the blob do magic?
04:47 #dri-devel: < imirkin> dunno. i think blob might just not expose the bgra4 format.
04:47 #dri-devel: < imirkin> <Text>Cannot obtain glGetCompressedTextureSubImage or glGetTextureSubImage function pointer.</Text>
04:47 #dri-devel: < imirkin> wtf
06:31 #dri-devel: < imirkin> hm. we currently don't support stuff like
06:31 #dri-devel: < imirkin> vec4 Load(layout(rgba32f) volatile image2D image, ivec2 coord)
06:31 #dri-devel: < imirkin> is that known?
06:34 #dri-devel: < Kayden> yes, that's illegal
06:34 #dri-devel: < Kayden> where are you seeing that?
06:35 #dri-devel: < imirkin> is it? it's one of the examples in ARB_shader_image_load_store
06:35 #dri-devel: < Kayden> ooh, really? I'll let people know to fix that.
06:36 #dri-devel: < imirkin> there's also a self-contradictory sentence there that's in the spec
06:36 #dri-devel: < imirkin> although the spec appears to have lost that example
06:36 #dri-devel: < imirkin> "Layout qualifiers cannot be used on formal function parameters, but they are not included in parameter matching."
06:36 #dri-devel: < Kayden> huh, I don't see that now
06:36 #dri-devel: < Kayden> oh, that's poorly woorded
06:36 #dri-devel: < imirkin> https://hastebin.com/ofunonocay.coffeescript
06:37 #dri-devel: < imirkin> that's from the image_load_store spec itself
06:37 #dri-devel: < Kayden> https://cvs.khronos.org/bugzilla/show_bug.cgi?id=15981 resolved with ES saying "Layout qualifiers cannot be used on formal function parameters, and layout qualification is not included in parameter matching."
06:37 #dri-devel: < imirkin> glsl 4.20 drops the layout() from the example
06:37 #dri-devel: < Kayden> https://cvs.khronos.org/bugzilla/show_bug.cgi?id=11466 agreed that GL should not allow this either
06:37 #dri-devel: < Kayden> there was a conformance test and they dropped it from there.
06:37 #dri-devel: < imirkin> ok. well it's also in the cts tests
06:37 #dri-devel: < imirkin> ok
06:38 #dri-devel: < imirkin> perhaps it was expected to fail :)
06:38 #dri-devel: < Kayden> I think what they mean by "not included in matching" is that you can just have an image2D parameter
06:38 #dri-devel: < Kayden> instead of having to declare both as layout(some format) image2D
06:39 #dri-devel: < imirkin> right.
06:57 #dri-devel: < mannerov> imirkin: yes with sb backend, not with llvm r600
06:59 #dri-devel: < imirkin> mannerov: llvm r600 backend is only used for opencl anyways
08:51 #dri-devel: < glennk> imirkin, DOT4_IEEE will likely need a minor patch to SB, you can grep for DOT and see where
08:52 #dri-devel: < glennk> i'm wondering if legacy GL contexts might need zero wins to not break some games/apps that relied on glsl not generating NaNs
13:54 #dri-devel: < nha> mesa/docs/spec mentions two wayland-related EGL_WL_* extensions which are quite old but do not appear in the EGL registry. Any particular reason why not?
14:16 #dri-devel: < lordheavy> owo, lot of love here :) https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/926699-watch-david-airlie-talk-about-vulkan-radv-from-lca2017?p=926781#post926781
14:36 #dri-devel: < imirkin> glennk: is what i did insufficient?
14:37 #dri-devel: < imirkin> glennk: as for legacy contexts... note that this is what nv50, nvc0, i965, and radeonsi do... presumably they'd show issues as well?
15:34 #dri-devel: < spstarr> xexaxo1: I'll reinstall older Vulkan RPM and try patch
15:47 #dri-devel: < spstarr> chadv: ping
15:47 #dri-devel: < spstarr> chadv: ^^ i donno, but Fedora has a newer Vulkan RPM available but not pushed to Fedora 25 yet
15:48 #dri-devel: < spstarr> https://koji.fedoraproject.org/koji/packageinfo?packageID=23126
15:48 #dri-devel: < spstarr> 1.0.39.0 just hit rawhide but while 1.0.37 is next in line for Fedora 25
15:50 #dri-devel: < chadv> spstarr: do you know where the bug is in the loader? or, if it's a loader bug at all?
15:50 #dri-devel: < chadv> spstarr: if so, then maybe we can backport the fix to a 1.0.37-2.fc{24,25}.rpm
15:52 #dri-devel: < spstarr> chadv: unsure, im going to be building new graphics stack shortly, kernel/mesa/LLVM (for HSW/AMDGPU prime usage)
15:52 #dri-devel: < spstarr> since Vulkan officially doesn't have something like PRIME yet.... it will only load ANV not radv
15:53 #dri-devel: * chadv reads spstarr's bug report
15:54 #dri-devel: < xexaxo1> chadv: I'd strongly encourage you to skim through the git log linked ;-)
15:56 #dri-devel: < chadv> xexaxo1: will do
16:05 #dri-devel: < mannerov> In dx9 in shaders you can set precision modifier, and in particular you can allow fp16. The shader compiler tends to aggressively set it if devs don't enforce full precision.
16:05 #dri-devel: < mannerov> In heaven there an argb32f RT that's read several times as texture after
16:06 #dri-devel: < mannerov> And the shader to write it was allowing fp16 computation
16:06 #dri-devel: < mannerov> so I've tried thanks to someone lending me their machine on windows nvidia a trace of heaven
16:06 #dri-devel: < mannerov> and the RT seems to have fp32 precision content, which means it's not demoted to argb16f
16:07 #dri-devel: < mannerov> my tests showed it's not demoted either on AMD
16:07 #dri-devel: < mannerov> A bit disappointed :-( This seemed like a legal and clever optimization
16:08 #dri-devel: < mannerov> (or perhaps when the drivers detect apitrace, they don't enable their optimizations)
16:12 #dri-devel: < imirkin_> mannerov: there are no fp16 ops on nvidia
16:13 #dri-devel: < mannerov> I didn't expect to use fp16 ops
16:13 #dri-devel: < mannerov> but to demote the argb32f to argb16f
16:13 #dri-devel: < imirkin_> ohhh
16:13 #dri-devel: < imirkin_> yeah that'd be clever
16:14 #dri-devel: < mannerov> and significant gain on heaven
16:14 #dri-devel: < mannerov> I don't remember exactly the figures when I tried, it was like 20%
16:15 #dri-devel: < imirkin_> mannerov: btw, i sent both r600 patches and a very-hacky-wont-fully-work si version of the mul zero thing. dunno if you have the hw or people who can test, but just fyi.
16:17 #dri-devel: < mannerov> I don't have r600, but I can ask
16:17 #dri-devel: < mannerov> I have VI, and SI, but getting to test on SI will be more work
16:18 #dri-devel: < imirkin_> oh, well my code should handle both. just won't account for a number of situations where mad/mul might be used where there's no "legacy" counterpart instruction i can flip it to.
16:18 #dri-devel: < FireBurn> spstarr, for me it only loads radv, it enumerates and uses dri0 first - for me that's my amdgpu tonga card
16:18 #dri-devel: < imirkin_> so the whole approach is buggered
16:19 #dri-devel: < FireBurn> spstarr, without airlied's prime patches that means you don't get any rendering and currently I get a crash
16:20 #dri-devel: < mannerov> imirkin_: what do you mean ? Isn't just changing the opcode sufficient ? In which situation there would be no legacy counterpart ?
16:20 #dri-devel: < imirkin_> MAC, among others
16:20 #dri-devel: < imirkin_> which is a 2-operand MAD, where src2 reg == dst reg
16:21 #dri-devel: < imirkin_> also various variants involving constants
16:21 #dri-devel: < imirkin_> er, immediates
16:21 #dri-devel: < mannerov> imirkin_: SI has MAC legacy
16:22 #dri-devel: < imirkin_> i know, but VI doesn't
16:39 #dri-devel: < spstarr> FireBurn: yes it enumerates for me also
16:43 #dri-devel: < mannerov> imirkin_: about the optimization, I think that's something they must have thought of
16:43 #dri-devel: < mannerov> so if they don't do it, there must be a reason. Perhaps regressions
16:44 #dri-devel: < imirkin_> well, it can be tricky to adjust formats
16:48 #dri-devel: < mannerov> yet AMD's "Catalyst AI" is all about optimizing formats, and for sure nvidia has similar
16:49 #dri-devel: < mannerov> But Catalyst AI has only effects on selected games in my understanding
17:23 #dri-devel: < imirkin_> so... nouveau is running into a funny (ha ha) ARB_copy_image issue. was hoping to get some feedback.
17:23 #dri-devel: < imirkin_> nouveau supports texturing BGRA4 but not rendering to it
17:23 #dri-devel: < imirkin_> so when a render buffer is created with format=GL_RGBA4, internally, it gets a rgba8 format
17:23 #dri-devel: < imirkin_> however a texture created with GL_RGBA4 gets a rgba4 format
17:24 #dri-devel: < imirkin_> (and is non-renderable if you try to attach it to a fb)
17:24 #dri-devel: < imirkin_> however there's a CTS test that tries to do glCopyImageSubData between them
17:24 #dri-devel: < imirkin_> which triggers asserts-galore due to the internal formats not matching
17:24 #dri-devel: < imirkin_> so ... the question is -- "do i need to handle it, or can i just error out with INVALID_OPERATION"
17:43 #dri-devel: < HdkR> Wow. Khronos' conformance tests going OSS
17:43 #dri-devel: < HdkR> That's awesome
17:44 #dri-devel: < imirkin_> yeah, i noticed that tree last night. hence my question above - something those tests hit :)
17:44 #dri-devel: < robclark> imirkin, at least for gles (not sure about gl), spec calls out formats that need to be renderable vs textureable.. although no idea where that leaves glCopyImageSubData().. you need a spec lawyer ;-)
17:44 #dri-devel: < imirkin_> since no one in their right mind uses GL_RGBA4 renderbuffers, or uses renderbuffers with copy image.
17:45 #dri-devel: < imirkin_> robclark: the GL spec is nowhere that precise. but even in the gles spec, it's fine for RGBA4 to not be renderable, if it's in the list at all.
17:45 #dri-devel: < imirkin_> robclark: but this isn't about rendering vs texturing... it's about "what is the format of the renderbuffer for the purpose of image copy format equivalence"
17:46 #dri-devel: < robclark> "the formats are considered compatible according to the compatibility rules used for texture views as defined in section 3.9.X. In particular, if both internal formats are listed in the same entry of Table 3.X.2, they are considered compatible, or "
17:47 #dri-devel: < robclark> anyways, if they are not compat, then INVALID_OPERATION
17:47 #dri-devel: < imirkin_> perhaps i didn't make the issue clear
17:47 #dri-devel: < robclark> (would be nice if the html man pages actually had hyperlinks to the section/table mentioned)
17:47 #dri-devel: < imirkin_> both the texture and renderbuffer are created with internalformat=GL_RGBA4
17:47 #dri-devel: < robclark> ahh
17:48 #dri-devel: < imirkin_> however the driver internally upgrades the renderbuffer to RGBA8 (or BGRA8, dunno)
17:48 #dri-devel: < imirkin_> but not the texture.
17:48 #dri-devel: < kisak> r600g's num-compilations and num-shaders-created HUD are both broken in mesa git
17:49 #dri-devel: < robclark> imirkin, presumably you are talking about internalFormat=GL_RGBA4? Or can you pass that for format too in desktop gl?
17:49 #dri-devel: < robclark> (and if app asks for a specific internal format, are you supposed to magically up-promote it in the first place)?
17:49 #dri-devel: < imirkin_> robclark: format is unrelated to the format of the image (amusingly enough)
17:49 #dri-devel: < robclark> hmm
17:50 #dri-devel: < imirkin_> robclark: i support texturing RGBA4 but not rendering RGBA4
17:50 #dri-devel: < imirkin_> so if you take that texture and attach it to a fb, the fb becomes incomplete. this is legal.
17:50 #dri-devel: < robclark> right
17:50 #dri-devel: < imirkin_> however with renderbuffers, you're supposed to pick a format you CAN render to
17:50 #dri-devel: < glennk> mannerov, fwiw i tested demoting buffers in heaven to 16 bit but no diff in perf on a turks or cypress
17:50 #dri-devel: < robclark> hmm.. ok..
17:50 #dri-devel: < robclark> idk then
17:52 #dri-devel: < glennk> imirkin_, sb thing should be trivial, but without it it'll likely crash or generate incorrect output
17:52 #dri-devel: < imirkin_> glennk: i thought i got it though... did i miss something else?
17:52 #dri-devel: < mannerov> glennk: gl may be less affected than dX9
17:52 #dri-devel: < imirkin_> glennk: https://patchwork.freedesktop.org/patch/134849/ -- at the end.
17:53 #dri-devel: < mannerov> my understanding is that argb32f is particular slow to sample from on GCN compare to other 64 bits formats
17:53 #dri-devel: < glennk> imirkin_, was that in the first patch you sent to the list?
17:54 #dri-devel: < imirkin_> glennk: yes, since that's the patch that introduces DOT4_IEEE usage
17:54 #dri-devel: < mannerov> gl has a different path and doesn't use argb32f
17:55 #dri-devel: < glennk> imirkin_, weird, now it shows up after refreshing
17:55 #dri-devel: < glennk> imirkin_, looks okay then! feel free to add rb
17:55 #dri-devel: < imirkin_> glennk: ok thanks!
17:55 #dri-devel: < imirkin_> glennk: any thoughts about the RCP/RSQ thing?
17:56 #dri-devel: < imirkin_> my thought is "leave alone for now"
17:56 #dri-devel: < glennk> i think that one blows up apps if you start generating NaNs
17:57 #dri-devel: < glennk> common for instance for lighting to feed in negative values and expect 0 out
17:58 #dri-devel: < imirkin_> so... how does it work on si and i965 and the others?
17:59 #dri-devel: < glennk> kisak, i don't think those counters have ever been wired up to r600g?
18:00 #dri-devel: < glennk> mannerov, i think on eg the bottleneck simply was elsewhere, from memory it was rasterizer
18:01 #dri-devel: < glennk> don't remember if heaven uses stencil much, if it does HiS support would probably have a bigger effect
19:06 #dri-devel: < mattst88> https://www.khronos.org/news/press/khronos-open-sources-opengl-and-opengl-es-conformance-tests
19:06 #dri-devel: < mattst88> woo
19:13 #dri-devel: < nha> mattst88, fyi, there's a part of the CTS which isn't open-source (some licensing issue afaik), but anyway, this is indeed a very welcome move :)
19:13 #dri-devel: < mattst88> yeah, old SGI code IIRC
19:15 #dri-devel: < HdkR> That code probably just needs to burn in a fire anyway? :)
19:15 #dri-devel: < jekstrand> HdkR: Yes
19:16 #dri-devel: < Plagman> yay finally
19:16 #dri-devel: < nha> well, to be fair, the modern parts of the CTS are pretty meh as well
19:17 #dri-devel: < nha> code files with thousands of lines of over-engineered code
19:17 #dri-devel: < mattst88> meh is probably too kind :)
19:17 #dri-devel: < Kayden> piglit is so much nicer to work with. but, the CTS does at least test multiple visuals and window sizes, etc.
19:17 #dri-devel: < nha> and pretty obviously not written with an eye to actually being useful for understanding failures
19:18 #dri-devel: < mattst88> yep, that's why we've always thought tests by developers for developers is the way to go :)
19:18 #dri-devel: < jekstrand> nha: They're both good and bad. Piglit is way better for simply testing a single thing.
19:19 #dri-devel: < jekstrand> nha: However, if you want something to test depth/stencil ops with piles of different combinations of settings, their framework is pretty good.
19:19 #dri-devel: < Plagman> mattst88: that's why member companies should contribute more to cts and infrastructure
19:19 #dri-devel: < jekstrand> nha: They also have a way better utilities core for doing format conversions and things of th elike.
19:19 #dri-devel: < mattst88> yep
19:19 #dri-devel: < Plagman> bidding it out to random folks won't do much good
19:19 #dri-devel: < nha> jekstrand, that's true
19:21 #dri-devel: < jekstrand> The dEQP core is pretty fantastic in terms of what it's capable of doing. Not a huge fan of the APIs they've chosen but it is powerful.
19:49 #dri-devel: < imirkin_> nha: thanks a lot for testing my patches on r600
19:54 #dri-devel: < nha> imirkin_, np, I happen to have the card in one of my systems right now, so...
19:54 #dri-devel: < nha> btw, I agree with the fix/feature thing, but _in practice_, reversing the order of patches might avoid some confusion if somebody bisects a nine issue
19:55 #dri-devel: < jekstrand> imirkin_: ping recieved. :-)
19:55 #dri-devel: < imirkin_> jekstrand: hehe, you said you almost started reviewing it last time...
19:55 #dri-devel: < imirkin_> is it really that bad of a change?
19:56 #dri-devel: < imirkin_> nha: well, that's fine - i can flip them i guess. the bisect argument isn't a bad one...
20:04 #dri-devel: < jekstrand> imirkin_: No, reviewing just requires that I swap all of the query stuff back in.
20:04 #dri-devel: < jekstrand> imirkin_: That's not my most familiar part of the driver.
20:18 #dri-devel: < bwidawsk> robclark: http://sprunge.us/jaXU
20:24 #dri-devel: < danvet> is eric engestrom here?
20:24 #dri-devel: < danvet> seems like he needs a wiki account ...
20:29 #dri-devel: < robclark> bwidawsk, not 100% sure about the of anon structs in uabi.. but other than that lgtm..
20:30 #dri-devel: * bwidawsk likes anonymous structs
20:30 #dri-devel: < bwidawsk> but yeah, I hear you
20:30 #dri-devel: < bwidawsk> I'll remove it
20:30 #dri-devel: < nha> now let's see about int64 on gallium...
20:33 #dri-devel: < robclark> bwidawsk, doesn't hurt to double check with, for ex, danvet.. I could be wrong about that from uapi standpoint..
20:33 #dri-devel: < bwidawsk> I don't care enough
20:34 #dri-devel: < bwidawsk> and it's certainly not commonm
20:34 #dri-devel: < robclark> but yeah, in non uabi code I like anon structs and even unions sometimes.. sometimes just to confuse myself..
21:04 #dri-devel: < nha> I've rebased the int64 patches, they're here: https://cgit.freedesktop.org/~nh/mesa/commit/?h=ARB_gpu_shader_int64
21:05 #dri-devel: < nha> piglit passes on radeonsi, but there are some parts of the main glsl_to_tgsi patch that I want to go over
21:05 #dri-devel: < nha> not today though
21:05 #dri-devel: < narann> Hi guys! I was wondering: Will the OpenGL conformance test be used by mesa devs in the future? https://github.com/KhronosGroup/VK-GL-CTS
21:06 #dri-devel: <+airlied> yeah I find not eating before glsl_to_tgsi work a good plan :-P
21:06 #dri-devel: <+airlied> narann: it's been used by mesa devs in the past while closed source
21:06 #dri-devel: < narann> airlied: thanks for the information
21:07 #dri-devel: <+airlied> nha: I'm assuming the 2->64 conversions :)
21:08 #dri-devel: * Kayden might be running several instances of the CTS now...
21:09 #dri-devel: < nha> yeah
21:10 #dri-devel: <+airlied> code I read and wonder how I wrote it :-P
21:10 #dri-devel: < mattst88> narann: we use it already. :)
21:10 #dri-devel: < mattst88> since before it was public :)
21:10 #dri-devel: < narann> Thats a good news! Thanks!
21:11 #dri-devel: <+airlied> ah I suppose it makes sense when I reread it
21:14 #dri-devel: <+anholt> jekstrand: since you clearly looked at the search patch, could you also ack the optimization it was trying to enable? https://patchwork.freedesktop.org/patch/133987/
21:20 #dri-devel: < fredrikh> i wonder if it would be a bad idea to hook the vulkan VBLANK counter directly up to drmWaitVBlank
 

Written by Christoph Brill © 2007-2017

Valid XHTML 1.0 Transitional

Available in Android Market