echosystm: what is this vga switcheroo thing?
airlied: echosystm: for hybrid graphics laptops
Jonimus: wishes his laptop had that right about now :P
hagabaka: I am trying to enable r300 gallium on ubuntu using https://launchpad.net/~xorg-edgers/+archive/ppa/ , but after installing the packages and restarting, glxinfo still doesn't say anything about gallium. Can anyone help?
echosystm: does it actually work airlied?
echosystm: and if so, with what chips?
airlied: echosystm: intel/ati and ati/ati combs work with an X logout, nvidia with nouveau still needs some work
Nightwulf|work: hi all
echosystm: where can i see what cards are supported by this open source driver?
airlied: echosystm: all radeons are supported to varying degrees
MostAwesomeDude: Heh. "But some are more supported than others."
echosystm: sorry, i meant, where can i see the specifics
hifi: has there been any new things lately
MostAwesomeDude: r100-r500 are awesome, r600-r700 are fairly radical, and r800 is bogus.
MostAwesomeDude: There used to be a RadeonFeature page that recieved updates; dunno how up-to-date it is.
MostAwesomeDude: http://wiki.x.org/wiki/RadeonFeature
MostAwesomeDude: Looks more or less accurate.
ossman: MostAwesomeDude, we need something like that vista system test with those descriptions ;)
GNU\colossus: MostAwesomeDude: I don't see where my R600-based card did not run absolutely awesome with radeon, though :)
ossman: mutters something about vsync
GNU\colossus: worked like a charm for me, at least sync-to-vblank for Xv :)
ossman: that might still work. but opengl got broken recently unfortunately
MostAwesomeDude: GNU\colossus: "Fairly radical," not "awesome."
AndrewR: MostAwesomeDude, r2xx 3D has bugs .... have you tracked down those strange-coloured gears on r200 (but not rv280)?
MostAwesomeDude: AndrewR: I think it was an agpmode thing. I stopped caring and will probably not start caring again for another few hours.
AndrewR: MostAwesomeDude, OK
DrDisk: has anyone seen these symptoms: http://funkturm.neurobeat.org/RADEON-ScreenCorruption-1.jpg (1 to 3)
DrDisk: "1" only happens on a 2nd screen, "2" & "3" whenever the 2nd screen is higer than the 1st
DrDisk: HW is a IBm T42 with "RADEON(0): Chipset: "ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP)" (ChipID = 0x4e50)"
airlied: DrDisk: using compiz?
DrDisk: airlied, nope, plain KDE kwm
DrDisk: also, just saw that after a resize, when using 3D the area that is not corrupted seems to be the previous screen size
DrDisk: the box runs SuSE 11.2, w/ X.org 1.6.5 and an updated ati driver (6.12.7)
svenstaro: MostAwesomeDude: So now that I'm using awesome gallium will you accept my fine bugs?
glisse: DrDisk: does the corruption persit after the resize ?
H__: Hi all. Is this : (II) RADEON(0): Modeline "1680x1050"x0.0 (note the 0.0Hz) causing the Not using mode "1680x1050" (bad mode clock/interlace/doublescan) I get ?
DrDisk: glisse, yes
DrDisk: if its the other way round (primary monitor has larger resolution than secondary), there's no corruption and that area is just black in a screenshot
DrDisk: currently primary output is LVDS, and the secondary is either VGA-0 or DVI-0
DrDisk: but i tend to avoid DVI-0, because it somewhat confuses the WM... (DVI-0 its still identified as monitor #2 but the taskbar moves from LVDS to DVI-0 when I enable it. funnily it stays on LVDS when I enable VGA-0 instead)
DrDisk: initially LVDS runs with 1400x1050x24 (native resolution) and the external monitor (VGA-0 usually) is at 1280x1024
DrDisk: just made another screenshot of the 3D case (after resizing the secondary screen to 1400x1050):http://funkturm.neurobeat.org/RADEON-ScreenCorruption-4.jpg
DrDisk: the height of the screen seems not to matter, the corruption begins always at the same x-coordinate (local coordinate x=>1256, fullscreen coordinate x=>2656)
Terrax121: Hi
Terrax121: I have vacation now, and want to get my hands dirty with oss development.
Terrax121: Is there any specific part of the oss driver stack, where it makes sence to look into?
AndrewR: Terrax121, depend on what you can, as coder.
bridgman: the most interesting action is probably happening on the 3d side; if I were going to start somewhere I would look into mesa because it has the best combination of accessibility and need
Terrax121: AndrewR, what do you mean by, can as a coder? You mean how good I am to c or how much experience I have in driver development in general?
bridgman: mesa is big but once you understand where the hw drivers fit it's not so bad
Terrax121: bridgman, do you mean galium3d development or the opengl part in mesa?
bridgman: gallium3d paths; pretty much all of the attention is there now
bridgman: we
bridgman: we're using the classic mesa hw drivers to add support for Evergreen but that's about it
Terrax121: Okay what about mesa's opengl implementation? As far as I know, OpenGL 3.0 hasn't been implemented yet?
bridgman: it was maybe half way there last time I looked; there's a status file, hold on
Terrax121: Thx
bridgman: go to http://cgit.freedesktop.org/mesa/mesa then tree, docs, GL3.txt
AndrewR: Terrax121, hopefully bridgman has better answers, myself mostly read everything, not writing any code (-> useless)
Terrax121: But when talking about OpenGL mesa -> galium3d -> hw driver, its the galium3d part, which needs the most intention?
Terrax121: AndrewR, okay, do you having any c experience?
bridgman: there are three things going on in parallel - extending mesa GL support, modifying mesa to use Gallium3D drivers, and writing Gallium3D hw drivers
bridgman: the important thing to understand is that most of mesa is still used whether you are running with the classic hw drivers or the new Gallium3D drivers
Terrax121: Okay. I see Marek has some galium3d development going
glisse: core mesa already have enough attention i would say :)
Terrax121: bridgman, I see. Mesa just has to translate it hardware calls to galium3d?
AndrewR: Terrax121, http://news.gmane.org/gmane.comp.video.dri.devel and mesa3d-dev list has some useful discussions about what need to be done ... myself once tried to hack at nouveau, i have few lines of code in my tree, but stopped some time ago (lack of knowledge about mesa internals, and lack of any solid knowledge in general :/)
Terrax121: its*
bridgman: yes, but since OpenGL is such a humongous API that translation is non-trivial
glisse: gl4 is better, dropping the old stuff
Terrax121: Ok
glisse: well i should review little bit more gl4 before saying it's good :)
Terrax121: Well I must say, its hard to know where to begin, because so many folks are involved. :)
bridgman: yep... although so far dropping the old stuff is proving to be impractical unless you are willing to run two different GL drivers, one for new apps and one for existing apps ;(
bridgman: Terrax121; just pick something that interests you and understand it; tinker with the code, ask questions, try things...
bridgman: and accept up front that for the first while everything you do is going to get done by someone else before you finish ;)
bridgman: but that doesn't last long
Terrax121: :)
bridgman: btw if you're interested in video accel that's one area where there's not a lot of dev effort yet AFAIK
bridgman: you should still learn about Gallium3D API anyways
AndrewR: bridgman, http://people.freedesktop.org/~jb17bsome/vpe/ (not tried it yet)
Terrax121: Actually I developed my own mpeg4 implementation this semester (it was a mini project, where we had to learn about image/video compression)
Terrax121: <- I'm a student
Terrax121: bridgman, do there exist some general docs about galium3d?
bridgman: I think so, although with the Tungsten -> VMWare transition I'm not sure where they are these days
bridgman: I think most people just point to the pipe driver header file, hold on
AndrewR: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/docs/source ?
Terrax121: AndrewR, thx
Terrax121: Should the video acceleration be done though shaders and vdpau API or va-api?
bridgman: I think the header file is : http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/include/pipe/p_context.h
Terrax121: through*
bridgman: I don't think anyone cares although obviously a choice has to be made at some point
bridgman: all the APIs are pretty similar anyways, at least the way they are actually used
glisse: vdpau seemed saner
glisse: from hw pov
glisse: from driver hw pov
Terrax121: Okay
bridgman: personally I would look at adding some Gallium3D calls to ffmpeg/libavcodec rather than writing a whole new decoder from scratch, but I'm lazier than most
Terrax121: :)
Terrax121: Well that might be the best way to do it. Just implementing the things which is able to be parallelized
bridgman: exactly - some of the functionality is going to have to stay on the CPU and it doesn't seem like the kind of thing you could code up in a weekend, even if you were Awesome
Terrax121: Okay I have to head at work. I will read up on the informations you gave me.
Terrax121: I will hang around in this channel, and most likely have some questions now and then
bridgman: ok, have fun
svenstaro: Whats the preferred way to enjoy high res videos with radeon?
mjr: (considering there's that pre-existing va-api frontend for vdpau, the latter wouldn't probably be that crummy a choice, but hey, I'm not gonna do it either way so I don't count ;)
svenstaro: Just now mplayer said "I hate you and your vdpau"
AndrewR: ...speaking about GPU video (post)processing - anyone tried gstreamer plugin for deinterlacing via shaders? Obviously, its not for my rv280 [need GLSL] :)
svenstaro: 1080p video goes so-so
svenstaro: Heavy CPU work
AndrewR: http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/gst/gl ...even 720p h264 is slightly too much for my CPU, but i always can resize (1024x768 diplay here, anyway)
AndrewR: *display
KotH: AndrewR: well.. if you use one of the slowest players conceived by humanity, no wonder your pc is too slow ;)
KotH: AndrewR: try vlc, that should give you a factor 2 to more speed
KotH: AndrewR: if this isnt enough yet, try mplayer
rhodan: 50(
rhodan: 508
rhodan: 420
rhodan: {}M, VIRT, RES
rhodan: Where art thou taking my memory
rhodan: forsooooth!
rhodan: Is there a way to make X drop its caches?
AndrewR: KotH, hey, i use mplayer, gstreamer only here for swfdec :) (and vlc seems to hate me, for some reason)
ajax: X doesn't have caches, in that sense.
KotH: AndrewR: huh?
KotH: AndrewR: then you must have a very slow machine if it cannot decode h.264 with 720p ... or insanely high bitrate files
AndrewR: KotH, but generic GL-based deinterlacing might be useful, especially if i found way to feed resulting shader into player's vo gl (and change videocard to some nv40 w/ nouveau ... when nouveau will be a bit more speedy)
KotH: AndrewR: deinterlacing should not be needed with modern video
KotH: AndrewR: at least it has been years since i last saw any interlaced content on the net
AndrewR: model name : AMD Duron(tm) Processor cpu MHz : 950.062 cache size : 64 KB - says it all about my computing power (modern machines at least 8x faster)
KotH: o_0
KotH: oh...kay...
KotH: 720p mpeg asp is your uper limit than ^^'
AndrewR: KotH, i have few home-made DV files, and some mpeg2/DVD ones ... well, just something nice to have someday, not pressing need.
rhodan: Is there no way to free the memory, then?
KotH: AndrewR: for mpeg2 stuff, you should have more than enough cpu power to do the deinterlacing there
amarsh04: KotH, I found horrible interlacing with http://www.youtube.com/watch?v=jXPcLwGs91s so I re-encoded the same video as http://www.youtube.com/watch?v=RIV2gV3nTPo
KotH: is at work and thus doesnt watch youtube
amarsh04: oh, ok KotH
KotH: amarsh04: and you sure it is _interlaced_ and not _telecined_ ?
rhodan: If we speed up transcoding we can speed up the overall progression to non-interlaced formats.
KotH: if you are transcoding, you should always deinterlace/invers telecine
rhodan: or non-interlacively speed up the conversion to progressive formats.
KotH: speed up? what do you mean?
amarsh04: originally shot on digital video (PAL) afaik, I think I did end up using inverse telecine
rhodan: If he can convert his videos faster,
rhodan: we'll get rid of interlacing faster, too.
mwc: Is there anything that can be done to assist work on the Evergreen port until AMD releases the docs?
svenstaro: mwc: Get hacking :P
mwc: basic modesetting is up, so I assume that the DDX is coming along based on wisdom from the r700
agd5f: DrDisk: if your desktop size is larger than 2048 pixels GL-based compositors won't work since the desktop is larger than the max texture size (2048 pixels)
agd5f: they should check before they start, but they generally don't
mjr: (apparently the dev branch of compiz works around that though but I don't know if that's in release versions still)
glisse: i am curious on how they would do that
mjr: iirc by having a non-texture buffer from which multiple textures are updated. Yes, rather less efficient but better than nothing, especially as often the only window that exceeds the size may be the root one.
svenstaro: I thought biggest size was 4096?
bazu: hi, i`m using radeon driver but doesen`t work vbetool
bazu: how to fix it :(
KotH: bazu: "does not work" is not an error description
bazu: sorry about the english
bazu: but i try in fedora, archlinux and on ubuntu
KotH: your english is not the problem
bazu: and i if try vbetool dpms offf
bazu: nothing happend
bazu: if change to fglrx everythink it`s ok
bazu: i`m using hd3470
mjr: svenstaro, depends on the gpu generation, drdisk was talking quite old hardware way back when
mjr: notes that with gallium3d, his compiz desktop has operated for over a day without crashing, while the classic driver didn't fare as well (ubuntu lucid, r300g from a ppa)
agd5f: bazu: don't use vbetool it messes with the hw behind the driver's back
agd5f: svenstaro: depends on the hw generation. r1xx-r4xx is 2048, r5xx is 4096, r6xx-r7xx is 8192
mwc: what's R800? I can't imagine anybody needing 16384 texture sizes, but maybe with those 6-monitor eyefinity configs...
mwc: Oh, sorry, evergreen
agd5f: mwc: yup 16k
ajax: mwc: you should talk to the oil and gas people sometime
ajax: _big_ textures
mwc: ajax: probably also the medical visualization types
agd5f: bazu: if you want to blank the display use xset. xset dpms force off
Pallokala: I have occasionally used 8000x8000 virtual desktop (compiz) with fullscreen firefox for grabbing f.ex. large maps of something from net
DrDisk: agd5f, there's no compositing or anything like that running, just some (random) GL screensaver if at all
DrDisk: ( i once enabled compositing, the resulz was an instant kernel freeze)
H__: Damn, just found out that my X300 is no longer supported in the fglrx drivers, and the radeon driver does not properly support my analog VGA ... this means I can no longer use my Z60m laptop with an external monitor :-(
agd5f: H__: radeon supports the vga port just fine. if you are having an issue please file a bug: https://bugs.freedesktop.org
H__: oh ? ok
H__: agd5f: I see no 'radeon' or 'ati' product in this bugzilla. which product entry should I use ?
agd5f: H__: xorg, then driver/radeon
H__: ah yes, ok.
DrDisk: *gna* /usr/share/aclocal/xorg-macros.m4 is present and is read by aclocal but ignored (at least the macros referenced in configure.ac aren't copied to aclocal.m4...
DrDisk: gna... too old
DrDisk: hmmmm a hacked 6.12.192 seems to build w/0 error....
DrDisk: lets try 6.13.0...
DrDisk: builds w/o error... will try later if it runs...
kdekorte: Hello, been seeing alot of work on r600g, does it do anything yet?
glisse: it produce a nice sweet gallium.bof files
kdekorte: cool, but none of the redbook stuff yet>
kdekorte: yet?
glisse: but it's of limited use beside that, ie it's useless to end user
glisse: most of the fp works
glisse: don't use that much the redbook to test
Zaba: what exactly is missing in it for, for instance, working glxgears?
Obscene_CNN: all the other important bits are missing ;)
glisse: what is missing is proper handling of trans instruction in the shader compiler
glisse: otherwise gears works
glisse: really 80% of the work left is in shader compiler
Zaba: I see
kdekorte: glisse: so any idea how much work is left to the shader compiler to be functional?
Zaba: about 2 megajoules, I reckon!
glisse: something like a day of workand it should be functional but not clever
mwc: Has there been any indication from AMD how much work from the R700 port will translate to Evergreen?
glisse: the cp the driver so most of the work translate
glisse: again most of the work is in shader compiler
mwc: Cool, I might have to see what I can contribute once some support hits Mesa. It'll probably be the classic stuff that gets evergreen supprot first, then R600g later from what I'm hearing?
dafox: glisse: any news on bug #28402 (Kernel 2.6.34 freezes randomly)? I noticed that someone else reported experiencing similar freezes with 2.6.34, perhaps his information could be of use (if he were asked to provide it).
ernov: hi
ernov: is there any chance for radeon driver to ever work for my stupid x200m card?
Daekdroom: ernov, which driver?
Daekdroom: I have a X1100, which is basically the same thing, and the radeon driver works very well
soreau: ernov: The radeon driver should work. What problem are you having exactly?
ernov: no matter what system i try to use it doesn't work, so it's radeon's fault
Daekdroom: Which driver are you talking about? It sounds like you're trying ATI's binary driver
soreau: 'doesnt work' doesnt tell us anything. What are you trying and what is not working exactly?
ernov: soreau: the problem is that screen craps after loading driver, sometimes after switching to tty
ernov: it goes gray and shivers
soreau: ernov: Does X work?
ernov: sometimes
soreau: ernov: Can you pastebin your current X log?
glisse: dafox: don't hold your breeze
ernov: eg on freebsd not, on gentoo works but unable to switch to tty - screen goes gray
glisse: fixing lockup might takes years
dafox: glisse: It would be nice to update my kernel more often than that ...
glisse: dafox: what could be helpfull is kernel message on lockup
dafox: glisse: there are no messages recorded at that point
dafox: glisse: the log just stops
glisse: you would need to log through ssh
glisse: or have netconsole running
ernov: soreau: unfortunatelly i can't find paste app in freebsd
dafox: glisse: what is netconsole? It does look like it is a hard freeze, I'm not sure if I can even log in through ssh (I think I tried that at one point and it failed, but I'll try again to make sure)
soreau: ernov: Do you have curl?
soreau: and cat..
struberg: good evening, I have a radeon drm question. I have 2.6.35-rc3. which power management features are finally in there?
struberg: I read a lot about dynpm but modinfo radeon doesn't show it
struberg: how to switch down to the lowest power consumption mode? I now use radeon.hw_i2c=1 and radeon.dynclks=1 but don't see much drop in temperature
dileX: you can switch via sysfs
dileX: http://lists.freedesktop.org/archives/dri-devel/2010-May/000492.html
struberg: mom digging into it - txs :)
dileX: for r600+ there is a patch from agd5f
struberg: yes, have a rv620
dileX: temperature*
dileX: http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-add-support-for-internal-thermal-sens.patch
struberg: ah the patch from alex is still not in linus 35-rc3 repo?
dileX: IIRC it is for 2.6.36
struberg: will try it txs dileX
hagebake: has anyone played Frogatto (a 2D platforming game using OpenGL, http://www.frogatto.com) on radeon? It slows down when rendering water for me, and for someone else using radeonHD. I wonder if it's a problem in radeon
agd5f: hagebake: 3D is all done in the mesa driver, so the ddx is irrelevant in most cases
H__: agd5f: FYI I just filed https://bugs.freedesktop.org/show_bug.cgi?id=28540
Thunderbird: MostAwesomeDude, just stumbled on this which might be a good workaround for S3TC http://www.opengl.org/registry/specs/EXT/texture_compression_dxt1.txt
Thunderbird: it is just the same as the S3TC extension without the compression part
Thunderbird: it was designed for OpenGL ES but it should be fine here :)
MostAwesomeDude: Thunderbird: You should email mesa-dev about that. :3
Thunderbird: not subscribed to it
Thunderbird: just thought you might want to know about it; (perhaps we can use it in Wine if it were supported)
MostAwesomeDude: I'm fairly certain you don't have to be subscribed to post.
MostAwesomeDude: But the people that *should* see it (idr, VMWare guys) aren't often on IRC.
Thunderbird: it doesn't handle all s3tc formats though I think
Ke: agd5f: if you have some contacts, could you make "xset dmps force on" unblank the screen on fglrx
Ke: or ask them to~
stringfellow: Thunderbird: for Wine's purposes that extension is fairly useless
Thunderbird: it is only dxt1 that's the issue
Thunderbird: if they added the other ones, it could be useful, right?
stringfellow: maybe, but then it isn't really the same extension anymore
Thunderbird: sure, it would require a new one
stringfellow: I mean, sure, s3tc without encoding is enough in a lot of cases
stringfellow: but if you want that you might as well just write a separate extension that does that
Thunderbird: the main reason I put it forward it was because I think MostAwesomeDude mentioned that they were considering to support the normal s3tc extension without the compression part
Thunderbird: what vendor is shown for R100/R2xx cards in glxinfo?
Thunderbird: Tungsten..
mokoloko: compression is the patented part?
Thunderbird: yes
Thunderbird: well decompression as well but it is no issue if it is done in hardware
mwc: so if compression was done in HW, we'd be set?
stringfellow: for Wine's purposes the driconf option should work well enough, even if it isn't exactly ideal
stringfellow: I'd be more worried about floating point textures becoming a problem
Thunderbird: it is just that the driconf option isn't on
Thunderbird: though we could warn about it when a game creates a s3tc texture anyway
Thunderbird: some games just create it
stringfellow: any semi-recent game is going to use float textures for all kinds of things
Thunderbird: hopefully but some games are still stupid e.g. SC2
stringfellow: I'd say SC2 is fairly well done, actually
Thunderbird: in the menu it expects it (though I haven't tried to hide s3tc)
Thunderbird: btw would a quirk to disable EXT_framebuffer_object on r1xx/r2xx hardware be fine for you for 1.2? just remembered the bug http://bugs.winehq.org/show_bug.cgi?id=21708
stringfellow: not really convinced it's needed
stringfellow: or rather, that it's going to make things better
Thunderbird: true, backbuffer doesn't work that great
stringfellow: yes, but that's not the issue
stringfellow: e.g. you could require depth textures for FBO ORM, that would probably be a reasonable requirement
stringfellow: but you still won't be able to share your depth/stencil buffer in a reasonable way
stringfellow: between onscreen/offscreen
MostAwesomeDude: BTW, float textures should work in Gallium.
stringfellow: MostAwesomeDude: they do? I thought those had patent issues as well
MostAwesomeDude: stringfellow: "Alleged possible patent conflicts." :3
MostAwesomeDude: Moreover, I don't really care.
MostAwesomeDude: I will leave it up to the Intel and VMWare people as to whether a compile flag should be added to Mesa to conditionally disable them.
stringfellow: not complaining, but I was under the impression that was the reason Mesa didn't support them
MostAwesomeDude: Anyway, I wouldn't object to MESAX_texture_compression_dxtc_free, a texture compression extension that only permits decompression.
svenstaro: MostAwesomeDude: How do I subtly trick you into fixing issues I'm seeing with gallium and r300?
mjr: takes back the statement about compiz stability on r300g (from a random ubuntu ppa), but at least only the wm crashes, not the whole session. Might even blame compiz, though on intel works fine for extended periods.
MostAwesomeDude: svenstaro: File bugs on FDO bugzilla, give me bug numbers.
svenstaro: I'll make lots of pictures!
svenstaro: Is there any way I can FORCE vsync off?
soreau: mjr: Slow your roll there.. looked at a bt yet?
soreau: svenstaro: Why?
mjr: No, and about to blather myself to sleep anyway.
soreau: In that case, try not to fall asleep on the keyboard without posting a bt first :P
svenstaro: soreau: I want to debug without vsync
soreau: svenstaro: I fail to see how that has any relevancy
soreau: Unless you're debugging something related to vsync
svenstaro: soreau: I am
svenstaro: MostAwesomeDude: File for DRI?
MostAwesomeDude: svenstaro: Yeah, file under r300, I guess. Put r300g in the bug title.
MostAwesomeDude: goes to bug FDO admins again
svenstaro: But will you tell me how to disable vsync first?
svenstaro: Because the bug might be related to that
MostAwesomeDude: I'm not sure how to do it in Gallium. Check driconf.
svenstaro: Can't find anything related to vsync there
svenstaro: Oh wait, it was hidden behind a funny name I think
svenstaro: Doesn't look like it is honoring my options at all
svenstaro: glxgears happily spits our around 1000 frames even with 100% forced vsync
agd5f: svenstaro: you need 2.6.34 or maybe 2.6.35 (not sure when the patch got merged) plus latest ddx git to use vsync with dri2
svenstaro: But I DONT want vsync :P
svenstaro: I'm actually having problems turning it off.
svenstaro: http://dri.freedesktop.org/wiki/ConfigurationInfrastructure doesnt work at all
agd5f: svenstaro: comment out info->accel_state->vsync = TRUE; in radeon_dri2.c in the ddx
svenstaro: Isn't there a happier way?
pazof: it's not so sad :)
svenstaro: It is if I have to recompile my stack again :(
agd5f: it's not synced to vsync, it just stalls the cp until scanout is past the destination coordinates. actual vsync requires the glx extensions
agd5f: it's more of an anti-tearing measure
svenstaro: Yes, but I want to forcefully just turn it off temporarily.
agd5f: svenstaro: then comment out that line
svenstaro: Which part of my stack is that?
agd5f: ddx, xf86-video-ati
svenstaro: so not r300_dri.so?
agd5f: no. with dri2 the ddx is responsible for gl swaps
svenstaro: May I request a way to disable vsync without recompiling in the future? :P
pazof: no:)
agd5f: svenstaro: that doesn't sync it to the refresh
agd5f: it just makes buffer swaps tear free
svenstaro: after recompiling, restart X?
agd5f: yes
svenstaro: And then it all is awesome?
agd5f: svenstaro: depends what you are trying to do. gl buffers swaps will tear now
svenstaro: hopefully :P
svenstaro: IMMA RESTARTING MAH X
svenstaro: Reporting back in. FPS still limited to 60 FPS. No tearing. Still time skips.
svenstaro: I want to make this tear like a mofo, help me. :) In particular, I want to unlimit FPS.
svenstaro: No tips? :/
svenstaro: I can't record a movie of this, my laptop is not quick enough to produce a viewable framerate. Is a bug description enough?
MostAwesomeDude: Sure. The important thing is probably reproducability.
svenstaro: Actually you could test this out real quick given any 3D scene. Create a sufficiently complex 3D scene that you get around 40 FPS, move around. Jittery movement and timeskips. Not happening without gallium3d.
MostAwesomeDude: Hm. I think it *really* depends on the app. Q3/OA work fine here.
svenstaro: I tested Nexuiz and Ogre and Warsow
svenstaro: So 2 q3 games
MostAwesomeDude: Do you have the Mesa demos repo? Does demos/ipers stutter?
MACscr: right now i have 3 monitors and a total of 2 screens setup. One screen is for two monitors and the second is its own screen and even x server. How can i get the two monitors to act as two screen, but the same x server? I want to be able to maximize apps and have it just fit the screen instead of both monitors
svenstaro: Would it be system installed by the autotools?
MostAwesomeDude: Well, if you're running on stuff from git, we just split it out to its own repo.
MostAwesomeDude: http://cgit.freedesktop.org/mesa/demos
svenstaro: Er yeah I'm using that. Apparently it wasn't installed though, making it
MostAwesomeDude: Meh, nobody actually installs them. I don't even think the names are safe WRT the rest of the system.
svenstaro: Dunno, I like being able to do glxgears and glxinfo
soreau: nobody!
MostAwesomeDude: Honestly, I really *really* wish distros would install ipers in the same package as glxgears.
MostAwesomeDude: It's far more demanding as far as small demos go.
svenstaro: Then you should probably make upstream put it to the install stuff
svenstaro: Anyhow, it doesn't lag at all, super smooth. :/
svenstaro: Not even if I ramp up the details one time.
soreau: svenstaro: You are so backward. You want to kill your vsync and are sad when things run super smoothly
svenstaro: soreau: Yes.
svenstaro: Do we have any really complex demo?
soreau: svenstaro: What problem are you actually trying to fix?
svenstaro: When gaming or doing benchmarks using what should be smooth scenes at good FPS, I get mysterious timeskips or timemorphs using gallium. Without gallium, overall performance is a little lower but super-steady.
svenstaro: This is r300g using all git.
svenstaro: Ah, demo cubemap is able to reproduce it!
svenstaro: albeit it wont start at all without gallium
soreau: svenstaro: What app is demonstrating the issue in the first place?
svenstaro: All Q3 games, my own benchmark using Ogre, all Ogre samples
MostAwesomeDude: Hm.
Droste: svenstaro: you're using kwin if I remember correctly. is compositing disabled?
svenstaro: Of course
svenstaro: With compositing my FPS would be rather laughable
RAOF: MostAwesomeDude: How much would you like distros to ship demos/ipers? Enough to file a Debian or Launchpad bug asking for it with a little justification?
mwc: IIRC, fedora ships a mesa-demos package, maybe debian and ubuntu could be persuaded to as well
mwc: http://koji.fedoraproject.org/koji/rpminfo?fileStart=0&rpmID=1950414&fileOrder=name&buildrootOrder=-id&buildrootStart=0#filelist
svenstaro: Perhaps it would be better to ship a full-blown benchmark suite that is actually user friendly and encourages performance reports?
mwc: interestingly, one thing fedora doesn't ship ipers ;)
MostAwesomeDude: svenstaro: That's just asking for trouble. :3
svenstaro: You think so? :/
airlied: fedora also ships phoronix test suite
MostAwesomeDude: RAOF: I just might do that. I'd need to go through the entire demo list and make sure there's not anything *more* demanding in there.
RAOF: airlied: As does Ubuntu.
airlied: and fedora does ship ipers
airlied: just checked
airlied: /usr/lib/mesa/ipers here
Droste: MostAwesomeDude: mesa/demos: src/trivial/clear.c <-- isn't a god name as it overrides clear from ncurses-utils
airlied: yeah we packaged them in /usr/lib/mesa for that reason
svenstaro: Well I for one am now happy that I can unleash all my awesome shaders into my applications with gallium.
Droste: airlied: but you have to know that it's there. you can't put that directory in your PATH
mwc: I can't imagine running any of those frequently enough that they'd need to be in my PATH
Droste: it's more an advantage for tutorials/help if you could just say to a user start xxx and he doesn't have to look up the path to the demo
mwc: At any rate, if you really have to have it, just put it last in your path so that clear doesn't override anything earlier
Droste: yes but if there is another clear you'll always use that and never the mesa one
Droste: clear was just an example I rembered. Maybe there's another one
mwc: or you just tell them to run /usr/lib/mesa/blah
Droste: which could be another path at ubuntu/opensuse/debian/...
mwc: yep
Droste: if the names are safe, distros could just install them in /usr/bin
Droste: which would be more consistent than using a /../lib/.. directory
Droste: but it's not that important because most users will never use any mesa demo at all
svenstaro: I will continue my quest for writing a useful and visually attractive upstream benchmark.
svenstaro: So long!
airlied: there is no nice benchmark for GL since the API is so broad, hence why things like phoronix test suite and the closed benchmarks exist and are huge
Thunderbird: the 'great' phoronix test suite which mostly consists of highly advanced quake3 games
svenstaro: I'm actually building one without a quake base
svenstaro: I think phoronix is bloated and silly
airlied: svenstaro: its at least in some way real-world
airlied: the problem with benchmarks for GL in general is they miss the point, that lots of GL apps require corner cases to work that other GL apps don't
svenstaro: I think that is rather untrue. Compiler optimization options on all those games which most people install from repos matter a LOT
Droste: airlied: are you going to merge 2.6.35-rc3 into d-r-t?
airlied: and if the corner cases don't work, the app will be slow no matter what the benchmark says
airlied: Droste: probably rebase at some point whenI have some time
svenstaro: The phoronix test suite should compile all required games using -O0 and try to control most other factors.
hagabaka: has anyone played Frogatto (a 2D platforming game using OpenGL, http://www.frogatto.com) on radeon? It slows down when rendering water for me, and for someone else using radeonHD. I wonder if it's a problem in radeon
airlied: its a 3D driver problem, what 3D driver you using, also kms/ums?
hagabaka: me?
airlied: yes
hagabaka: 3D driver = mesa or gallium? I tried both
hagabaka: I have KMS, I don't know what UMS is...
hagabaka: but I use the packages from https://launchpad.net/~xorg-edgers/+archive/ppa
svenstaro: hagabaka: I'll test it for you real quick, let me compile
hagabaka: I'm using radeon with 9800 Pro
svenstaro: Their SVN is crapslow
hagabaka: hmm
Daekdroom: hagabaka, do you have the libgl1-mesa-dri-gallium package installed?
hagabaka: yeah
Daekdroom: That means you're running gallium...
Daekdroom: Have you tried it without it?
Daekdroom: (just remove the package and you won't even have to restart X)
hagabaka: although it doesn't use gallium by default as the page says, I have to manually set LIBGL_DRIVERS_PATH to use it
Daekdroom: Oh.
Daekdroom: It works by default with me.
hagabaka: I don't know why
hagabaka: but it might be better this way, I think KDE could be very broken with gallium
MostAwesomeDude: Entirely possible.
hagabaka: but switching through LIBG_DRIVERS_PATH is the right way to use it right?
svenstaro: frogatto is badly set up
hagabaka: what do you mean?
svenstaro: Just look at their build script
svenstaro: Also, media and code under different licenses :(
hagabaka: well they are in early alpha, and are trying to not get bogged down by supporting a build system yet
hagabaka: but the Makefile works for me, after installing the necessary dev packages
svenstaro: Just use CMake and not worry about build system
svenstaro: Anyway, compiling
Daekdroom: Frogatto is so broken it always detects my keyboard as pressing the LEFT key xD
hagabaka: they want to sell the game on istore and maybe other places, so they don't want people to get the game through "open source" and sell/give away another copy of the game to the commercial platforms, or something like that
Sarvatt: actually i'm testing some hackish patch in xorg-edgers at the moment to load radeong_dri.so if Option "Gallium" "True" is in your xorg.conf, radeong is in libgl1-mesa-dri
svenstaro: The game takes long to compile for just SDL
hagabaka: hi shadowmaster
shadowmaster: hi
hagabaka: svenstaro is compiling frogatto to see if it slows down when displaying water too
svenstaro: hagabaka: I'm done and it is super steady
hagabaka: oh
shadowmaster: oh, gallium talk. I still don't dare to compile the gallium drivers from git master :P
svenstaro: shadowmaster: Do it, I just did it and it is awesome.
svenstaro: shadowmaster: distro?
shadowmaster: Debian squeeze
svenstaro: Oh, I'm sorry.
shadowmaster: but I'm running the regular dri drivers from git master since long ago
svenstaro: Just compile it, it will work awesome.
svenstaro: Also, it is awesome and not enabled or even loaded by default
shadowmaster: I'd want to check what's the status for my chipset first (r6xx), since AFAIK it's a rather recent additioD[D[D[D[D[D[D[D[D[D[D[D[Dn
svenstaro: wat
shadowmaster: er, addition
Daekdroom: r600g doesn't work.
Daekdroom: well.. It does.. but you're definitely better off using classic mesa
shadowmaster: ah :(
Daekdroom: It doesn't even renders glxgears =/
hagebake: sorry disconnected
hagebake: is it steady at these screens too? http://frogatto.googlecode.com/issues/attachment?aid=-8705115859150886310&name=frogatto-water%3A%3Adraw_area-4v.png&token=610ca2b38448bd4a2623274c2ee0e709&inline=1&thumb=1
Sarvatt: hagebake: try adding Option "Gallium" "True" to the radeon device section in an xorg.conf
hagabaka: ok
Sarvatt: i'm fiddling with the gallium stuff in edgers to get rid of that darn --with-dri-searchpath pointing at /usr/lib/dri-gallium thats causing problems
hagabaka: but there should be no difference with this way and running a program with LIBGL_DRIVERS_PATH=/usr/lib/dri-gallium, for just that program right?
Sarvatt: i was just saying how to enable gallium currently since i'm reworking the packages and things are in flux
hagabaka: ah
Droste: 19root6
Droste: aa
Droste: oh
Droste: sorry :-D
hagebake: does it represent a problem if radeon_bo_is_referenced_by_cs is using a lot of time in CPU profile?
hagebake: that is using r300 galium, with mesa, radeonReadRGBASpan_xRGB8888 instead is using most of the time
airlied: hagebake: sw fallback of some sort
hagebake: http://pastebin.com/VtrNRMLw , the game slows down unless I comment out line 290: glDrawArrays(GL_TRIANGLE_STRIP, 0, sizeof(vertices)/sizeof(GLfloat)/2);
hagebake: I think it's drawing a few rectangles with blending
hagebake: but blending doesn't seem to be the problem, because even if I disable GL_BLEND, it still slows down there
hagebake: do both radeon_bo_is_referenced_by_cs and radeonReadRGBASpan_xRGB8888 represent software fallback?
hagebake: that function is called every frame, but it also does some other things, and only that line seems to slow it down
airlied: what are you profiling with can you get acallgraph?
hagebake: google perftools
hagebake: I can get a graph, but those functions don't show in the graph for some reason...
hagebake: would you be able to use it if I upload the .prof file and the compiled program?
airlied: don't have a machine running those drivers in front of me
airlied: sysprof profiles woudl be handy
hagebake: the call graphs are at http://hagabaka.doesntexist.org:60880/~hagabaka/frogatto-profile/gallium.ps and mesa.ps in the same directory, I'll try to get sysprof in the mean time
airlied: yeah that is missing the kernel bits
hagebake: would sysprof solve that problem, or do I need to install something related to kernel?
airlied: you might need kernel debug symbols if you are using a distro kernel
airlied: not really seeing the mesa bits either
airlied: just libdrm
hagebake: I'm using http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc1-lucid/
airlied: mesa is definitely hitting a sw fallback, no idea what gallium is doing
Sarvatt: hagebake: install the 2.6.35 kernel in the PPA along with linux-tools from there, should have what you need
Sarvatt: its linux-image-2.6.35-2-generic at the moment
hagebake: do you mean v2.6.35-rc2-maverick?
Sarvatt: nope
Sarvatt: it's in xorg-edgers I mean
hagebake: oh
Sarvatt: its just not pulled in automatically, linux-image-2.6.35-2-whatever and linux-tools-2.6.35-2 are what ya want
Sarvatt: just copied 2.6.35-3 in there but it'll take a few hours to build
hagebake: cool, now I don't need to download those kernel packages manually
Sarvatt: well you'll need to upgrade to each new abi manually still, you'll notice you get linux-libc-dev updates and that means the new kernel is in there
hagebake: as long as they have the dependencies right I should be fine
hagebake: sysprof asks me to build the kernel module, but module-assistant keeps saying it can't find the kernel headers, even though "prepare" just tries to install a headers package that's already installed. it also complained that it can't create a symlink /usr/src/linux
airlied: latest sysprof shouldn't need a module
hagebake: oh