IRC Logs of #dri-devel on for 2014-07-28

Choose date

00:03 #dri-devel: < RAOF> vignesh: Mesa 7.8 is rather old; any particular reason you're using it?
00:05 #dri-devel: < vignesh> RAOF, I'm using it for some experiments for some customer specific requirements
02:26 #dri-devel: < vignesh> In mesa/src/mesa/main/extesnions.c. What does On and OFF means in
02:26 #dri-devel: < vignesh> static const struct {
02:26 #dri-devel: < vignesh> GLboolean enabled;
02:26 #dri-devel: < vignesh> const char *name;
02:26 #dri-devel: < vignesh> int flag_offset;
02:26 #dri-devel: < vignesh> } default_extensions[] = {
02:26 #dri-devel: < vignesh> { OFF, "GL_ARB_depth_clamp", F(ARB_depth_clamp) },
02:26 #dri-devel: < vignesh> { ON, "GL_ARB_draw_buffers", F(ARB_draw_buffers) },
02:26 #dri-devel: < vignesh> Thanks
08:31 #dri-devel: < vsyrjala> ugh. NV12MT has finally come back to haunt me. only took a few years. i think i'll just ignore it and hope it goes away
08:35 #dri-devel: < dvdhrm> danvet, should we allow DRM_IOCTL_DUMB_CREATE on render-nodes? Currently, there is no way to allocate scan-out buffers on render-nodes.
08:36 #dri-devel: < dvdhrm> For intel, normal buffers might work. But at least on radeon, buffers created on render-nodes might not be available for scan-out on other GPUs.
08:36 #dri-devel: < danvet> dvdhrm, dumb create is only for dumb kms clients
08:36 #dri-devel: < danvet> i.e. without modeset ioctl it doesn't make sense
08:37 #dri-devel: < dvdhrm> danvet, I know. But for instance on wayland a client might provide a full-screen surface which the compositor can use for direct scanout
08:37 #dri-devel: < danvet> anyone who uses for anything else than that can get his ticket to receive airlied's wrath ;-)
08:37 #dri-devel: < dvdhrm> by-passing the compositing-step
08:37 #dri-devel: < danvet> dvdhrm, well drivers should somehow expose a means to allocate frontbuffer-capable stuff
08:37 #dri-devel: < dvdhrm> yeah, this currently is what DUMB_CREATE does :p
08:37 #dri-devel: < danvet> dumb (at least on i915) is completely unusable for anything where you actually care about perf
08:38 #dri-devel: < danvet> it's even not a really good option for uploading to the gpu
08:38 #dri-devel: < dvdhrm> danvet, even as compositing target?
08:39 #dri-devel: < danvet> with restrictions
08:39 #dri-devel: < dvdhrm> Then I think we need to extend gbm_surface_create() to take flags that mark buffers as frontbuffer-capable.
08:39 #dri-devel: < danvet> we actually prefer x-tiled if you care
08:39 #dri-devel: < danvet> e.g. fbc doesn't work without x-tiled
08:39 #dri-devel: < dvdhrm> fbc? x-tiled? ok, hw-features..
08:40 #dri-devel: < dvdhrm> we need ION, hmm
08:41 #dri-devel: < agd5f> dvdhrm, yeah, we need tiled buffers as well for optimal performance
08:42 #dri-devel: < dvdhrm> anyone working on a cross-device allocator?
08:43 #dri-devel: < glisse> ION is utter crap and this is an understatement
08:43 #dri-devel: < dvdhrm> glisse, I know, I rather meant "something solving the same problem"
08:44 #dri-devel: < dvdhrm> Something like DRM_IOCTL_BUFFER_NEW returning a dma-buf, then calling DRM_IOCTL_BUFFER_ATTACH on each DRM device you wanna import the buffer, and then DRM_IOCTL_BUFFER_ALLOCATE to allocate the backing buffer compatible to all attached devices.
08:44 #dri-devel: < glisse> there is no way to solve this, each GPU have so much different tiling pattern and memory restriction that this is a pointless exercice
08:45 #dri-devel: < glisse> for instance on AMD hardware same gpu with different memory configuration leads to different tiling pattern
08:45 #dri-devel: < dvdhrm> glisse, if we don't solve this, cross-device buffer sharing is dead?
08:46 #dri-devel: < glisse> and what is the point of sharing buffer in first place ?
08:46 #dri-devel: < danvet> dvdhrm, there is rumours of a standardized tiling layout using 64kb tiles
08:46 #dri-devel: < dvdhrm> glisse, udl and friends
08:46 #dri-devel: < glisse> buffer sharing is useful in soc but on desktop i do not see any use
08:46 #dri-devel: < danvet> I haven't heard yet that it will take off
08:46 #dri-devel: < danvet> without that cross driver sharing either means linear and you get to suck it up
08:46 #dri-devel: < danvet> or not-quite-zero copy
08:47 #dri-devel: < dvdhrm> glisse, udl is no use?
08:47 #dri-devel: < danvet> well that copies
08:47 #dri-devel: < danvet> with the cpu even
08:47 #dri-devel: < glisse> udl is a corner case
08:47 #dri-devel: < dvdhrm> yeah, I'm fine with killing performance. I just want a way to share buffers that works
08:47 #dri-devel: < glisse> it is less that 1% of an operating system that is already in the 1% market share
08:48 #dri-devel: < jcristau> if you're ok with killing performance you can just copy :)
08:48 #dri-devel: < dvdhrm> jcristau, you cant. There's no way to read it out..
08:48 #dri-devel: < dvdhrm> at least no generic way
08:49 #dri-devel: < danvet> jcristau, if you do anything like sampling
08:49 #dri-devel: < danvet> copy to tiled beats 0-copy
08:49 #dri-devel: < danvet> if you can't agree on a tiling layout somehow
08:51 #dri-devel: < dvdhrm> danvet, but that's why I asked for DUMB_CREATE. I think it's a nice ioctl to create a linear dumb buffer that works fine for software rendering and sharing. A fall-back for all corner-cases.
09:24 #dri-devel: < pq> so how's Optimus and similar fitting to this?
10:12 #dri-devel: < mareko> stringfellow: hi, wine doesn't contain PCI IDs for Sea Islands Radeon GPUs, it also doesn't support VRAM size >= 4096 MB, because the type where the size is stored is uint (32 bits)
10:13 #dri-devel: < stringfellow> mareko: yeah
10:13 #dri-devel: < stringfellow> adding the PCI IDs should be easy, but I just haven't gotten around to it
10:13 #dri-devel: < stringfellow> I guess nobody else did either
10:15 #dri-devel: < mareko> the default size - 64 MB - doesn't work for StarCraft 2, it needs a lot more just to show the main menu
10:16 #dri-devel: < stringfellow> yeah
10:16 #dri-devel: < DrNick> wine has a table of VRAM sizes?
10:16 #dri-devel: < stringfellow> although I think you're supposed to get a better fallback than that
10:16 #dri-devel: < stringfellow> DrNick: yeah, it's terrible, but well
10:16 #dri-devel: < DrNick> if only there were some kind of OpenGL extension that reported that information
10:16 #dri-devel: < DrNick> or two even!
10:16 #dri-devel: < stringfellow> ideally we'd like to use query_renderer instead
10:19 #dri-devel: < stringfellow> mareko: wrt. VRAM >= 4GB, you wouldn't happen to know what that reports on Windows by any chance in d3d9?
10:19 #dri-devel: < stringfellow> GetAvailableTextureMem() returns a UINT, so yeah
10:20 #dri-devel: < stringfellow> I'd guess it's just capped to 4GB
10:21 #dri-devel: < HdkR> Nobody needs more than 4GB of VRAM, trololol
10:21 #dri-devel: < DrNick> hey, it was 32-bit Windows, nobody needed more than 4 GB of RAM either
10:21 #dri-devel: < HdkR> hehe
10:21 #dri-devel: < mareko> stringfellow: sorry no, my windows doesn't boot since I changed my motherboard/etc
10:23 #dri-devel: < stringfellow> (fwiw, dxgi has vram size as SIZE_T, which is 64-bit for 64-bit processes at least, but also only 32-bit for 32-bit processes)
10:29 #dri-devel: < stringfellow> I pretty much won't have time to do anything about it this week
10:29 #dri-devel: < stringfellow> possibly next week
12:24 #dri-devel: < danvet> dvdhrm, I concur on just ignoring is_master races
12:24 #dri-devel: < danvet> not worth the trouble and not that critical really
12:24 #dri-devel: < dvdhrm> danvet, ok, fine with me.
12:49 #dri-devel: < EdB> curro____: Hello
12:58 #dri-devel: < okias> tstellar: hey, should be in s/asset/assert/ ?
13:07 #dri-devel: < tstellar> okias: Oops, thanks.
13:12 #dri-devel: < okias> np
13:21 #dri-devel: < tfiga> robclark: would you find dummy implementation of freedreno libdrm API useful?
13:21 #dri-devel: < tfiga> e.g. code that implements dummy BOs in user memory and forwards command streams to some debug output
13:21 #dri-devel: < robclark> you mean like a no-op implementation?
13:21 #dri-devel: < robclark> ahh
13:21 #dri-devel: < robclark> I suppose
13:22 #dri-devel: < tfiga> I'm working on something like this right now and though that you might find it useful as well
13:22 #dri-devel: < robclark> I guess it could be interesting to wire it up to somehow generate .rd files that cffdump can grok..
13:22 #dri-devel: < tfiga> my target systems are quite slow and testing could be done much faster on fast hosts...
13:22 #dri-devel: < robclark> I've started adding scripting to my parsing tool.. the immediate purpose is to automate some of the a4xx r/e, but one other thought I had was a sort of command-stream error checker..
13:23 #dri-devel: < robclark> that plus no-op backend means I could debug some things on my laptop :-P
13:23 #dri-devel: < tfiga> yep, that's the goal
13:24 #dri-devel: < robclark> I could see that being useful
13:24 #dri-devel: < tfiga> I kind of reused your freedreno libdrm API without any significant changes so it might just work for you too
13:24 #dri-devel: < tfiga> although I may need to rebase it on something more current as I had a little break in the works
13:24 #dri-devel: < robclark> ok.. not super urgent but let me know where the code ends up and some day I might copy it
13:25 #dri-devel: < robclark> and wire up the bits to spit out cffdump files
13:25 #dri-devel: < tfiga> most likely in some branch over there:
13:25 #dri-devel: < robclark> cool, thx
13:25 #dri-devel: < tfiga> but it's not there yet
13:25 #dri-devel: < tfiga> will do a bit of testing first :)
13:25 #dri-devel: < robclark> ok, no hurries.. I'm more in r/e mode right now anyways
13:26 #dri-devel: < tfiga> hopefully this will be a bit more useful than for a 5 years old GPU that nobody uses anymore
13:31 #dri-devel: < glennk> FIMG-3DSE, now thats a "gpu" i hope never to meet again :-)
13:49 #dri-devel: < tfiga> glennk: well, it's very specific, I'd say
13:50 #dri-devel: < tfiga> I believe it can be usable with right software, but it's not easy to work with
13:51 #dri-devel: < glennk> i remember it being slightly slower than pure software rasterization on the devices that had it
13:52 #dri-devel: < tfiga> it shipped with really bad software
13:53 #dri-devel: < tfiga> the whole graphics stack provided by the vendor was flawed in almost every aspect
13:55 #dri-devel: < tfiga> although there are certain things in design of this hw that make me wonder who made it
13:55 #dri-devel: < tfiga> "why the hell we need a command stream processor if we have an ARM core?"
13:55 #dri-devel: < glennk> heh, that was one of the major flaws
13:56 #dri-devel: < glennk> though you can partially get around that using an arm dma engine
13:56 #dri-devel: < tfiga> in my code I do heavy batching and even caching of batches prepared to be send directly to small vertex memory
14:14 #dri-devel: < robclark> tfiga, you should come to XDC2014, maybe even present about your driver ;-)
14:14 #dri-devel: < tfiga> robclark: well, if you wanna some laugh, then probably yes ;)
14:15 #dri-devel: < tfiga> I already see the title of the presentation: "how to develop for retarded hardware"
14:15 #dri-devel: < robclark> well, I always think making hw do things it wasn't supposed to do is fun :-P
14:15 #dri-devel: < robclark> heheh
15:33 #dri-devel: < tfiga> robclark: heh, it builds and links fine, but now I need to somehow trick EGL to work without DRM device
15:34 #dri-devel: < tfiga> I guess I'll call it a day at this point
15:35 #dri-devel: < tfiga> pushed whatever I have to my repo
15:43 #dri-devel: < robclark> cool
18:48 #dri-devel: <+MrCooper> dvdhrm: doesn't GBM_BO_USE_SCANOUT apply to surfaces?

Written by Christoph Brill © 2007-2014

Valid XHTML 1.0 Transitional

Available in Android Market