IRC Logs of #dri-devel on for 2014-08-30

Previous dayChoose dateNext day Show menu

00:10 #dri-devel: < pq> imirkin, 'make distcheck' is really handly if a project supports it, and making that kind of release tar-balls is intended. It automatically verifies the tar-ball is buildable and that 'make check' passes from it, etc.
00:10 #dri-devel: < pq> *handy
00:11 #dri-devel: < pq> OTOH, I'm with the people who don't really understand why to distribute 'make dist' kind of tar-balls...
00:11 #dri-devel: < pq> instead of git snapshots
00:22 #dri-devel: < ftigeot> you don't want software to be packaged ?
00:56 #dri-devel: < pq> ftigeot, the difference between a tar-ball that contains a random set of pregenerated files, vs. a tar-ball from exactly what is in version control system.
00:58 #dri-devel: < linkmauve1> pq, the goal of make dist is to not require autotools (sometimes a specific version) to build.
01:16 #dri-devel: < pq> yet, don't most distros just run autoreconf anyway?
01:16 #dri-devel: < pq> because the packaged auto-files might be outdated or unpatched
01:16 #dri-devel: < jcristau> the autotools model kind of predates that
01:17 #dri-devel: < jcristau> nowadays, yes, we tend to just autoreconf
01:19 #dri-devel: < pq> are dist tarballs supposed to contain all generated sources? So that it would make e.g. cross-builds easier by not having to compile generators or anything for the build arch.
11:19 #dri-devel: < imirkin> zgreg_: have you seen the issue at any point of OSD being black with vdpau? (e.g. in mplayer)
13:40 #dri-devel: < okias> Hey guys, can I dump gallium caps for actual running hw?
13:41 #dri-devel: < imirkin> "dump"?
13:41 #dri-devel: < imirkin> i.e. run ->get_param for every param?
13:42 #dri-devel: < okias> imirkin: I meant something like DUMP_CAPS=1 ?
13:43 #dri-devel: < imirkin> which does... what?
13:43 #dri-devel: < glennk> sounds like something rbug might be able to do, no idea how though
13:43 #dri-devel: < robclark> if it doesn't, it seems reasonable to add to rbug
13:45 #dri-devel: < glennk> but generally grep will tell you probably just as much, especially if some caps are state-dependent
14:36 #dri-devel: < johnflux> register_framebuffer() allocates 8kb for struct fb_pixmap pixmap; /* Image hardware mapper */
14:36 #dri-devel: < johnflux> What is this?
14:36 #dri-devel: < johnflux> what's a image hardware mapper?
14:58 #dri-devel: < robclark> johnflux, looks like some kind of sprite + image format translating thing for hw that supports weird formats.. idk, no one really uses fbdev anymore in the real world
14:58 #dri-devel: < johnflux> robclark: thanks
14:58 #dri-devel: < robclark> I guess it is something for some weird 80's hardware :-P
14:59 #dri-devel: < glennk> sounds suspiciously like a hardware cursor of some sort
15:00 #dri-devel: < glennk> 64x32 or 32x64 rgba8888 = 8kB
15:00 #dri-devel: < robclark> yeah, would make sense.. the only references I can find to it in code are old fbdev driver cursor stuff
15:01 #dri-devel: < robclark> looks a bit like it was designed to be a bit more generic.. but I don't see anyone using it for anything other than cursors
15:06 #dri-devel: < johnflux> robclark: what's a colormap? fb_alloc_cmap
15:07 #dri-devel: < robclark> color look up table
15:07 #dri-devel: < robclark> remember indexed color?
15:07 #dri-devel: < johnflux> aaah
15:08 #dri-devel: <+airlied> jekstrand: btw coverity reported two memory leaks of tmp_row in texstore_rgba_integer and texstore_via_flaot
15:08 #dri-devel: < robclark> (remember, fbdev dates back to when dinosaurs walked the earth)
15:35 #dri-devel: < kallisti5> odd question
15:35 #dri-devel: < kallisti5> i'm not pthreads expert...
15:35 #dri-devel: < kallisti5> but I ran mesa through electric fence (a tool that triggers a crash on invalid memory access)
15:35 #dri-devel: < kallisti5> and it pointed out "thread_function"
15:35 #dri-devel: < kallisti5>
15:35 #dri-devel: < kallisti5> not defined in the mesa sources, nor /usr/include on linux
15:36 #dri-devel: < DrNick2> src/gallium/drivers/llvmpipe/lp_rast.c:static PIPE_THREAD_ROUTINE( thread_function, init_data )
15:37 #dri-devel: < kallisti5> DrNick: that doesn't define what it is though as far as I can tell..
15:37 #dri-devel: < kallisti5> oh. wait. static.. no type
15:37 #dri-devel: < kallisti5> c11 crap?
15:38 #dri-devel: < DrNick> PIPE_THREAD_ROUTINE is clearly a macro
15:38 #dri-devel: < mattst88_> macro...
15:39 #dri-devel: < kallisti5> ok. Guess i've never seen it used like that before
15:40 #dri-devel: < kallisti5> could be just a bug in ElectricFence
15:40 #dri-devel: < kallisti5> ok.. I need to find a C / C++ performance profiler.. that would help a ton
15:41 #dri-devel: < kallisti5> by breaking out the state_tracker Haiku's GL now consumes enough cpu to cause GUI rendering issues
15:41 #dri-devel: < kallisti5> or get the valgrind port working
15:47 #dri-devel: < kallisti5> actually... maybe I just broke something. running ok now
18:04 #dri-devel: < zgreg_> imirkin: no
18:05 #dri-devel: < zgreg_> imirkin: were you able to find out what's going wrong with vdpau getbits conversions?
18:05 #dri-devel: < imirkin> zgreg_: haven't tried yet
18:11 #dri-devel: < imirkin> zgreg_: i think i'm going to look at the black osd thing though -- that's a lot more important to me right now :)
18:12 #dri-devel: < imirkin> probably some sort of sampler state screwup. ugh.
19:10 #dri-devel: < imirkin> zgreg_: what should be returned by sampler_view_components?
19:10 #dri-devel: < imirkin> i.e. an array of samplers which sample... what?
19:56 #dri-devel: < zgreg_> imirkin: samplers that sample a single component each
19:56 #dri-devel: < imirkin> zgreg_: yeah, i worked it out...
19:56 #dri-devel: < zgreg_> imirkin: the basic idea is that this allows all formats to be re
19:56 #dri-devel: < imirkin> but actually, rendering the video surfaces is all working great
19:56 #dri-devel: < zgreg_> treated the same way
19:56 #dri-devel: < imirkin> the problem is the OSD overlay
19:56 #dri-devel: < imirkin> which is rendered to an output surface using PutBitsIndexe
19:58 #dri-devel: < imirkin> mplayer does a vdp_video_mixer_render + vdp_output_surface_put_bits_indexed + vdp_output_surface_render_output_surface combo
19:58 #dri-devel: < imirkin> where the mixer_render and render_output_surface both render to the same output surface
20:02 #dri-devel: < zgreg_> and EOSD (RGBA) subtitles work fine?
20:02 #dri-devel: < imirkin> no
20:03 #dri-devel: < imirkin> err... i guess i dunno
20:03 #dri-devel: < imirkin> would those be the type that you get in a dvd?
20:03 #dri-devel: < zgreg_> nope
20:03 #dri-devel: < zgreg_> only SSA/ASS subtitles use EOSD in mplayer
20:03 #dri-devel: < zgreg_> but seriously, try mpv. mplayer is a dead project.
20:04 #dri-devel: < imirkin> meh. mplayer works great for everything (except this... heh. but i'm pretty sure it's a driver issue)
20:04 #dri-devel: < imirkin> everything else i've ever tried has let me down
20:05 #dri-devel: < zgreg_> well mpv is basically a hugely improved mplayer
20:05 #dri-devel: < imirkin> so improved it doesn't play all files anymore
20:06 #dri-devel: < imirkin> although perhaps that was mplayer2. i tried _something_ along those lines for a little while
20:06 #dri-devel: < imirkin> came back crying to mplayer pretty quickly
20:07 #dri-devel: < zgreg_> anyway, mpv shouldn't use paletted surfaces so it at least avoids this problem :)
20:07 #dri-devel: < zgreg_> but with radeon, this seems to work fine in mplayer
20:11 #dri-devel: < zgreg_> I haven't used mplayer in a long time, but I have just verified that the OSD still works with vdpau here
20:11 #dri-devel: < imirkin> cool thanks
20:11 #dri-devel: < imirkin> just to check, was it mplayer or mplayer2?
20:12 #dri-devel: < zgreg_> original mplayer
20:12 #dri-devel: < imirkin> k
20:12 #dri-devel: < zgreg_> and it indeed uses put_bits_indexed, checked with VDPAU_TRACE=1
20:12 #dri-devel: < imirkin> and i'm moderately sure it was fine on nv50
20:12 #dri-devel: < imirkin> which means it's just nvc0 that's messed up

Written by Christoph Brill © 2007-2014

Valid XHTML 1.0 Transitional

Available in Android Market