AndrewR: no, src_bo in textured video path was not what i was thinked it was .. at least putting it strictly in GTT while running in PCI mode doesn't affect tvtime (720x576, yuy2) notiecable .... and error-checking already there, so it was something else killing X, not just some xv buffer allocation failure. Go to bed .... i'll back
AndrewR: (hm. on the other hand ... 720x576 ~ 400 Kpix / frame. bilinear filtering = 4 mem accesses / texel. so 1.6 M * 30 = 48 M. for 2-byte texel it should be around 96 Mbytes/s ... but probably random acces over PCI at this speed techically impossible ..... )
MostAwesomeDude: It's entirely possible that the texel retrieval is accelerated for bilinear lookups.
MostAwesomeDude: Oh, read it wrong. You're talking about texturing from GART?
AndrewR: MostAwesomeDude, yes .... but it very possible i read code wrong, and src-bo just tmp bo mostly for putting image there, not for texturing from ....
bloopletech: How do I work out which chipset series I have? All I know if the ATI name/number
xming: wikipedia
bloopletech: Hmm ... do the Mobility Radeon chipsets use the same Rxxx numbering?
bloopletech: I've tried google/wikipedia - I've found the tech specs, but still can't work it out
xming: again it's all detailed on wikipedia
xming: bloopletech: http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units
bloopletech: xming: Awesome thanks! The other wiki article I was looking didn't have the code names
bloopletech: Apparently my chipset is codenamed 'Redwood' ... searching the page, looks like RV8xx series
airlied: they stopped using the r(v)xxx after 700
bloopletech: airlied, ah thanks
bloopletech: Well my real question then is, does the open source ati driver support the Redwood chipset?
airlied: bloopletech: unaccelerated, preferable to use KMS
bloopletech: Because I'm very vague about whether Ubuntu Lucid Lynx will work with the fglrx driver
bloopletech: airlied, sorry? Not sure what you mean about using KMS
airlied: bloopletech: if you are using the open source driver, kernel modesetting is better at supporting those gpus, though its still all unaccelerated
bloopletech: airlied, ok, thanks
airlied: bloopletech: Ubuntu normally spends a lot of time making ure fglrx works
bloopletech: airlied, yeah but then there's this https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/494699
bloopletech: Actually looks like it may be fixed
airlied: ATI generally support Ubuntu releases with pre-release drivers
bloopletech: airlied, cool, will have to ask in #ati and have a better look around - ATI's attempts at disowning laptop drivers doesn't help
papillon81: may I ask to read this thread: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2010-April/041425.html mentor told me yesterday that the issue caused by the chage in mesa should be fixed on the OSG side.
evil_core: how to set auto GPU/mem clock adjusting for dynpm2?
evil_core: http://www.phoronix.com/forums/showthread.php?t=23395&page=2
evil_core: is that patch usefull/needed for mesa master?
evil_core: and was it AGP specific?
evil_core: http://www.phoronix.com/forums/showthread.php?t=23447&page=5
evil_core: I need to make such change in r100.c or r600.c for r500?
evil_core: nevermind, found it radeon_asic.c ;)
evil_core: why theres no min_power_state_index for r100?
ReeRD: hello
ReeRD: i'm having severe performance problems using xf86-video-ati. openarena on absolutely minimal settings is unplayable. is that expected at this point? is the performance of xf86-video-ati really that bad? the gpu is xpress 1100 (x200m)
evil_core: ReeRD: KMS?
ReeRD: yes, it's on
evil_core: so try UMS
evil_core: and maybe show glxinfo | grep render
evil_core: before
svenstaro: ReeRD: x2100 here, yes it's really that bad
ReeRD: evil_core: if you don't mind, take a look here: http://sidux.com/index.php?name=PNphpBB2&file=viewtopic&t=20654. i posted all the relative info about my setup there
ReeRD: svenstaro: very sad
ReeRD: evil_core: what will i lose by disabling kms?
svenstaro: ReeRD: it's better in UMS
ReeRD: svenstaro: by how much?
svenstaro: if you want better performance and can't code, profile using sysprof and bug people in this channel
evil_core: ReeRD: in mine r500 quake based games lags hardly
evil_core: especially with mesa classic
ReeRD: evil_core: glxgears is 400fps...
svenstaro: ReeRD: some functions in KMS run completelyi n CPU but are accelerated in UMS
svenstaro: ReeRD: yeah thats bad, use UMS
svenstaro: ReeRD: if you want to help make it better, use sysprof and give people in this channel a headups
evil_core: ReeRD: glxgears says nothing
ReeRD: evil_core: probably, but it's still at least a minor indicator, i guess
MVXA: evil_core, glxgears says if the opengl stack is working <.
MVXA: or not
chithead: "glxinfo | grep render" will say
ReeRD: it's working
chithead: glxgears fps is not indicative of anything
ReeRD: evil_core: you said quake engine games lag to you. what's special about them? which ones don't lag?
evil_core: doom3 works best in gallium
evil_core: and it lags damny in UMS
ReeRD: evil_core: i picked up openarena as the least graphic intensive of them all and i was unpleasantly suprised about the performance
ReeRD: evil_core: so didn't even try anyhtig else
evil_core: doom3 works better than quake3/openarena
evil_core: but its r500 case
evil_core: I got zombie colors in ut2k4/gallium
JamesLast: Hi all
JamesLast: i get frequent lockups testing drm-radeon-testing (the new pm code)
JamesLast: if i go to commit db356d8dcbe8d20f1d32d88fd2d1334fda3350ab everything runs stable
JamesLast: after this commit system hangs whenever opengl is in use (eg compositor or openarena)
JamesLast: chipset is an x700 mobility pcie
evil_core: JamesLast: r500?
evil_core: JamesLast: you need additional patches
JamesLast: evil_core: no r400
evil_core: both agd5f and mjg59
evil_core: and it works rock stable on mine r500 :)
JamesLast: evil_core: where do i find those patches ?
evil_core: http://www.codon.org.uk/~mjg59/tmp/radeon_pm/
evil_core: http://people.freedesktop.org/~agd5f/pm-drt/
evil_core: mjg59 0003 needs agd5f 0002
JamesLast: evil_core: those patches ontop of drm-radeon-testing ?
evil_core: yes
evil_core: apply 'em all!
JamesLast: evil_core: ok will try and report back, tnak you
evil_core: no problem
evil_core: agd5f got more problems with me yesterday ;)
twnqx: evil_core: mind fixing my resume? :P
evil_core: twnqx: I am using s2ram currently, but whats the problem?
twnqx: https://bugs.freedesktop.org/show_bug.cgi?id=27822
twnqx: :P
evil_core: 16bit depth is vroken for KMS
twnqx: who would want 16bit anyway
matteo: hi people
matteo: the kernel fails to setup my card in KMS
matteo: https://bugzilla.kernel.org/show_bug.cgi?id=15181
matteo: the card works fine without KMS
abacaba: I'm using 2.6.34rc5 + drm-radeon-testing. Now my dmesg is filling up with messages like this:
abacaba: [ 116.630345] [drm] Requested: e: 50000 m: 40000 p: 16
abacaba: why?
agd5f: abacaba: debugging messages for power management. don't enable dynpm to remove them
evil_core: so 16bit KMS is broken
evil_core: but quake3 runs way smoothe in 16bit
evil_core: and wmaker looks better in 16bit ;)
dileX_: agd5f mjg59: applied your latest patches on top on d-r-t: while loading a 2.1M picture in firefox I get color corruptions. Think its a VRAM/GTT problem
dileX_: [52937.133278] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
agd5f: dileX_: r5xx?
dileX_: yes, rv515
agd5f: dileX_: skip 0001-radeon-Reclock-r500-memory-by-hand.patch
dileX_: hmm, let me look
agd5f: that patch is problematic on some r5xx chips
dileX_: I skipped it
agd5f: if it's a rendering error in ff, then it's probably not related to pm and more likely a bug in the ddx
dileX_: thats Debians ddx in v6.13.0
agd5f: airlied, evil_core: hack to disable the lowest power state on the t60p. http://pastebin.com/nXsWVCD3
agd5f: I'd like to figure out why it doesn't work, but barring that, we can add a quirk table
agd5f: another alternative would be to only use the lowest power mode for the dpms off state
mjg59: agd5f: Mm. I could really do with finding a T60p in the office
mjg59: Weirdly, we only seem to have T61s. And they're all nvidia.
twnqx: meh
twnqx: wanna trade? :X
agd5f: mjg59: here's the rom if your are interested: http://www.botchco.com/alex/t60p-alex.rom
mjg59: agd5f: Thanks, that'll be helpful
AndrewR: i was blind ... there was some oopses in log ... http://pastebin.com/QbTtDucD (but i think i saw bug filled against d-r-t, somewhere in bugzilla)
AndrewR: [Bug 27866]
dileX: AndrewR: is this with latest d-r-t?
AndrewR: dileX, commit 7a1ffce50373c177d3f6eecce52badc40c90e1dd
dileX: AndrewR: I had similiar issues
dileX: "drm/radeon/kms: take vram mutex pointer before derefing object." fixed it on rv515
AndrewR: dileX, but i have rv280 ... may be similar problem still hiding somewhere in r2xx specific parts ....
AndrewR: *parts of code.
evil_core: dynpm algo sucks, xeven urxvt lags when state 0 is eliminated ;)
evil_core: works like when I got ~3% packet loss over ssh ;)
Wizzup: hnsr: There is tortoisegit...
Wizzup: wow, I was way scrolled up, late response
hnsr: Wizzup, sweet!
vsrinivas: hi #radeon;; can anyone here answer a question about the drm r100_copy_blit?
mattst88: vsrinivas, don't ask to ask, just ask.
vsrinivas: okay; i didn't know if this was the right place for it, as its DRM rather than -ati specific?
soreau: vsrinivas: The radeon driver has parts in kernel drm, userspace libdrm, ddx (-ati) and mesa. As long as you're not asking about fglrx, it's fine
vsrinivas: okay;;
vsrinivas: why is it asking for BITBLT_MULTI for its packet type?
vsrinivas: iirc bitblt_multi is restricted to blits within the gpu memory, no?
glisse: vsrinivas: it can also hit system memory through gart
NTU: my friend here is having a problem with r300g on his rs690. it says Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate and then segmentation fault
NTU: when he tries doing glxgears. any ideas?
adamk: I didn't think IGP cards were supported yet.
adamk: But maybe that's a new development.
NTU: hes using 7.9 mesa -devel
adamk: OK, do you know that IGP cards are supposed to work?
MostAwesomeDude: RS690 will segfault, known issue.
NTU: oh ok
NTU: how would one go back to using classic mesa without recompiling mesa? hes using the xorg-edgers PPA.
NTU: just remove .deb from ppa?
zhasha: isn't RS690 using draw?
zhasha: NTU: don't know how he installed it, but since he did, can't he just reinstall the appropriate package for mesa dri drivers?
NTU: yeah thats what i told him
NTU: hes on it right now
NTU: nevermind that :)
verwilst: hello
verwilst: i guess development on this driver is still pretty active?
adamk: Yes.
verwilst: cool
verwilst: i just decided to use this one instead of fglrx ;)
verwilst: not sure whether to choose radeon or radeonhd though :P
NTU: radeon
verwilst: myeah, i guess this chan is a bit biased ;)
NTU: it has KMS and DRI2 and all that good stuff when used with right kernel
verwilst: it's ubuntu 10.04
verwilst: flgrx has a crappy plymouth
NTU: use -ati driver with it since 10.04 uses KMS
verwilst: that was one reason to switch
verwilst: no kms
verwilst: and it crashed on me 3 times since i started using it
verwilst: pretty strange
NTU: kms does lock up some systems in some cases I think
NTU: but for me and my buddies, its fine
verwilst: i have 2 screens, and if i move my mouse quickly between the 2 a couple of times, the pointer starts freaking out and it seems stuck on the connecting screen edges :P
verwilst: only hard reboot helps
verwilst: oh
verwilst: no composite yet though with radeon eh
verwilst: my terminal has fake transparancy :)
adamk: Huh? Composite has been supported on radeon for as far back as I can remember.
adamk: Are you running a compositing manager of some sort?
NTU: uses compiz with Kwin
soreau: NTU: You can't use two WM's at the same time
NTU: so kwin provides its own effects?
Wizzup: yes
NTU: in that case, i dont use kwin with compiz :)
adamk: You may use KDE4 with compiz, however.
soreau: and you can use kwin compositing
soreau: just not kwin and compiz
NTU: ah thats what i use. KDE4 + kwin compositing
NTU: thanks for the correction. :)
vsrinivas: glisse: rockin', thanks;
vsrinivas: also - would mapping some system memory via the gart and doing the same dance that r100_copy_blit does (without the CP) be more reasonable than just reading back from the framebuffer directly?
NTU: are gallium development questions allowed here?
NTU: for radeon?
MostAwesomeDude: Yes.
MostAwesomeDude: #dri-devel is also a fine channel.
NTU: where is PIPE_BUFFER_USAGE_* declared?
MostAwesomeDude: src/gallium/include/pipe/p_defines.h
MostAwesomeDude: Bad sign when I can do that from memory. :3
NTU: hehehe
Dr_Jakob: MostAwesomeDude: then again, its called p_defines.h and it does hold most of the defines.
Dr_Jakob: kinda makes it easy :)
MostAwesomeDude: Dr_Jakob: :3
NTU: where did PIPE_BUFFER_USAGE_INDEX, _PIXEL, _VERTEX etc all go?
MostAwesomeDude: Not sure. git grep is your friend.
NTU: right.. forgot sorry
NTU: yay i found it! the squashed commit changed it from BUFFER to BIND :)
svenstaro: squashed commits are never pretty
airlied: vsrinivas: thats what EXA download from screen does
vsrinivas: airlied: okay; EXA's is able to use the CP; in the situation i'm in, i can't; would it still be reasonable?
vsrinivas: airlied: also, i didn't follow exa's difference between DownloadFromScreenCP and DownloadFromScreenCS...
vsrinivas: (namely, what was
airlied: vsrinivas: CP is non KMS code, CS is the KMS path
vsrinivas: oh okay.
airlied: I suppose you could do dfs without the CP by programming the bit regs directly
airlied: and spinning on the busy bits for completetion
vsrinivas: yea, was what i was thinking to do... is dfs any better than fb reading at that point?
airlied: it should be, though depending on cpu/gpu you may blit back to uncached memory (in AGP case)
airlied: but if you are blocking the CPU wating for the GPU it mihgt not help that much
vsrinivas: ok.
NTU: svenstaro, they confuse me
vsrinivas: is it much work bringing up the CP?
AstralStorm: hello
AstralStorm: are there any plans to add VA API support to radeon driver any soon?
MostAwesomeDude: Not really.
AstralStorm: hmmh
AstralStorm: doesn't really look like a whole lot of work though
AstralStorm: a bunch of specialized shaders?
AstralStorm: can't write them myself, because there's no GLSL 1.20 for r6xx yet
AstralStorm: and I don't know radeon's assembly
evil_core: so buy r500!
AstralStorm: haha
AstralStorm: and rip out the laptop's chip
AstralStorm: solder in a new one, rewire bios to init it
AstralStorm: trivial stuff really
AstralStorm: might as well install coreboot too
AstralStorm: so no, it's not realistic
AstralStorm: actually, what I want to offload is some heavier effects like unsharp mask and specifically lanczos scaling
evil_core: but you can always buy T60p like other devs did!
evil_core: its best laptop ever
evil_core: the last one with FlexView display
AstralStorm: hahaha
AstralStorm: the one that I can't get
AstralStorm: and has a tiny low resolution screen
evil_core: lol
evil_core: I got 1600x1200, how many pixels d oyou have? ^^
evil_core: and its IPS, not crappy TN
AstralStorm: oooh, IPS, neat
AstralStorm: what size?
AstralStorm: I've 1920x1200 here, though TN
evil_core: 15"
AstralStorm: ok color though
AstralStorm: meh
AstralStorm: anything < full HD is suck
AstralStorm: here's 17"
AstralStorm: it's a good mobile desktop
evil_core: too big for a laptop
AstralStorm: ^
evil_core: mine 15"" is too big for me
AstralStorm: actually, it fits well in a backpack
AstralStorm: for really mobile purposes n810 suffices
evil_core: and I dont like widescreens
evil_core: and you dont get blueleds with T60p
AstralStorm: ?
evil_core: 16:9
AstralStorm: heh
evil_core: its 4:3
AstralStorm: so?
evil_core: I play mostly old games
AstralStorm: that makes it "just perfect" for watching movies ;p
AstralStorm: I mean that 16:10
evil_core: so you should change your laptop for T60p ;)
AstralStorm: no
AstralStorm: 1) I shouldn't 2) I don't want to
AstralStorm: 3) it's expensive
evil_core: You want, but you dont know uet that you want ;)
AstralStorm: no really
AstralStorm: I do like this full keyboard thing
AstralStorm: the large *and* high resolution screen
evil_core: useless numpad
AstralStorm: that does support Full HD
AstralStorm: *useful* numpad
AstralStorm: with any good window manager for instance :)
AstralStorm: extra keybinds too
AstralStorm: I'm temporarily switching my mplayer-mt to mplayer-vaapi to see if it helps
AstralStorm: and how much
evil_core: $ echo $((1920*1080)) $((1600*1200))
evil_core: 2073600 1920000
evil_core: theres not much difference ;)
AstralStorm: 1920x1200 actually
evil_core: anyway there are peoples puting QXGA display into T60
AstralStorm: and what matters is width
AstralStorm: you have to scale down a movie to 83% to fit
evil_core: or I can zoom
AstralStorm: which sucks
evil_core: I cando anything I want ;)
AstralStorm: pan-scan is real crap
AstralStorm: I'd like a 1920x1440 screen, but they don't make any laptops
AstralStorm: and that wouldn't be portable at all ;p
AstralStorm: this one is backpack-portable
evil_core: you can asseble yourself
AstralStorm: hahaha
AstralStorm: and you'll get me the parts
AstralStorm: they don't sell by piece
evil_core: there are many ppls puting QXGA screens , exchanging mobos from T61, etc in thinkthinkpadforum
AstralStorm: yeah yeah
AstralStorm: QXGA @ 15"
AstralStorm: what res is it anyway
evil_core: 2048x1536
evil_core: neverball lags both inb UMS and KMS when reflections are enabled
evil_core: w/o it it also lags, but not as much
AstralStorm: how large are the dimensions then?
AstralStorm: evil_core: probably some missing shader being software-emulated
evil_core: I remember that half year ago it was smooth, because I were playing with acceleromater
AstralStorm: hmmh
AstralStorm: a regression ;p
evil_core: in UMS now
evil_core: ALSA lib pcm.c:7236:(snd_pcm_recover) underrun occured
evil_core: ALSA lib pcm.c:7236:(snd_pcm_recover) underrun occured
evil_core: bI want emu10k1 in laptop :(
AstralStorm: cpu not keeping up
AstralStorm: emu10k1 sucks
AstralStorm: ;p
AstralStorm: emu10k2 now...
AstralStorm: (as in Audigy 2 ZS)
evil_core: but you cannot connect it to internal speakers
AstralStorm: ?
evil_core: in laptop
AstralStorm: what does the chip have to do with the codec itself?
AstralStorm: you can use an external codec with emu10k2
evil_core: I also got audigy 2zs platinum from old dekstop
AstralStorm: anyway, HDA is ok
AstralStorm: what's not is the noisy analog part used with most of those
evil_core: AstralStorm: you mean I can use PCMCIA audigy 2zs and put osund on internal speaker or docking station?
AstralStorm: no
AstralStorm: if you're buying something like that, get an Echo Audio card
evil_core: intel_hda is nightmare, it sound like a crap
AstralStorm: e.g. indigo
AstralStorm: no, it sounds *fine* when connected to an external amp
AstralStorm: I'm talking Realtek ALC1200 here
AstralStorm: by fine I mean it fits the specs. The output can't drive headphones really.
AstralStorm: maybe it can drive high impedance ones
evil_core: it doesnt, I got AD1981 and KEF C3/C4 and it doundednot so good comparing to audigy 2zs
AstralStorm: again, *straight out of jack* it sucked
evil_core: analog output on dokicng station is way better, but I would want to use spdif I got on docking station
AstralStorm: connected to external amp, beautiful.
AstralStorm: and I used the same analog output
AstralStorm: funny thing, isn't it?
AstralStorm: so the output is current-starved
AstralStorm: and the amp reduces the load a lot - it's easy to drive
evil_core: yeah I know, ut would be hard to wire C3 directly ;)
evil_core: AstralStorm: anywaym why theres something like "spread spectrum"?
AstralStorm: to reduce electrical noise
AstralStorm: it fudges clock speed some to reduce harmonics
evil_core: it blures out distortions :P
AstralStorm: so instead of a high peak at a harmonic frequency, you get a much lower but wider one
AstralStorm: yep
evil_core: so its hiding ditortions in crappy integrated soundcards ;)
AstralStorm: not just them
AstralStorm: electrical noise spreads
AstralStorm: an active amplifier with reasonable CMRR and correct shielding will cut it out
AstralStorm: those amps in the integrated systems just can't be shielded well
AstralStorm: there's no space for it
AstralStorm: or rather, price considerations ;p
AstralStorm: plus the $0.1 delta-sigma amp can suck
AstralStorm: the digital part of HDA is well-designed though
AstralStorm: apart from lack of hardware mixing
AstralStorm: (buffers necessary for that are expensive)