IRC Logs of #dri-devel on for 2015-05-26

Previous dayChoose dateNext day Show menu

00:09 #dri-devel: < danvet> daniels, where do we warn in i915 without this?
00:46 #dri-devel: < daniels> danvet: warn in core atomic_crtc_check, but gated on DRIVER_ATOMIC
00:49 #dri-devel: < danvet> daniels, well that only happens if you call the atomic ioctl
00:49 #dri-devel: < danvet> which we can't on i915
00:49 #dri-devel: < danvet> can you pls resend patch 2 with the i915 parts dropped?
00:49 #dri-devel: < danvet> just to avoid conflicts with all the other in-flight stuff
00:49 #dri-devel: < danvet> maybe throw your patch at mlankhorst rebased on top of his pile ...
00:49 #dri-devel: < danvet> (the i915 parts I mean)
01:07 #dri-devel: < daniels> danvet: sure, just on my way in now
01:07 #dri-devel: < zgreg> does anyone know if there is a method determine the SIMD width in mesa/gallium?
01:08 #dri-devel: < zgreg> I couldn't find anything like it
01:08 #dri-devel: < zgreg> SIMD width as in warp/wavefront size
01:08 #dri-devel: < daniels> danvet: throw it at maarten for prts or just review?
01:11 #dri-devel: < danvet> daniels, fyi&review
01:14 #dri-devel: <+MrCooper> zgreg: maybe one of the PIPE_COMPUTE_CAP_* caps?
01:14 #dri-devel: < zgreg> nope
01:14 #dri-devel: < zgreg> guess I'll add one then
01:14 #dri-devel: < daniels> danvet: ack
01:15 #dri-devel: < zgreg> CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE always returns 1 right now and that's bad, some apps actually use it
01:23 #dri-devel: < pq> btw. was there any fake v4l driver that would support dmabuf export such that they could be imported to EGL?
01:24 #dri-devel: < pq> just thinking of a better test app for Wayland generic dmabuf protocol than an intel-specific one that relies on mmap to draw.
01:31 #dri-devel: < xexaxo> imirkin: that's was my original idea (callback that does the destruction in piglit_report_result) as I added the piglit_display() teardown.
01:34 #dri-devel: < xexaxo> imirkin: using atexit sounds like a nice plan. I have the vague memory that it might not always work as planned on Windows... although that was in the Win 2k/XP era.
01:52 #dri-devel: < daniels> danvet, ickle: speaking of compiler warnings, i still get one about unused dev_priv in i915_gem_mmap_gtt on topic/drm-next
01:52 #dri-devel: < daniels> *topic/drm-fixes
01:55 #dri-devel: < daniels> danvet: also, drm_atomic_crtc_check _is_ called in legacy paths (e.g. restore_fbdev_mode), not just through the ioctl
01:55 #dri-devel: < daniels> danvet: so i can either keep the warnings gated on DRIVER_ATOMIC (i.e. won't trigger unless you have i915.nuclear_pageflip), or just drop them
01:57 #dri-devel: < danvet> daniels, which patch added that caller for drm_atomic_crtc_check?
01:57 #dri-devel: < danvet> my tree here only has one caller in the drm atomic ioctl
01:57 #dri-devel: < danvet> well in drm_atomic_check_only
01:58 #dri-devel: < danvet> and iirc i915 still doesn't use any of the legacy2atomic helpers, so we should be fine ...
02:00 #dri-devel: < daniels> danvet: plane->set_property == drm_atomic_helper_plane_set_property
02:01 #dri-devel: < daniels> danvet: the calltree being restore_fbdev_mode -> (drm_atomic_helper_)plane_set_property -> drm_atomic_commit -> drm_atomic_check_only -> drm_atomic_crtc_check
02:02 #dri-devel: < danvet> yeah that doesn't work too well I guess
02:02 #dri-devel: < danvet> but surely this isn't a new problem introduced by your patches?
02:03 #dri-devel: < danvet> probably need to revert that patch from mattrope, dunno
02:03 #dri-devel: < daniels> danvet: not a new problem, no; but i put warnings in patch 3/4 (gated on DRIVER_ATOMIC) to check that state->enable and state->mode_blob stay in sync
02:04 #dri-devel: < daniels> danvet: since you've screwed your state if you're claiming to be atomic but keep your state internally incoherent
02:04 #dri-devel: < daniels> danvet: so it's going to introduce new WARN_ONs for anyone running with i915.nuclear_pageflip until maarten's branch lands
02:04 #dri-devel: < daniels> danvet: otoh, anyone not running with nuclear_pageflip just carries on as normal
02:05 #dri-devel: < daniels> danvet: i'd argue that anyone using that on any other branch than unify-flip-modeset deserves exactly what they get :P
02:08 #dri-devel: < danvet> hm yeah checking for ->enable and ->mode_blob to be consistent isn't a nice thing to do when transitioning
02:09 #dri-devel: < daniels> danvet: if you set DRIVER_ATOMIC then you're breaking userspace by !!enable != !!mode_blob
02:09 #dri-devel: < danvet> yeah
02:09 #dri-devel: < daniels> danvet: in that getcrtc will report something different than MODE_ID
02:09 #dri-devel: < daniels> danvet: hence why the checks are if (has_feature(DRIVER_ATOMIC) && ...)
02:09 #dri-devel: < danvet> the other thing I wonder about is how the rotation stuff in i915 works
02:10 #dri-devel: < daniels> mmm ... ?
02:10 #dri-devel: < daniels> i haven't looked at that at all
02:16 #dri-devel: < daniels> danvet: trivial plane_helper patch on the list that could go for -misc btw
02:16 #dri-devel: < danvet> well it does, forgot that we decode in the core
02:18 #dri-devel: < daniels> danvet: so is v3 good with all i915 changes dropped, and the crtc_check warnings in 3/4 remaining the same (i.e. only when DRIVER_ATOMIC set)?
02:18 #dri-devel: < danvet> daniels, those aren't helpers but core atomic stuff
02:18 #dri-devel: < danvet> they do the magic ww mutex dance
02:18 #dri-devel: < danvet> which the transitional helpers don't
02:19 #dri-devel: < danvet> they also add the crtc state to the drm_atomic_state
02:19 #dri-devel: < danvet> i.e. I'd wager this will oops
02:20 #dri-devel: < danvet> if a driver needs the plane mask already while transitioning we'd need to open-code this in there somewhere ...
02:20 #dri-devel: < daniels> danvet: hrm, okay - just spotted it by inspection; might deserve a comment as to why it ignores the helper
02:21 #dri-devel: < danvet> that function isn't a helper, its core atomic code
02:21 #dri-devel: < daniels> sure
02:21 #dri-devel: * daniels shrugs
02:21 #dri-devel: < danvet> while the transitional stuff is in limbo-land
02:21 #dri-devel: < danvet> we'd need to splatter them a lot more with various warnings ...
02:22 #dri-devel: < daniels> ok, i'll deal with that later if needed and get back to the other 17 things on my todo ;)
02:22 #dri-devel: < danvet> since the goal is just to be close enough to atomic to allow gradual transition, but it's not really atomic
02:25 #dri-devel: < daniels> yeah, fair enough
02:26 #dri-devel: < daniels> like i said, didn't really turn up any problems, just raised an eyebrow
02:53 #dri-devel: < daniels> mlankhorst: should modeset_update_crtc_power_domains be testing crtc->base.state->active rather than crtc->base.state->enable?
02:57 #dri-devel: < mlankhorst> *looks*
02:57 #dri-devel: < mlankhorst> probably
03:01 #dri-devel: < danvet> MrCooper, wrt vblanks and stuff the trouble iirc was that the counter wraps around like mad
03:01 #dri-devel: < danvet> X has hacks to cope with that
03:02 #dri-devel: < danvet> but generally system suspend/resume should wreak total havoc with state
03:03 #dri-devel: < danvet> we've had similar troubles with runtime pm in i915 too, required saving/restoring the hw state
03:04 #dri-devel: < danvet> well this is for immediate vblank disable
03:04 #dri-devel: < danvet> it "works" if you don't disable immediately and keep vblanks on
03:05 #dri-devel: < danvet> in short my claim is if this works for you you're either really lucky or you're testsuite isn't nasty enough ;-)
04:57 #dri-devel: < danvet> tagr, ping about may patch to check unused planes in addfb2 ...
04:59 #dri-devel: < danvet> daniels, pq: does weston use the ALLOW_MODESET flag btw?
04:59 #dri-devel: < danvet> I mean to make sure that the pageflip really just is a flip ...
04:59 #dri-devel: < daniels> danvet: yeah
04:59 #dri-devel: < danvet> cool
05:11 #dri-devel: < tagr> danvet: heh, yeah, I looked at it twice now I think, but never got around to replying
05:14 #dri-devel: < tagr> danvet: in this current form this prevents using planes that aren't specified by the fourcc (e.g. auxiliary planes)
05:15 #dri-devel: < danvet> yup
05:15 #dri-devel: < danvet> imo we need another flag for those
05:15 #dri-devel: < tagr> I think when we discussed this here a while ago we never reached a conclusion about how exactly to specify the aux planes
05:15 #dri-devel: < danvet> since old userspace _will_ hand you garbage in those fields
05:15 #dri-devel: < danvet> i.e. just looking at aux planes won't ever work
05:15 #dri-devel: < tagr> yeah, but userspace that sets FB_MODIFIERS won't
05:16 #dri-devel: < danvet> hence why I've done this patch, to make this clear
05:16 #dri-devel: < danvet> yeah, but only if we start to enforce this
05:16 #dri-devel: < danvet> if there's no EINVAL you have to assume that sooner or later someone will hand you garbage
05:16 #dri-devel: < danvet> at least ime ;-)
05:17 #dri-devel: < tagr> okay, so you think the plan would be to extend the checks later on and do something like an additional "if (r->flags & DRM_MODE_FB_AUX_PLANES) continue;"?
05:18 #dri-devel: < danvet> slightly different
05:18 #dri-devel: < danvet> or maybe this
05:19 #dri-devel: < danvet> eventually need a num_planes < 4 check too because overflow
05:19 #dri-devel: < tagr> yeah
05:20 #dri-devel: < tagr> we could of course just assume that if FB_MODIFIERS is passed that no garbage will go in, and hence DRM_MODE_AUX_PLANE would mean that auxiliary planes are used, look at the handles to know which
05:20 #dri-devel: < tagr> then there's no need to encode the number and we'd be free to use as many as we want
05:21 #dri-devel: < tagr> well, as man as 3 (for RGB)
05:21 #dri-devel: < tagr> s/man/many/
05:29 #dri-devel: < danvet> tagr, imo "assume ... that no garbage will go in" just doesn't work ;-)
05:29 #dri-devel: < danvet> not at the userspace/kernel boundary at least
05:29 #dri-devel: < tagr> danvet: but with your patch we're already enforcing that no garbage goes in if FB_MODIFIERS is set
05:30 #dri-devel: < tagr> so DRM_MODE_FB_MODIFIER | DRM_MODE_FB_AUX_PLANES should work
05:31 #dri-devel: < danvet> well AUX_PLANES doesn't exist yet, that was kinda just an idea-diff
05:31 #dri-devel: < danvet> I mean I don't follow you ...
05:32 #dri-devel: < tagr> I'm saying that once your patch is merged, specifying DRM_MODE_FB_MODIFIER requires userspace to zero out the IOCTL data
05:32 #dri-devel: < danvet> yup
05:32 #dri-devel: < danvet> that's kinda the point
05:33 #dri-devel: < tagr> so, if we add DRM_MODE_FB_AUX_PLANES, then if DRM_MODE_FB_MODIFIERS is also set (and we could/should make it a requirement that FB_AUX_PLANES requires FB_MODIFIERS), then we know userspace zeroes out unused data, hence non-zero handles would be auxiliary buffers
05:33 #dri-devel: < tagr> then we don't need to assume no. of planes == 1 or encode the number in the flags
05:34 #dri-devel: < pinchartl> where's the mail thread that discusses aux planes ?
05:35 #dri-devel: < danvet> on irc only
05:35 #dri-devel: < pinchartl> that's why I couldn't find it :-)
05:35 #dri-devel: < danvet> tagr, I've seen a few too many i915 addfb patches with lacking input validation to be this optimistic
05:35 #dri-devel: < pinchartl> anything I should contribute to ?
05:35 #dri-devel: < danvet> imo encoding the number of aux planes can't hurt
05:36 #dri-devel: < tagr> danvet: how can you not be optimistic? we already have your code to validate the input
05:36 #dri-devel: < danvet> I'm a grumpy maintainer and only see bugs in patch submissions?
05:37 #dri-devel: < tagr> danvet: all we'd be doing is saying: "alright, the input is sane now, but there might be auxiliary planes"
05:37 #dri-devel: < danvet> e.g. the recent nv12 stuff forgot to check how constraints that both handles should be the same and uv should be after y ...
05:37 #dri-devel: < danvet> oh, I expect someone will do an addfb with rgb+aux and garbage in planes 2&3
05:37 #dri-devel: < danvet> because there's no EINVAL for it
05:38 #dri-devel: < danvet> and you wont be able to catch all users
05:38 #dri-devel: < tagr> you can do the same if the number of planes is encoded
05:38 #dri-devel: < danvet> anyway that's kinda all a bikeshed for aux planes
05:38 #dri-devel: < danvet> my patch as-is ok or not?
05:38 #dri-devel: < tagr> danvet: already replied on list
05:38 #dri-devel: < danvet> not if you ask for 1 aux plane and fill in garbage to the others ...
05:38 #dri-devel: < danvet> ah, sorry ;-)
05:39 #dri-devel: < tagr> but you could easily ask for 2 planes and make both garbage
05:39 #dri-devel: < danvet> yeah, but that's asking for intent
05:39 #dri-devel: < danvet> without that it's just asking for incompetence
05:40 #dri-devel: * danvet still has hopes left
05:40 #dri-devel: < danvet> but yeah, there's not much hope for drivers to check everything, at least judging by i915 patches :(
05:43 #dri-devel: < tagr> hmm... I guess encoding the number would be _slightly_ less error-prone
05:43 #dri-devel: < danvet> daniels, btw should I merge one of the patches to remove unref_blob_locked now?
05:43 #dri-devel: < danvet> looks like it's now no longer used in your latest series ...
05:44 #dri-devel: < danvet> oh well I merged the user already
05:44 #dri-devel: * danvet not on top of things today apparently
05:45 #dri-devel: < tagr> danvet: that reminds me, will gamma lookup tables be handled as binary properties as well? attached to atomic state at modeset/flip time?
05:46 #dri-devel: < tagr> for background: there was some concern that with compression, we're going to run out of the number of planes for planar formats (Y, U, V and compression bits planes)
05:46 #dri-devel: < danvet> tagr, attached to plane/crtc
05:46 #dri-devel: < tagr> and the assumption was that LUTs would go in as planes as well, but last time I checked they are attached to objects as properties, so not part of the FB
05:46 #dri-devel: < danvet> we're working on this actually under the "color management" umbrella
05:46 #dri-devel: < danvet> plan is to expose a pre&post gamma table and color correction matrix in between
05:47 #dri-devel: < danvet> yeah, the existing gamma table will probably be mapped to a post gamma table on the crtc
05:47 #dri-devel: < danvet> not thought much about what the tables should look like besides "let's use a blob for the actual data"
05:48 #dri-devel: < danvet> maybe an enum of common gamma tables&sizes + the table itself
05:48 #dri-devel: < danvet> the current one is rgb888 with 256 entries
05:48 #dri-devel: < tagr> danvet: oh, so you wanted to make this a generic interface?
05:49 #dri-devel: < danvet> well semi-generic property
05:49 #dri-devel: < danvet> kinda like rotation
05:49 #dri-devel: < danvet> we need to support 3 different platforms (i.e. different in major ways) in just i915, so some level of generic I want just for self-preservation ;-)
05:50 #dri-devel: < tagr> as far as I know Tegra would do fine with 256-entry rgb888
05:51 #dri-devel: < tagr> but haven't had much incentive to look at it yet
05:51 #dri-devel: < tagr> in detail
05:59 #dri-devel: < damien_l> we probably can't make it generic, because the details are quite hw specific
06:00 #dri-devel: < damien_l> we have weird configs where the lut changes sizes depending on what we use
06:02 #dri-devel: < imirkin> skeggsb: do you see anything wrong with RT_FORMAT => { COLOR = A8R8G8B8 | ZETA = Z24S8 | TYPE = SWIZZLED | LOG2_WIDTH = 0 | LOG2_HEIGHT = 2 } ? (nv44)
06:02 #dri-devel: < damien_l> would be interesting to know if other hw have similar things: we have a per-plane luts, then after blending, lut + 3x3 matrix + lut
06:02 #dri-devel: < imirkin> oops, wrong chan
06:08 #dri-devel: < glennk> tagr, just curious, but doesn't tegra support rgb10 framebuffers?
06:10 #dri-devel: < pinchartl> when CONFIG_FRAMEBUFFER_CONSOLE is disabled, is the DRM core expected to configure a default KMS pipeline for fbdev compatibility ? I can't get anything on the screen using /dev/fb0 then, but if I first use modetest to configure the pipeline I can then control the device through fbdev
06:12 #dri-devel: < tagr> glennk: I wouldn't know exactly
06:13 #dri-devel: < tagr> glennk: I think some components may support it (like the multimedia blocks), but I don't think the display engine can handle them
06:14 #dri-devel: < tagr> glennk: but given that I work primarily on upstream, I lack understanding of the full feature-set =\
06:15 #dri-devel: < glennk> ok, think the desktop gpus support 30 bit output
06:16 #dri-devel: < tagr> glennk: Tegra display is completely different from desktop GPU display, unfortunately
06:19 #dri-devel: < tagr> damien_l: as far as I can tell Tegra uses per-plane LUT, then LUT + 3x3 + LUT after blending
06:20 #dri-devel: < glennk> 8 bit 3 component lut + 3x3 + 8 bit 3 component lut is basically an icc profile
06:23 #dri-devel: < tagr> I clearly have a serious lack of understanding, are there any good references?
06:25 #dri-devel: < damien_l> tagr: oh interesting! by "specificities" that I hard to expose generically I meant: we can enable one or two of luts around the 3x3 matrix, and because they share the same space to store the values, their max sizes change with how many of them are enabled at once
06:25 #dri-devel: < damien_l> these kind of details may be hard to expose in a generic way
06:26 #dri-devel: < tagr> damien_l: the documentation I'm looking at doesn't say anything specific about the size, unfortunately
06:27 #dri-devel: < damien_l> we also have some kind of gamut expansion unit (for wide gamut displays), no idea how well those ones are standardized
06:34 #dri-devel: < damien_l> tagr: I found useful
06:34 #dri-devel: < damien_l>
06:34 #dri-devel: < glennk> tagr, first couple of pages in the icc spec too
06:35 #dri-devel: < damien_l> "Two basic models can be used in ICC profiles, a Matrix/shaper model and a cLUT (Color Lookup Table) model [...] The Matrix/Shaper model consists of a set of per channel lookup curves followed by a 3x3 matrix."
06:35 #dri-devel: < damien_l> next step is to actually read the ICC spec, of course
06:36 #dri-devel: < glennk> the rgb DeviceLink icc profiles are the interesting ones, can ignore the other types
06:51 #dri-devel: < danvet> damien_l, I think the amount of generic would be that we'd try not to dupe gamma table types if they match exactly
06:51 #dri-devel: < danvet> e.g. the common 8bit 3 component 256 entry one
06:51 #dri-devel: < danvet> and then define a "usual" color correction pipe of pre-gamma/csc/gamma
06:52 #dri-devel: < danvet> and crtc/plane can expose whatever they really support
06:52 #dri-devel: < danvet> maybe for the csc we should try to have a standard, not sure
06:52 #dri-devel: < danvet> since it's little data, converting in the kernel isn't a big problem
06:52 #dri-devel: < danvet> 16.16 fixed point usually isn't a bad choice
06:53 #dri-devel: < glennk> haven't seen very many HDR displays :-(
06:54 #dri-devel: < danvet> daniels, and pulled in \o/
06:54 #dri-devel: < danvet> daniels, btw I'll be on vacation for 2 weeks starting next week
06:54 #dri-devel: < daniels> danvet: !
06:54 #dri-devel: < daniels> danvet: heh
06:54 #dri-devel: < daniels> danvet: ok, i'll keep an eye out for the sky falling ;)
06:54 #dri-devel: < danvet> but I guess if weston gets all into shape you can post the final "enable atomic for real" patch to airlied directly
06:54 #dri-devel: < damien_l> "land patch, go on vacation" :)
06:55 #dri-devel: < daniels> danvet: cool, thanks :)
06:55 #dri-devel: < danvet> damien_l, "send pull request, go on vacation" is the maintainer version ;-)
07:09 #dri-devel: < daniels> :D
07:09 #dri-devel: < daniels> danvet: thanks a lot
08:15 #dri-devel: < robclark> cwabbott_, so what is actually the diff between parallel_copy and just doing a normal mov (like op_vec2/3/4)?
08:20 #dri-devel: < cwabbott_> robclark: just ignore parallel copy
08:20 #dri-devel: < cwabbott_> it's for our fancy out-of-ssa pass
08:21 #dri-devel: < robclark> cwabbott_, well, what started me looking at it was trying to decide where exactly I have to insert mov for loop bodies to deal w/ back edges..
08:21 #dri-devel: < cwabbott_> ah, ok
08:21 #dri-devel: < robclark> so kinda the same problem I guess
08:22 #dri-devel: < cwabbott_> well, if you want, you can sorta think of the parallel copies as being implicit in the phi node
08:22 #dri-devel: < cwabbott_> it's just that it's more convenient for that pass to create them explicitly
08:22 #dri-devel: < robclark> hmm
08:26 #dri-devel: < cwabbott_> for back edges w/ loops though, i'd have a separate pass that runs after register allocation and creates the copies
08:33 #dri-devel: < robclark> cwabbott_, the problem is that it is a royal pita to insert/remove instructions after scheduling.. so basically if I need to insert mov's I need to do it before RA..
08:33 #dri-devel: < robclark> (well, ok.. I can remove instructions and replace 'em w/ nop's but doing anything more is not easy)
08:34 #dri-devel: < cwabbott_> robclark: so at the end of each predecessor block, you're gonna have to emit mov's to rearrange the input block of registers to the registers you've assigned for phi nodes
08:34 #dri-devel: < cwabbott_> robclark: well, maybe you need to make it easier :)
08:35 #dri-devel: < glennk> or use xor to swap values in a pinch
08:35 #dri-devel: < imirkin_> robclark: couldn't you do it after ra but before sched?
08:35 #dri-devel: < cwabbott_> you only need to insert the mov's at the end of a block if that makes it easier
08:35 #dri-devel: < cwabbott_> glennk: well yeah, sometimes xor is necessary :)
08:35 #dri-devel: < robclark> cwabbott_, ok.. so if I'm understanding properly, I only need to insert mov for non-back-edge phi input..
08:35 #dri-devel: < cwabbott_> if you need to permute the values and you ran out of register
08:35 #dri-devel: < cwabbott_> robclark: no, for backedges too..
08:35 #dri-devel: < robclark> cwabbott_, re: making it easier, you'll have to take that up with whoever designed the ISA ;-)
08:36 #dri-devel: < cwabbott_> robclark: well, you can just do the "emit tons of nop's" thing
08:36 #dri-devel: < robclark> cwabbott_, hmm, for backedge... seems like I should be able to arrange for instr that emit's value at end of the block to write into the correct registers?
08:36 #dri-devel: < cwabbott_> and then later figure out post-RA scheduling :)
08:36 #dri-devel: < robclark> imirkin, ra is after sched
08:37 #dri-devel: < imirkin_> robclark: uhm... why?
08:38 #dri-devel: < cwabbott_> robclark: well yeah, i guess you should know that information for backedges before you assign registers... but you could still get into a spot where you need to emit some copies
08:38 #dri-devel: < imirkin_> robclark: er wait. sched. my bad.
08:38 #dri-devel: < robclark> hmm
08:38 #dri-devel: < cwabbott_> i.e. you might not be able to assign the value to the register you wnt
08:38 #dri-devel: < cwabbott_> *want
10:16 #dri-devel: < pq> tagr, re: passing additional buffers; Wayland dmabuf protocol needs to somehow account for that too, then. And EGL interop. If a modifier says a fourcc uses more planes than usual, we need to understand modifiers also in userspace.
10:17 #dri-devel: < pq> if not in the Wayland protocol / compositor level, then at least inside EGL impl
10:22 #dri-devel: < imirkin_> airlied: in case you feel any ownership over the issue:
11:00 #dri-devel: < fredrikh> imirkin_: which assert does that test trigger?
11:01 #dri-devel: < imirkin_> fredrikh: don't remember. something depth-related.
11:01 #dri-devel: < imirkin_> fredrikh: pretty sure softpipe has ARB_texture_stencil8, so should be easy to test
11:01 #dri-devel: < imirkin_> (and probably llvmpipe)
11:03 #dri-devel: < imirkin_> i looked at it for a second and decided it'd take longer than i had to spare to work out the full path of who was in the wrong
11:03 #dri-devel: < imirkin_> but that test was def not designed for depth/stencil :)
11:03 #dri-devel: < imirkin_> it even says so
11:04 #dri-devel: < glisse> agd5f: so it freeze when sending smc message setswstate
11:04 #dri-devel: < glisse>
11:04 #dri-devel: < glisse> i tried disable all dpm feature but it does not change a thing
11:08 #dri-devel: < fredrikh> ah, apparently i have a release build of mesa
11:08 #dri-devel: < fredrikh> guess that explains why i'm not seeing it
11:08 #dri-devel: < imirkin_> right, you need to --enable-debug to see asserts
11:22 #dri-devel: < imirkin_> fredrikh: do you see it now?
11:22 #dri-devel: < fredrikh> i haven't done a new build yet :)
11:22 #dri-devel: < imirkin_> oh
11:50 #dri-devel: < agd5f> glisse, I guess the GPU hangs when checking the clock or voltage. probably need to check the state parameters sent to the smc for the power state (e.g., start with cypress_convert_power_state_to_smc() and make sure things like pll dividers and such look reasonable). An alternative is to clamp clocks and voltages in btc_apply_state_adjust_rules() and see if you can narrow down further (e.g., hangs with clocks overt 500 Mhz, et
11:50 #dri-devel: < agd5f> c.)
11:57 #dri-devel: < glisse> agd5f: i try using the current state and it still freeze
11:58 #dri-devel: < glisse> all value look reasonable
11:58 #dri-devel: < glisse> it just freeze as soon as you send the setswstate
12:01 #dri-devel: < agd5f> glisse, no more ideas then. Probably something the hw guys would need to look at
12:02 #dri-devel: < glisse> agd5f: my guess is that thames has something slightly different from regular desktop turks chip
12:02 #dri-devel: < glisse> is there any helper to dump RV770_SMC_HW_PERFORMANCE_LEVEL ?
12:07 #dri-devel: < agd5f> glisse, nope
12:07 #dri-devel: < glisse> not even a different smc firmware ? :)
12:08 #dri-devel: < agd5f> I'll check internally, but I don't think there are any newer smc images for btc
12:13 #dri-devel: < agd5f> glisse, yeah, that's the latest firmware
12:13 #dri-devel: < glisse> well i guess i will just disable dpm on thames, until i find courage to go trace fglrx
13:06 #dri-devel: < imirkin_> xexaxo: is there a -rc2 coming?
13:08 #dri-devel: < xexaxo> imirkin_: waiting for the gl dispatch (glapi) fix.
13:08 #dri-devel: < xexaxo> so it'll be out tonight by the looks of it.
13:09 #dri-devel: < imirkin_> xexaxo: ok cool
13:11 #dri-devel: < imirkin_> nouveau is totally broken on -rc1 unfortunately
14:27 #dri-devel: < mareko> imirkin_: you said tessellation was nowhere near completion, but I would beg to differ, what else is missing other than this?
14:28 #dri-devel: < imirkin_> mareko: erm... context may have been different
14:28 #dri-devel: < imirkin_> mareko: it was nowhere near enough to go into 10.6
14:28 #dri-devel: < mareko> ok, that was true indeed
14:28 #dri-devel: < imirkin_> mareko: while i haven't looked at your branch lately, you need to reconcile with chrisf's latest work
14:28 #dri-devel: < imirkin_> mareko: at the very least, enabling wireframe in heaven causes compile issues
14:28 #dri-devel: < imirkin_> due to a bogus mesa error
14:29 #dri-devel: < mareko> has he done any core stuff recently?
14:29 #dri-devel: < imirkin_> (coz it sees an ir_swizzle and bails)
14:29 #dri-devel: < imirkin_> erm... not recently. but potentially more recently than when you pulled his branches
14:29 #dri-devel: < imirkin_> also i did a semi-thorough review of one of his branches
14:29 #dri-devel: < mareko> because I've modifying the whole patch series, not just the gallium stuff
14:30 #dri-devel: < imirkin_> i suspect you've already handled a few of the things i pointed out in there... tbh i don't remember what my comments even were
14:30 #dri-devel: < mareko> and I only need to fix a few things in Mesa core and it's done
14:30 #dri-devel: < imirkin_> were you aware of the heaven wireframe issue?
14:31 #dri-devel: < mareko> nope
14:31 #dri-devel: < imirkin_> here was my review feedback on chrisf's stuff:
14:31 #dri-devel: < imirkin_>
14:31 #dri-devel: < imirkin_> i obviously didn't look at any of the i965 stuff
14:31 #dri-devel: < imirkin_> but the core bits start towards the bottom of that page
14:31 #dri-devel: < imirkin_> might want to glance over them in case i caught something you didn't
14:34 #dri-devel: < mareko> some core patches were also sent to mesa-dev last year, I guess those review comments have been ignored too
14:34 #dri-devel: < imirkin_> seems possible.
14:34 #dri-devel: < imirkin_> i do think chris integrated at least some of those, not sure
14:35 #dri-devel: < imirkin_> also look at the later tess-i965-N branches in his tree... might be worth diffing the core stuff
14:37 #dri-devel: < imirkin_> and i still haven't worked out why i get the blue triangles on fermi+ (although fermi gets a lot fewer of them than the gk208 i have)
14:37 #dri-devel: < imirkin_> i'm hoping it's a core issue somehow though :)
14:37 #dri-devel: < imirkin_> (like varying placement or something)
14:38 #dri-devel: < imirkin_> could be that patch varyings are overflowing in an unfortunate way though... the code handled it before, but i'm beginning to suspect that the way it handled the situation was wrong
14:38 #dri-devel: < imirkin_> so i need to trace how the blob handles more than N patch varyings
15:59 #dri-devel: < pinchartl> the .atomic_commit() operation starts by calling drm_atomic_helper_prepare_planes(), which will call the .prepare_fb() operation on all fbs
16:00 #dri-devel: < pinchartl> .cleanup_fb() will be called later when the fbs are flipped out
16:01 #dri-devel: < pinchartl> but if .atomic_commit() fails (for instance because it can't allocate the commit object, or because a wait for the previous atomic commit to complete is interrupted), who is responsible for calling .cleanup_fb() ?
16:02 #dri-devel: < pinchartl> I don't see any driver handling this at the moment, it looks like a bug to me
16:06 #dri-devel: < pinchartl> I guess the kerneldoc of drm_atomic_helper_cleanup_planes answers my question
16:45 #dri-devel: < xexaxo> idr: what are your plans on the glapi fix - are we going to revert v2 and apply v3 or just redo the diff as a separate patch ?
16:49 #dri-devel: <+idr> xexaxo: I already send a diff-as-a-separate-patch.
16:50 #dri-devel: <+idr> WTF? It's not in the archive.
16:50 #dri-devel: <+idr> Ugh.
16:51 #dri-devel: < xexaxo> cannot see it here either. typo'd the ML address/alias ?
16:51 #dri-devel: < xexaxo> your changes seems to be exactly what I was suggesting earlier btw. glad to see that I wasn't paranoid, this time :)
16:56 #dri-devel: <+idr> I have a script that does all that.
16:57 #dri-devel: <+idr> Anyway... I just resent.
17:10 #dri-devel: < imirkin> mareko: just noticed that text parsing of the tess shaders is pretty weak

Written by Christoph Brill © 2007-2015

Valid XHTML 1.0 Transitional

Available in Android Market