IRC Logs of #dri-devel on irc.freenode.net for 2014-09-16


Previous dayChoose dateNext day Show menu

01:34 #dri-devel: < Chewi> austriancoder: thanks for your work on etnaviv. I'm trying to get it going on a Utilite Pro under Gentoo. I've created/extended packages for libetnaviv, libdrm and mesa. I think I'm close but I'm getting conflicts between headers, such as viv_features_word in viv.h. any advice would be appreciated.
05:31 #dri-devel: < Chewi> austriancoder: think I see the problem now, trying to mix different branches targeting different approaches, i.e. fbdev vs drm
05:32 #dri-devel: < Chewi> austriancoder: I'm guessing the drm backend needs the drm kernel driver from staging as opposed to the older fbdev driver. unfortunately the former doesn't detect my HDMI screen.
09:26 #dri-devel: < degasus> does any of the current gpus support to fetch the dimension of the overdrawn area? I'd like to get the min/max of all drawn x/y pixels. I guess this could be a nice improvment for some swapping magic (eg Xephyr)
09:27 #dri-devel: < imirkin_> like a bounding box of all rasterized pixels?
09:28 #dri-devel: < degasus> yes
09:30 #dri-devel: < glennk> the quick answer is no, they don't, and you probably don't want the latency of reading back the query results
09:31 #dri-devel: < degasus> glennk: of course I'd have use them in the next shader stage ;)
09:31 #dri-devel: < glennk> the slightly more elaborate answer is you can compute min/max in the pixel shader and update some atomic variables with those values, but its slows rasterization down
09:31 #dri-devel: < glennk> or you could hack your geometry up in to tiles and use occlusion queries on them
09:32 #dri-devel: < glennk> but at that point, just compute the areas on the cpu, its trivial and costs less watts than having the gpu do it
09:34 #dri-devel: < degasus> yeah, I've also thought about atomics, but as atomicMax/Min returns the current value, they likely aren't implemented in a hierarchic way. I guess there won't be much overhead if the gpu computes the min/max per execution engine and only flush them at the end of the draw call
09:38 #dri-devel: < glennk> the overhead of computing that will probably be higher than just having the gpu blit the entire buffer every frame
11:07 #dri-devel: < mareko> I think I'm going to remove GALLIUM_MSAA
11:08 #dri-devel: < imirkin_> what was the purpose behind it?
11:28 #dri-devel: < glennk> mareko, isn't that option redundant with __GL_FSAA_MODE ?
11:28 #dri-devel: < fredrikh> forcing an msaa visual?
11:34 #dri-devel: < jackdaniel> w/in 13
11:45 #dri-devel: < mareko> glennk: that too
11:46 #dri-devel: < mareko> imirkin_: forcing an MSAA visual
11:46 #dri-devel: < imirkin_> mareko: heh... right. but, higher-level than that?
11:46 #dri-devel: < glennk> well, not just forcing the visual, but also force enabling actual MS on it
11:46 #dri-devel: < mareko> imirkin_: it doesn't do anything else
11:46 #dri-devel: < imirkin_> i.e. what would using a MSAA visual get you?
11:46 #dri-devel: < mareko> MSAA?
11:46 #dri-devel: < imirkin_> s/using/forcing/
11:47 #dri-devel: < glennk> for apps that don't know about msaa you can use it to get msaa on them
11:47 #dri-devel: < glennk> like older games
11:47 #dri-devel: < mareko> for apps that do use MSAA, you can use it to break MSAA on them
11:48 #dri-devel: < imirkin_> does it force everything to be multi-sampled, or just the "frontbuffer"?
11:48 #dri-devel: < glennk> should be just the main app back buffer
11:49 #dri-devel: < mareko> imirkin_: FRONT, BACK, and DB
11:49 #dri-devel: < glennk> mareko, the smart thing to do would be disable the effect of the variable if an app enables msaa itself
11:49 #dri-devel: < imirkin_> but not the various intermediate buffers you might create, right?
11:49 #dri-devel: < glennk> front is _never_ msaa :-/
11:50 #dri-devel: < mareko> you can render to front with MSAA directly
11:51 #dri-devel: < mareko> glennk: the problem is MSAA breaks if the app use a FBO and resolves to the back buffer
11:51 #dri-devel: < mareko> *uses
11:51 #dri-devel: < glennk> mareko, yeah, the assumption of the variable is that its only set for apps known to work with it
11:52 #dri-devel: < mareko> so if your back has N samples, FBO has M samples, N>1, M>1, N!=M, you will get this: http://www.phoronix.com/scan.php?page=article&item=amd_radeonsi_msaa
11:55 #dri-devel: < glennk> yeah, nvidia's driver would look like that if you set that variable on an app that did fbo msaa
12:00 #dri-devel: < glennk> mareko, how is the fbo copied to the back buffer?
12:00 #dri-devel: < zgreg> maybe it would be nice to crash/assert in case of illegal blits
12:01 #dri-devel: < zgreg> phoronix will continue to do bad benchmarks, even if you remove GALLIUM_MSAA :)
12:01 #dri-devel: < glennk> normally with a resolve it should work even if nsamples differs - it'll just set all samples to the same value
12:04 #dri-devel: < mareko> glennk: BlitFramebuffer
12:04 #dri-devel: < glennk> i think there are some actual piglit fails for blitframebuffer at least on r600 though
12:05 #dri-devel: < mareko> the fails have nothing to do with this issue
12:06 #dri-devel: < glennk> basically if nsamples differ i think it should be a resolve blit so if the destination is msaa or not shouldn't matter (other than bandwidth wasted)
12:06 #dri-devel: < imirkin_> iirc such blits are disallowed in GL
12:07 #dri-devel: < glennk> yeah, but if the driver allows stuff under the hood like GALLIUM_MSAA you need to do something reasonable for that combo
12:07 #dri-devel: < mareko> imirkin_ is right
12:08 #dri-devel: < imirkin_> you can do 1->N and N->1 and you can do scaled blits N->N (if that blit_scaled extension is enabled), but that's it
12:13 #dri-devel: < glennk> yeah, GL spec 4.5 disallows M != N
12:24 #dri-devel: < glennk> imirkin, i'm not sure i entirely understand what you mean by accessing other invocation's outputs
12:24 #dri-devel: < imirkin_> glennk: if you have a non-patch output, say 'x', it'll be declared as "out int x[]"
12:25 #dri-devel: < imirkin_> you're supposed to write to it with x[gl_InvocationID] = ...
12:25 #dri-devel: < glennk> ok, so this is the no hull shader case?
12:25 #dri-devel: < imirkin_> however you can also read from it, e.g. foo = x[0]
12:25 #dri-devel: < imirkin_> i can never remember which is the hull and which is domain
12:25 #dri-devel: < imirkin_> this is for the tess control shader
12:25 #dri-devel: < glennk> thats the hull shader afaik
12:25 #dri-devel: < imirkin_> the one that gets inputs from vertex shader, outputs to tess eval shader
12:26 #dri-devel: < imirkin_> has patch inputs and outputs (although the output patch size can be different than input patch size)
12:26 #dri-devel: < glennk> outputs to fixed function primitive gen, then to eval shader
12:27 #dri-devel: < imirkin_> http://cgit.freedesktop.org/piglit/tree/tests/spec/arb_tessellation_shader/execution/barrier.shader_test
12:27 #dri-devel: < glennk> the inputs to that stage are buffered by the hardware so everything is available there, and likewise the next stage isn't started until it gets enough outputs
12:29 #dri-devel: < imirkin_> right
12:29 #dri-devel: < glennk> ah, the barrier there is obviously needed to get any sort of valid data for whats been written prior to that
12:29 #dri-devel: < imirkin_> right :)
12:30 #dri-devel: < glennk> one way that could be implemented is running two shader stages after another
12:30 #dri-devel: < imirkin_> i believe D3D11 solves this by have multiple sub-stages
12:30 #dri-devel: < imirkin_> but there's nothing preventing multiple barriers in a single shader in GL
12:31 #dri-devel: < glennk> well, r600 can probably do either, i'm not entirely sure exactly how its stages map to GL yet though
12:31 #dri-devel: < imirkin_> well, with nvc0, there's a barrier instruction which handles all this quite nicely :)
12:31 #dri-devel: < imirkin_> and you can write to shader outputs, and you can read other shaders' outputs using the "load" instruction
12:31 #dri-devel: < glennk> but its inputs/outputs are basically just memory so it can do arbitrary reads/writes, and just use a barrier between
12:31 #dri-devel: < imirkin_> ( + a special flag)
12:32 #dri-devel: < imirkin_> er, other *invocations's* outputs
12:32 #dri-devel: < mareko> glennk: VS->TSC->TES in GL are LS->HS->VS in hw
12:32 #dri-devel: < glennk> the outputs from the eval shader can be fed to a special ring buffer if they are to be consumed by a geometry shader though - in that case reading back the values won't work
12:33 #dri-devel: < glennk> mareko, i think ES pops in there somewhere too
12:35 #dri-devel: < imirkin_> glennk: well, TES only generates one value per invocation and can't read any info from other invocations
12:35 #dri-devel: < imirkin_> s/value/vertex/
12:36 #dri-devel: < imirkin_> and then there's a primitive assembly stage which converts all the vertices into triangles
12:36 #dri-devel: < imirkin_> and feeds them to geometry shader
12:37 #dri-devel: < mareko> glennk: if there's GS, then VS->TCS->TES->GS in GL are LS->HS->ES->GS->VS
12:39 #dri-devel: < glennk> VS being last is really weird, i would expect it to be at the top...
12:42 #dri-devel: < mareko> glennk: LS outputs to LDS, ES outputs to export memory, VS outputs to the rasterizer
12:46 #dri-devel: < mareko> VS is the only shader which can feed the rasterizer
12:49 #dri-devel: < glennk> right
12:50 #dri-devel: < mareko> glennk: therefore, API/VS can be bound as VS, ES, and LS; API/TES can be bound as ES and VS
12:52 #dri-devel: < glennk> the GS case can have one more stage in hardware than the api has, for the gather from ring and output to LDS for rasterizer
12:53 #dri-devel: < glennk> and likewise sometimes stages can be merged together in hardware that are separate in api
12:57 #dri-devel: < glennk> imirkin, the control shader should have no problem just reading as memory arrays and doing a barrier between invocations
12:59 #dri-devel: < imirkin_> glennk: yep
12:59 #dri-devel: < glennk> maybe theres a smarter way, but the barrier it can just atomically increment a value, and then wait for that value to become = N
12:59 #dri-devel: < imirkin_> sure. or it can use the built-in functionality provided by the execution engine :)
13:00 #dri-devel: < glennk> not sure radeon has any such hardware for this case
13:00 #dri-devel: < imirkin_> the question isn't about "how oh how can this possibly work". the question is "how should this be represented in TGSI so that the code is reasonable"
13:00 #dri-devel: < mareko> S_BARRIER on SI
13:02 #dri-devel: < imirkin_> the way i already have it implemented is by making 2d outputs first-class concepts that you can write to/etc. however this also introduces a lot of unnecessary nastiness
13:02 #dri-devel: < imirkin_> another approach is to not make it possible to write to 2d outputs, only read from them
13:02 #dri-devel: < mareko> how about using TGSI_OPCODE_BARRIER that already exists in Mesa
13:02 #dri-devel: < imirkin_> which i actually like a little more
13:02 #dri-devel: < imirkin_> for barrier()? sure. my code already does that.
13:03 #dri-devel: < glennk> marcheu, GROUP_BARRIER might be usable on egcm
13:03 #dri-devel: < imirkin_> https://github.com/imirkin/mesa/commit/e4c900b584ee647384393593092a5d446963bc4a
13:03 #dri-devel: < imirkin_> :)
13:04 #dri-devel: < glennk> not sure what constitutes a group for the non-compute case though
13:04 #dri-devel: < mareko> yey :)
13:04 #dri-devel: < mareko> glennk: a patch I think
13:05 #dri-devel: < glennk> in that case, yey :-)
13:05 #dri-devel: < glennk> "emit-and-forget"
13:05 #dri-devel: < imirkin_> the question is just about how to write the TGSI code s.t. it's reasonable and doesn't cause pain all over the codebase
13:05 #dri-devel: < glennk> ...except for having to teach sb all about it :-/
13:06 #dri-devel: < imirkin_> yeah, it's like EMIT -- you can't move things across it
13:06 #dri-devel: < glennk> sb doesn't do that one right yet either
13:06 #dri-devel: < glennk> well, it does on a branch i have on my machine, but not in a clean way
13:06 #dri-devel: < imirkin_> although i suspect barrier isn't nearly as common as EmitVertex
13:07 #dri-devel: < imirkin_> so you could just not use sb if someone uses barrier
13:07 #dri-devel: < glennk> i would expect it to be fairly common in tess shaders for computing differential values
13:07 #dri-devel: < imirkin_> hm, i think chrisf was suggesting it'd be rare. i don't know anything firsthand, as usual :)
13:08 #dri-devel: < imirkin_> but presumably you could well have TCS without barrier, while a GS without EmitVertex is a little more dubious...
13:09 #dri-devel: < glennk> in terms of #times executed certainly rarer
13:11 #dri-devel: < glennk> i guess barrier would work as mem ops, have an implicit dependency inserted between them to serialize their execution
13:11 #dri-devel: < imirkin_> anything that writes outputs, yeah
13:11 #dri-devel: < tstellar> glennk: I think for non-compute 1 group == 1 wave.
13:12 #dri-devel: < imirkin_> and any subsequent reads have to depend on it too so that they don't get moved above it
13:12 #dri-devel: < glennk> reads/writes both all get deps
13:13 #dri-devel: < glennk> tstellar, thats GWS_BARRIER i think
13:13 #dri-devel: < glennk> "Stalls execution until the number of waves indicated by VALUE and VAL_INDEX_MODE are
13:13 #dri-devel: < glennk> waiting on the resource selected by RESOURCE and RES_INDEX_MODE."
13:21 #dri-devel: < tstellar> glennk: My understanding is that GROUP_BARRIER is a sync point for all threads in a wave / group.
13:23 #dri-devel: < tstellar> glennk: This is how we use it for OpenCL.
13:24 #dri-devel: < glennk> per wave is definitely GWS_BARRIER for compute
13:25 #dri-devel: < glennk> per group is GROUP_BARRIER
13:25 #dri-devel: < glennk> question though is what group means for non-compute such as tess control shader
13:27 #dri-devel: < tstellar> glennk: Right, I thought for non-compute 1 group == 1 wave, so you could use GROUP_BARRIER.
13:31 #dri-devel: < glennk> i would think group = primitive
13:32 #dri-devel: < glennk> and wavefront is unchanged, but since the contents of a wavefront are hardware assigned in some arbitrary fashion, that case isn't very useful
13:34 #dri-devel: < glennk> imirkin, i guess any syntax is okay as long as the drivers can quickly get from it to their internal representation and not have to mess further with TGSI :-/
13:37 #dri-devel: < glennk> evergreen has the address register and two index registers which can index the memory read/write ops
13:37 #dri-devel: < glennk> might be one way to express it
13:37 #dri-devel: < imirkin_> yeah... i'm a fan of the pragmatic approach too
13:38 #dri-devel: < imirkin_> but i feel like some people here have an idea of what is the Right Way (tm) and don't feel like having to redo my impl multiple times
13:38 #dri-devel: < glennk> i don't think there is a right way until actual implementations spring into existence :-|
13:41 #dri-devel: < glennk> i think generic 2 dimensional indexing might be the wrong thing for some hardware to implement, if for instance it places instance data in non-adjacent memory locations
13:42 #dri-devel: < glennk> i'm not quite sure how radeons with more than one engine map this...
13:43 #dri-devel: < imirkin_> well, nvc0 can only write to the current invocation's outputs
13:43 #dri-devel: < glennk> i presume each one handles a full invocation independently from the others, with its own private memory regions
13:43 #dri-devel: < imirkin_> (without resorting to crazy hacks like trying to figure out where the backing memory for that stuff is and writing to it "by hand")
13:43 #dri-devel: < glennk> ok, radeon can write anywhere but you only get consistent results if you synchronize explicitly
13:43 #dri-devel: < imirkin_> and even then, it'd probably run into serialization issues
13:45 #dri-devel: < glennk> well, if the shader uses checks for not clobbering other invocations data etc it should work, but thats getting in to esoteric territory
13:46 #dri-devel: < imirkin_> right
13:46 #dri-devel: < imirkin_> it's not the way you're meant to be doing stuff
13:46 #dri-devel: < glennk> ie you can do write (n+1)%N with no problems
13:46 #dri-devel: < imirkin_> at least not on nvc0
13:47 #dri-devel: < imirkin_> but you could probably come up with a protocol to work around it
13:47 #dri-devel: < imirkin_> but... there's no need to :)
13:47 #dri-devel: < glennk> for GS on the other hand radeons cannot read back data from that in any consistent way
13:49 #dri-devel: < glennk> i think i'm more worried about the tgsi two dimensional array vs GL_ARB_arrays_of_arrays
13:51 #dri-devel: < imirkin_> not a thing
14:07 #dri-devel: < imirkin_> glennk: that stuff should all get lowered by the time it hits tgsi
14:09 #dri-devel: < glennk> sure about that? how does that work with strided buffers?
14:09 #dri-devel: < imirkin_> not sure what you're talking about...
14:09 #dri-devel: < imirkin_> but i was under the impression it should all get compressed into a single linear offset
14:13 #dri-devel: < glennk> hmm, uniform blocks as arrays of arrays, not sure what that means for how that gets flattened?
14:14 #dri-devel: < glennk> block selector and then remaining dimensions flattened?
14:14 #dri-devel: < imirkin_> you mean an array-of-array inside a ubo?
14:15 #dri-devel: < imirkin_> i think things have a well-defined width...
14:15 #dri-devel: < glennk> well, inside isn't so much a problem
14:16 #dri-devel: < imirkin_> outside seems like an identical issue...
14:16 #dri-devel: < glennk> well, the indexing of ubos requires using the index register on evergreen
14:16 #dri-devel: < imirkin_> ok..
14:16 #dri-devel: < glennk> similar to indexing a sampler array
14:17 #dri-devel: < imirkin_> but if you have like ubo[5][5]
14:17 #dri-devel: < imirkin_> and then you do ubo[i][j] that can get flattened into i * 5 + j
14:19 #dri-devel: < glennk> well, okay, as long as you get the right ADDR[1] for the indexing expression in TGSI
14:19 #dri-devel: < imirkin_> my point is that by the time it gets to st_glsl_to_tgsi, it should already be ubo[25] and the index will be i*5+j
14:21 #dri-devel: < glennk> okay
14:37 #dri-devel: < glennk> imirkin, would one option for writing just be current invocation uses no array index?
14:37 #dri-devel: < imirkin_> yes
14:37 #dri-devel: < imirkin_> that's my suggestoin #2 iirc
14:37 #dri-devel: < glennk> similar to how color writes are handled
14:37 #dri-devel: < imirkin_> i.e. when you write, you just say OUT[1] or whatever
14:37 #dri-devel: < imirkin_> but when you read, you use OUT[a][1]
14:38 #dri-devel: < glennk> OUT[1] ? not just OUT?
14:38 #dri-devel: < imirkin_> which is a little dodgy, but i think it's the best of both worlds
14:38 #dri-devel: < imirkin_> well, there can be multiple outputs
14:38 #dri-devel: < imirkin_> and they are indexed...
14:38 #dri-devel: < glennk> oh right
14:38 #dri-devel: < imirkin_> and even if there's only one it'd be OUT[0]...
14:38 #dri-devel: < glennk> but yeah, have the current invocation being the implicit one
14:39 #dri-devel: < imirkin_> this gets rid of the need to teach everything about 2d destinations
14:39 #dri-devel: < imirkin_> the only problem is if you have code like
14:39 #dri-devel: < imirkin_> foo[gl_InvocationID] += 1
14:39 #dri-devel: < imirkin_> then it becomes something dumb like
14:39 #dri-devel: < imirkin_> MOV TEMP[0], OUT[ADDR[1].x][0]
14:40 #dri-devel: < imirkin_> ADD OUT[0], TEMP[0], 1
14:40 #dri-devel: < imirkin_> (obviously using shorthand here)
14:40 #dri-devel: < imirkin_> and i think there's a pass that likes to "cache" out's, although iirc i told it to just forget about TCS
14:41 #dri-devel: < glennk> well, i would presume more ADD OUT[gl_InvocationId][0], TEMP[0], 1 for that case
14:41 #dri-devel: < imirkin_> that's suggestoin #1
14:41 #dri-devel: < imirkin_> and i have to teach everything about 2d destinations
14:41 #dri-devel: < imirkin_> suggestion #2 is just OUT[0] in the destination, with the gl_InvocationID implied
14:41 #dri-devel: < glennk> right
14:41 #dri-devel: < imirkin_> and then *way* less stuff has to change
14:42 #dri-devel: < glennk> considering the piles of hacks that is current tgsi
14:42 #dri-devel: < glennk> what is one more straw?
14:42 #dri-devel: < glennk> *creak*
14:42 #dri-devel: < imirkin_> well, i've already written a lot of that support
14:42 #dri-devel: < imirkin_> but it's super-hacky and complicates a bunch of stuff and feels really unnecessary
14:42 #dri-devel: < imirkin_> the benefit seems really dubious
14:43 #dri-devel: < glennk> for #1 you mean?
14:43 #dri-devel: < imirkin_> yes
14:43 #dri-devel: < glennk> i don't particularly like the idea of 2d destinations in r600_shader.c :-|
14:44 #dri-devel: < imirkin_> so... you don't like #1 either
14:44 #dri-devel: < glennk> so i think #2 seems a bit more natural, especially given nvidias restriction on writing
14:44 #dri-devel: < imirkin_> i tend to agree... :)
14:46 #dri-devel: < glennk> radeon just needs to figure out the right memory offset for everything to write into, so i think it always needs the invocation id anyway
14:49 #dri-devel: < imirkin_> hopefully mareko and sroland will agree...
14:49 #dri-devel: < glennk> as far as i know the driver just allocates a gob of memory somewhere (typically GDS on chip memory) large enough to hold output values * number of engines, and emits regular memory writes into that
14:51 #dri-devel: < glennk> for the patch shader
15:01 #dri-devel: < robclark> hmm, any ideas why dri2_dpy->image would be null? (or even more specifically, if EGL_EXT_image_dma_buf_import is implemented for anything more than intel?)
15:02 #dri-devel: <+airlied> I thought we did gallium support for it
15:02 #dri-devel: < robclark> I assume I don't need to be using the gallium-egl for this?
15:02 #dri-devel: * robclark a bit lost in all the egl's
15:02 #dri-devel: <+airlied> no its part of dri2
15:03 #dri-devel: < robclark> looks like dri2_dpy->image is used for all eglimageexternal..
15:03 #dri-devel: < robclark> hmm
15:04 #dri-devel: <+airlied> do you see the esxtension in eglinfo?
15:04 #dri-devel: < robclark> I guess I need to actually build eglinfo..
15:05 #dri-devel: < robclark> or do we have that packaged somewhere..
15:05 #dri-devel: < Kayden> or wflinfo
15:05 #dri-devel: < robclark> nope, don't seem to have that either..
15:05 #dri-devel: < Kayden> ah, I guess that doesn't print extension lists yet.
15:05 #dri-devel: < robclark> that's all in mesa-demos, isn't it?
15:05 #dri-devel: < imirkin_> iirc it does... at least new versions do
15:09 #dri-devel: <+airlied> robclark: what egl platform?
15:09 #dri-devel: < robclark> I'm not --enable-gallium-egl..
15:09 #dri-devel: < robclark> so should be the other egl
15:10 #dri-devel: < robclark> src/egl/drivers/dri2/egl_dri2.c
15:10 #dri-devel: <+airlied> no I mean gbm/wayland/etc
15:10 #dri-devel: < robclark> x11
15:10 #dri-devel: < xexaxo> --with-egl-platforms :)
15:10 #dri-devel: < robclark> using: --with-egl-platforms=x11,drm
15:12 #dri-devel: < xexaxo> robclark: using 10.3 or later ?
15:12 #dri-devel: < robclark> master
15:19 #dri-devel: <+airlied> robclark: it shouldn't be that hard to trace
15:19 #dri-devel: <+airlied> platform_x11.c and the egl dri2 stuff
15:20 #dri-devel: < robclark> just building debug mesa and demo's..
15:21 #dri-devel: < xexaxo> robclark: afaics you should never get that far. i.e. platform_x11 find the dri2 extension
15:21 #dri-devel: < xexaxo> then jumps into the core egl_dri2 and gets the image extension. if it fails it just bails out
15:22 #dri-devel: < robclark> apparently theory differs from reality slightly :-P
15:23 #dri-devel: < robclark> anyways, if everyone thinks it *should* work then I'll dig through it.. I just figured I should make sure it wasn't something that no one ever bothered to implement..
15:24 #dri-devel: < imirkin_> anholt`: you shouldn't need ARB_fbo for GL2.1... it's part of GL3.
15:24 #dri-devel: <+airlied> I'm nearly sure I wrote code for it once :)
15:24 #dri-devel: < imirkin_> anholt`: (this is re your recent vc4 commits)
15:25 #dri-devel: < xexaxo> robclark: up-to mesa 10.3 only the intel dri driver had support for the image extension. with 10.3 and later pretty much every gallium driver has it.
15:25 #dri-devel: < xexaxo> robclark: I'm guessing that it's either picking up the wrong dri module, or something very nasty is happening :]
15:26 #dri-devel: < robclark> hmm..
15:26 #dri-devel: <+airlied> robclark: your kernel driver does have prime support :)
15:28 #dri-devel: <+anholt> imirkin: state_tracker insists on it.
15:29 #dri-devel: <+anholt> I've still got outstanding patches for deleting awful things in state_tracker, and I wanted to stop carrying that workaround in all my branches.
15:29 #dri-devel: < imirkin_> anholt: hmmm... didn't use to =/
15:29 #dri-devel: < robclark> airlied, yup.. I did realize I never bothered to add helpers for libdrm_freedreno (but I have that locally now)..
15:29 #dri-devel: < imirkin_> anholt: nv4x's also don't have mixed fb support (or ARB_fbo) but claim GL2.1 just fine...
15:31 #dri-devel: < robclark> xexaxo, hmm, looks like I have the correct dri2_create_image_dma_buf() (from my local / recent-master mesa build).. not sure if somehow there is something hanging around from slightly older distro build (but it is rawhide, so shouldn't be too ancient)
15:35 #dri-devel: < robclark> hmm, does look like I miss the dmabuf extension.. http://paste.fedoraproject.org/134067/41090686
15:37 #dri-devel: < xexaxo> robclark: looking into the function, if dri2_dpy->image is null we're in deep sh*t. you're missing the prime bits then createImageFromDmaBufs is null then... we need a one-liner for it thus EXT_image_dma_buf_import is not advertised
15:38 #dri-devel: < xexaxo> that last part should be "if you're missing the prime bits then createImageFromDmaBufs is null thus EXT_image_dma_buf_import is not advertised"
15:39 #dri-devel: < robclark> xexaxo, http://hastebin.com/raw/buzisihadi
15:39 #dri-devel: < robclark> image is null.. and yes, that looks a bit frightening..
15:41 #dri-devel: < robclark> actually a fair bit of that looks a bit unitialized
15:42 #dri-devel: < robclark> hmm..
15:42 #dri-devel: < robclark> libEGL warning: Could not open driver /usr/lib/egl/egl_gallium.so (/usr/lib/egl/egl_gallium.so: undefined symbol: _glapi_tls_Dispatch)
15:43 #dri-devel: < robclark> hmm, but that might not matter..
15:44 #dri-devel: < xexaxo> yet I cannot see how even that one can happen.
15:45 #dri-devel: < xexaxo> we already have beat some sense into the linker to scream when we produce such libraries :\
15:46 #dri-devel: < xexaxo> unless your (build) system does not support -Wl,--no-undefined
15:46 #dri-devel: * robclark assumes it should..
15:47 #dri-devel: < xexaxo> apart from the uninitialized members there are quite a few pointers set to 0x1 which looks very bad
15:48 #dri-devel: < robclark> hmm, wtf.. it seems to find DRI_IMAGE ... http://hastebin.com/raw/uvonanukad
15:53 #dri-devel: < xexaxo> the gdb printf seems to disagree though... if valgrind comes out silent I'm out of ideas
15:55 #dri-devel: < robclark> oh, that gdb cast is bogus..
15:55 #dri-devel: < robclark> stoopid retarded macro hell
15:59 #dri-devel: < robclark> ok, image is fine.. just createImageFromDmaBufs is null..
16:01 #dri-devel: <+airlied> robclark: --enable-glx-tls for that
16:01 #dri-devel: <+airlied> otherwise you are using the distro egl libs with driver without that
16:02 #dri-devel: < robclark> hmm.. wouldn't 'make install' overwrite them?
16:02 #dri-devel: <+airlied> depends on how you configured things
16:02 #dri-devel: * airlied never uses make install so wouln't know
16:03 #dri-devel: < robclark> well... --prefix=/usr ;-)
16:03 #dri-devel: <+airlied> and --libdir? :)
16:04 #dri-devel: < robclark> don't give it
16:04 #dri-devel: < robclark> so whatever is default..
16:04 #dri-devel: < robclark> anyways, I think that wasn't the problem..
16:05 #dri-devel: <+airlied> oh you are 32-bit anyways
16:05 #dri-devel: < robclark> I don't build egl_gallium, so still had the distro version of that
16:05 #dri-devel: < robclark> yeah
16:05 #dri-devel: < xexaxo> what was fedora/rh stance the lib vs lib32 vs lib64 topic - lib64 for native 64bit libs, and lib for multilib (32bit) ones ?
16:05 #dri-devel: <+airlied> xexaxo: pretty much
16:05 #dri-devel: < robclark> just tracing through dri2_init_screen() to see how it decides if I have dmabuf..
16:05 #dri-devel: <+airlied> it asks the kernel
16:05 #dri-devel: < glennk> is there any 64 bit arm with adreno out yet?
16:06 #dri-devel: < xexaxo> robclark: it goes through the kernel. check src/gallium/state_tracker/dri2.c
16:06 #dri-devel: <+airlied> calls drmGetCap
16:06 #dri-devel: <+airlied> and that just checks the kernel funcs are connected up
16:06 #dri-devel: < robclark> hmm,
16:06 #dri-devel: < robclark> DRM_DRIVER_DESCRIPTOR("msm", "freedreno", create_screen, NULL)
16:06 #dri-devel: < robclark> ok.. maybe because I don't give it a configure fxn?
16:07 #dri-devel: < robclark> yeah, that seems plausible
16:07 #dri-devel: < xexaxo> airlied, robclark: that is only if the target sets DRM_CONF_SHARE_FD
16:07 #dri-devel: < xexaxo> iirc ilo radeon and nouveau do. i915 and everyone else does not
16:08 #dri-devel: <+airlied> robclark: seems most likely
16:09 #dri-devel: < robclark> so the next question will shortly be "what happens when I try to pass it multi-planar format" :-P
16:38 #dri-devel: < robclark> ok.. rgb dmabuf egl image working.. turns out there were a few things missing.. approx: http://hastebin.com/akanarohak.pl
18:09 #dri-devel: <+airlied> pinchartl, tagr, robclark : that atmel hlcdc stuff, any opinions etc, esp the panel precusor bits
18:11 #dri-devel: < robclark> hmm, I suppose I need to make some time to look at the last round..
18:16 #dri-devel: <+airlied> we also have the rockchip driver I think
18:18 #dri-devel: * airlied suggets a cross review
18:26 #dri-devel: < robclark> someone probably needs to bug me.. preferably next week when I have more time, to remind me to look at 'em..
 

Written by Christoph Brill © 2007-2014

Valid XHTML 1.0 Transitional

Available in Android Market