Revellion: nice that GPU would cook nice eggs XD
bobbens: reminds me of an old pentium mod, where they used a dial to control the CPU voltage to cook sausages with the CPU :)
edgecase: using DynamicClocks "on" made it hotter?
elwood: hi all
elwood: i have a M52 chipset, which driver i have to use? where i can find informations about radeon' driver?
michaellarabel: elwood: The xf86-video-ati or xf86-video-radeonhd works for you.
michaellarabel: What kind of information you looking for?
elwood: michaellarabel, i am using a debian instable, and i got from tvtime " no overlay support". I have to pass some options?the new xorg.conf is getting me crazy!
ejs1920: elwood: you need latest git version for textured video support
elwood: ejs1920, well, i can get the source and simply compile it? there is some howto?
ejs1920: i don't know of any howto
elwood: ejs1920, so i will use git and try it
elwood: ejs1920, thanks
ejs1920: good luck
eboettcher: there should be on the wiki
elwood: eboettcher, thanks!
eboettcher: AFAIK that won't build for you unless you revert the DRI2 changes
eboettcher: elwood: that being git mesa
eboettcher: let me check
elwood: eboettcher, i need to build the radeon module, but the procedure is the same
elwood: git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/
ejs1920: you want git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
ejs1920: and possibly git://anongit.freedesktop.org/git/mesa/drm
elwood: ejs1920, perfect, now i am doing the first one
elwood: well .xinerama error :)
ejs1920: i'm not familiar with xinerama
elwood: i 'm searching on google :) it always knows
elwood: well i need a different version of xorg. now i got it :)
ejs1920: i have xf86-video-ati git running fine with x server 220.127.116.11
ejs1920: you shouldn't need x server 1.5 pre-release just for the radeon driver
elwood: ejs1920, this is what i get http://pastebin.com/m4632d488
ejs1920: you need the x protocol headers installed
ejs1920: i'll need to check what debian package that is
ejs1920: xorg-x11-proto-devel on fedora
elwood: ejs1920, great, i am looking in the apt
ejs1920: x11proto-core-dev is one
ejs1920: x11proto-xf86misc-dev is another
elwood: x11proto-xf86misc-dev this is the right one
elwood: ejs1920, compiled :) now make install and crossing fingers
elwood: well now i got it installed, i need to remove the deb package right?
ejs1920: depends where you installed it
elwood: i used --prefix=/usr
ejs1920: then it will have overwritten the ones from the .deb
ejs1920: removing the deb will remove the new driver
elwood: ejs1920, but to have a clean installation i can remove the deb and reinstall the new?
ejs1920: alternatively, keep the new in your home directory somewhere and adjust ModulePath in xorg.conf
elwood: ejs1920, this is also interesting, modinfo radeon which version should show me?
ejs1920: that's the kernel module
ejs1920: did you install new drm?
ejs1920: well my /sbin/modinfo radeon doesn't give any version, i'm using the ones from kernel 2.6.24
elwood: ejs1920, i just recompiled the -ati from git, and getting dri error in xorg's log. maybe i need to recompile also the drm. I'm on 2.6.22
ejs1920: what's the error?
ejs1920: there's no 3d (dri) for your card yet
elwood: ejs1920, drmOpenDevice: open result is -1, (No such device) (most of probes) and (WW) RADEON(0): Direct rendering disabled
elwood: ok so it's normal?
ejs1920: it's normal
ejs1920: if you have problems with xvideo, try updating drm
elwood: yes i will try
elwood: there is a feed rss to be updated with new radeon?
ejs1920: not that i know of
ejs1920: phoronix.com will post articles about new releases and features
ejs1920: maybe with rss
elwood: ejs1920, thanks, you help me a lot
ejs1920: after all that, do you have xvideo working?
ejs1920: xvinfo should list "Radeon Textured Video"
elwood: ejs1920, i am trying to recompile drm
elwood: ejs1920, by the way now i am free from fglrx :) that's a good thing for me
ejs1920: libdrm doesn't need much to build, you need your kernel source install to build the new kernel modules
ejs1920: in the linux-core directory
elwood: ejs1920, i need time to get, i am on umts :(
ejs1920: ah, right
elwood: this is the first problem here
ejs1920: by the way, once git-clone finishes, you keep the folder and do git-pull to update the sources
elwood: ejs1920, yes git seems similar to svn
ejs1920: it is
elwood: drm done
elwood_: it works, still no 3d but it works
spreeuw: hey, git is broken for some reason
spreeuw: on an x700 here
spreeuw: synced drm and xf86-ati too
ghepeu: after three X crashes or lockups in a day, I reverted to xserver 18.104.22.168 and mesa 7.0.3 from git
ghepeu: then I tried x11perf and the char/s (xf86-video-ati git, EXANoComposite on) went from ~65000 to 112000
ghepeu: there's something bad in git master
osiris_: airlied or glisse: i've tracked down rs690 texturing problem.
glisse: osiris_: what is it ?
osiris_: glisse: it's tiling related
osiris_: glisse: enabling disabled code in r300SetTexImages fixes it partially
osiris_: glisse: there seem to be minor problem with mipmap filtering left
glisse: i am pulling code to take a look
osiris_: glisse: it looks like last mipmap isn't uploaded correcly
glisse: osiris_: strange
glisse: what does it look like without tiling enabled ?
osiris_: glisse: one moment, i'll make a screenshot
osiris_: glisse: texobj mesa demo http://img153.imageshack.us/my.php?image=texobjmv1.png
glisse: osiris_: could you edit the code to unset micro
glisse: after the code you activated
glisse: also activate debug texture texture to see the debug message
osiris_: glisse: the problem remains, here's console output http://pastebin.ca/972799
glisse: can you provide console output of same program with micro_tile enabled this time
otaylor: Question: why is some stuff computed by "Prepare" functions stored in static local variables and some in RADEONInfoRec?
otaylor: (specifically I'm looking at is_transform/transform in radeon_exa_render.c)
osiris_: glisse: with microblocks tiled: http://pastebin.ca/972807
glisse: osiris_: in this run texture a properly show right ?
osiris_: glisse: yes
spstarr: anyone see radeon locking issues ?
spstarr: i posted a log in /scroll
ghepeu: spstarr, what kind of locking issues?
spstarr: lets see if i have them in log
glisse: spstarr: what is your version of xorg ? look like some lock problem, iirc some old xorg did have that with aiglx
spstarr: X.Org X Server 22.214.171.1241 (1.5.0 RC 1)
spstarr: I am using rawhide's X
spstarr: uild ID: xorg-x11-server 126.96.36.1991-17.20080401.fc9
glisse: disabling aiglx help ?
spstarr: well, yeah then i dont get drm locking issues :)
spstarr: messages:Apr 4 21:43:36 segfault kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, held 0 owner f49bd840 f50df63
spstarr: start/restart, idle
osiris_: agd5f: is there a reason why anisotropic filtering bits are missing in r500 3d docs?
spstarr: glisse: this is a rv350
glisse: spstarr: so without aiglx you get dri and no locking problem ?
glisse: maybe somethings wrong in ddx
otaylor: glisse: second, Filed a bug about lockups on radeon_+rawhide this morning, let me find the bug #
spstarr: glisse: i didnt disable aiglx in xorg.conf
spstarr: hearts otaylor
glisse: osiris_: i was relooing to doc their doesn't seem to be any special case for tiled texture
otaylor: glisse: Is https://bugzilla.redhat.com/show_bug.cgi?id=441058 what you are seeing?
otaylor: oh, sorry s/glisse/spstarr/
spstarr: otaylor: I have a T42 and RV350 chipset
spstarr: i'd say yes
spstarr: because also
spstarr: when starting Fedora rawhide with rhgb THEN having X restart i get a gpu wedge
spstarr: black screen and no activity
spstarr: but its random
otaylor: spstarr: Hmm, actually I think what you are seeing may be different, I wasn't seeing the radeon_cp_start stuff
spstarr: I do see this behavour though:
spstarr: This happens maybe once every 3-5 restarts of the server. I've never seen
spstarr: it on the first start of the X server, so I suspect it might be related
spstarr: to the shutdown of the previous X server. <--
otaylor: https://bugzilla.redhat.com/show_bug.cgi?id=242746 has that mentioned
spstarr: something is not resetting the video card's state on exit of X?
otaylor: spstarr: Hmm, maybe they are related, or maybe the "radeon_cp_start" message is just spurious and unrelated
osiris_: glisse: chapter 2 is about tiling, and there are some bits in TX_OFFSET regs (0x4540-0x457c)
spstarr: i can confirm 242746
otaylor: spstarr: Probably. I talked briefly to it about it to airlied a few days ago, and he seemed to think he had some idea what it might be
spstarr: i can confirm both of those bugs :)
otaylor: spstarr: but hadn't looked into it into detail yet, I filed the bug today so he wouldn't forget about it :-)
spstarr: adds himself to both
glisse: osiris_: i meant that there doesn't seems to be any special case related to tiling which would make engine behave differently
otaylor: spstarr: It's been annoying me a bunch because I've been a) debugging login from GDM to the desktop b) doing some X server hacking. Both of which tend to need frequent restarts
spstarr: Yes I can see that as being annoying
osiris_: glisse: isn't tiling all about how 2d image is to be stored by driver, and read by hardware in memory?
otaylor: spstarr: my kernel-driver/drm knowledge is minimal or I'd have tried to fix it myself
spstarr: ok, im on the watchlist with both of those bugs
glisse: osiris_: yes but hw should behave the same ie work wether texture is tiled or not :)
spstarr: otaylor: kernelspace scares me :)
osiris_: glisse: I have a patch proposal about pipe count config: http://pastebin.ca/972847
osiris_: glisse: do you know why texture tiling is disabled now?
glisse: osiris_: iirc there is problem with it & multitexture
glisse: osiris_: this texture problem exist with bigger texture ?
glisse: i am looking through code and this is only think that might explain it
glisse: in fact in the wrong case half of the texture is right
glisse: osiris_: multiarb for instance
osiris_: glisse: looks like the problem exists only for small textures
Revellion: hmm, anyone know a possible workaround the 2048x2048 texture limit? :S
Revellion: for cases with Compiz and desktops being larger than that the root-window area is limited at the border of 2048
Revellion: atleast on older HW, newer might possibly support bigger texture sizes obviously
arekm: afaik there is some way but needs coding stuff into driver
otaylor: Revellion: it can be worked around in the software in some cases, though it is bit of a pain. I did that for luminocity, since I was testing on ancient hardware with 512x512 texture limits
otaylor: Revellion: The easiest fix here might be to get nautilus (assuming GNOME) to use a separate root window window per monitor
Revellion: otaylor: on which layer?, application or driver?
Revellion: otaylor: easiest but not possibly ideal
Revellion: otaylor: we got other DE's too which has the same issue
otaylor: Revellion: By in "software" I meant "in the compositing manager" ... i.e., compiz or luminocity
Revellion: XFCE4's Xfdesktop and KDE's own
otaylor: Revellion: Well, they can get the same fix
Revellion: also the issue would arrise if people have an app with a window size larger than those dimensions :S
otaylor: Revellion: using smaller desktop windows is going to be a memory win too if the different monitors are not the same height
otaylor: Revellion: Yeah, but app windows than a single monitor are pathological, and monitors bigger than 2048 pixels in one dimension are not ... mainstream ... at the moment
otaylor: Revellion: We can hope that hardware limits on texture sizes will stay ahead of monitor sizes
Revellion: *looks at a certain very high-resolution widescreen monitor*
Revellion: dual-DVI connections powering a 2560x1600
Revellion: could hit a snag there :|
otaylor: Revellion: I'm pretty positive that a driver fix is simply not feasible, the compiz fix is feasible, but going to make things a lot hairier inside compiz
otaylor: Revellion: But if you are looking for a several-week challenging project...
Revellion: for surfaces in games covering larger areas than 2048x2048 it seems it's a simple matter of just putting another area near it
Revellion: in the case of those giga-textures 32768x32768 in some games
Revellion: it seems like a big checkerboard of 2048s
Revellion: so in that case compiz would have to somehow in some odd way split 1 window into multiple textures
Revellion: and pretend it has no limits :|
Revellion: hackish :\
otaylor: Revellion: Yeah, that's the basic approach, but preventing seams at the edges can be hard, especially when scaling down.
Revellion: to not mention syncing :\
otaylor: Revellion: as long as you stay 1:1 things aren't so bad, and some people might not care much about the seams if their window worked at all
otaylor: Revellion: The other big issue here is that the idea texture-for-pixmap extension simply falls over when your pixmaps exceed the possible texture size
otaylor: Revellion: I think newer hardware should support 4096x4096 ... maybe you should just consider that part of the price of your spiffy monitor
Revellion: well i was just brainstorming the case where someone could possibly have a fairly high resoluted monitor on old hardware
Revellion: the real machine that monitor is on has a nvidia more than capable to handle the texture size
Revellion: and if that is the case how should it be handled. there is inevitably performance degradation but atleast should work somewhat
otaylor: Revellion: well, you can always brainstorm yourself into a corner :-)
Revellion: but nah i got an emergency break in place to pull ;P
Revellion: a bit of an continuation of my old quest to see how to handle larger than 2048x2048 3D rendering contexts on Radeon R200 hardware
Revellion: i read somewhere that the r300's 3D limit is 3960 something is that true or?
otaylor: Looks like 2048 on R300, 4096 on R500
Revellion: otaylor: ouch, then that rumour is false :\
otaylor: Revellion: (from the docs for the TXWIDTH register)
Revellion: otaylor: well the docs should be pretty definite XD
otaylor: Revellion: You can use a larger "pitch", so you could slice up a large pixmap into multiple textures without having to make a copy, but a single texture operation would seem limited
Revellion: hmm Textured Video is quite nice on r200, but the 2048x2048 limit can be noticed :)
Revellion: even on non 3D/non composited :)
Revellion: drag window past 2048 to the right on 3200x1200 and the video abrutely stops
otaylor: http://bugs.freedesktop.org/show_bug.cgi?id=15371, a quite useful patch if I say so myself
elwood: well i'm trying texture on m52 , not so simple
elwood: it's normal that X see the M52 and then dri says R500?
Revellion: M52 is just a model numeration
Revellion: r500 is the chip
Revellion: or chip-family
elwood: ok so i keep going :)
elwood: i have recompiled xf86-ati mesa and drm, it's all or i need something ?
Revellion: otaylor: nice patch indeed
Revellion: elwood: trying to get textured video going?
Revellion: you really only need xf86-video-ati from git for that
Revellion: and not much else
elwood: Revellion, yes and maybe 3d :)
Revellion: if you got a fairly recent mesa
Revellion: 3D is a bit less likely to get going
elwood: Revellion, i've just compiled the one from git
Revellion: and switched on EXA?
elwood: Revellion, yes i did, now i need just and X reboot and crossing finger
elwood: Revellion, i need it to use tvtime :P
Revellion: textured video ? :)
elwood: you got it
Revellion: otaylor: that patch looks jummy
Revellion: contemplates testing it
Revellion: elwood: aah :)
Revellion: or for any decent video playback for that matter XD
elwood: thanks Revellion
Revellion: restarted X? :)
elwood: not yet
Revellion: elwood: it works? :)
elwood: i'm feeling brave right now
elwood: now i can restart, see you soon (i hope)
otaylor: Revellion: I think it won't apply without http://bugs.freedesktop.org/show_bug.cgi?id=15334 applied first. If I make a patch or two more I probably should put a tree up somewhere
Revellion: well i'm fine with testing it seeing as i got hardware affected by it :)
Revellion: otaylor: against git master right?
otaylor: Revellion: Yeah
Revellion: so the patch affects r100,r200,r300 ?
otaylor: r100-r500, but I don't think the r100/200 parts are working right. (hmm, should add a comment to that bug)
otaylor: "don't think they are" => "there's no way they could be"
airlied: osiris_: I noticed that before...
Revellion: git master checked out
Revellion: patches applied
airlied: osiris_: I wanted to get the texture patches that are dying in a bug upsteram to fix
Revellion: and lets see if it breaks horribly
airlied: osiris_: rs690 changed something comapred to r300 engine
osiris_: airlied: I should have asked before I started investigating the problem. I spent couple of days tracking the bug
airlied: osiris_: yeah you were logged off when I remembered I started to look at it.
airlied: osiris_: but their are some patches to fix radeon multi-texturing sitting in a bug.
airlied: fixing those might actually be the correct answer
glisse: Revellion: the solution would be to have tiled texture in TFP
glisse: airlied: osiris_ problem is due to us badly bliting the texture
Revellion: glisse: which means TFP would have to be extended to do that?
Revellion: then submit that down the line?
glisse: Revellion: which means that compiz would need a rewrite or massive modification to handle
glisse: their wouldn't be any driver modification
glisse: all common code
airlied: osiris_: bug 8056
elwood: whispers : now i don't know if is a mine fault or driver, whast i should check on X logs?
Revellion: so TFP couldn't possibly be made to act as if it had no limits?, and perform the tiling somehow?. or would that be way ugly?
otaylor: Revellion: Oh, fixing this up for R200 is going to be easy, found the right register values
Revellion: otaylor: oooh, any patch that will be ready soon for me to test for the heck of it?
Revellion: cause i guess this build i made just now is most likely not gonna work seeing your earlier statement :)
glisse: Revellion: you need uper layer (compiz whatever) to deal with it
Revellion: glisse: ah
otaylor: Revellion: yeah, it's only going to work about 25%. Give me a couple of minutes
glisse: basicly this means that compiz effect shouldn't only think that there is one texture per window but their might be several texture per window
Revellion: otaylor: sure, i'll be happy to test em :)
otaylor: Revellion: Try http://bugs.freedesktop.org/attachment.cgi?id=15709&action=edit on top of the other one
Revellion: otaylor: sure
Revellion: patching and building
Revellion: applied cleanly
Revellion: any testcase one could use?
Revellion: like a cairo example?
otaylor: http://fishsoup.net/tmp/repeats.py is my test case; if it comes up looking like http://fishsoup.net/tmp/repeats.png
otaylor: and if you press the p key and it the borders of the images switch back and forth between straight and indented and nothing else changes
otaylor: if you can hold down the p key and it the image switches back and forth rapidly , then you not only have non-buggy acceleration, you have good acceleration
otaylor: Oh, other thing, this is all about exa
Revellion: yeah noticed that early on :P
Revellion: pre-r100/r200 patch testing atm with repeats.py
Revellion: and it does some funky things if p is held :)
Revellion: some rendering gets a bit fubar
Revellion: to be expected right? :)
otaylor: So you need Option "AccelMethod" "EXA" in your xorg.conf
Revellion: otaylor: already have :)
otaylor: Revellion: Yeah, I don't expect workingness at all before my patches
otaylor: Revellion: a) the radeon code is buggy b) it usually falls back to buggy fallback code
Revellion: mhm, i've noticed that from time for the long time i've been atleast using the r200 and r300's
elwood: otaylor, but it's a great work
Revellion: r300 not much now since the laptop i have it on broke down awhile ago
otaylor: Revellion: (Which I also have patches to fix, but they won't be hit once you have the fixed atio driver)
Revellion: restarting X with new build
Revellion: otaylor: welcome back
otaylor: Should avoid accidentally hitting alt-f4 (I blame my new keyboard)
osiris_: airlied: so this patch is using bitblt packet3 to send textures to video memory, right?
airlied: osiris_: yes.. it needs kernel changes..
airlied: osiris_: but it does more correct uploads.
Revellion: otaylor: ill post up a screenshot of a repeats.py run, before P for ya to check if it matches you're expectations
otaylor: Revellion: Sure great. It's not exactly the most automated test :-)
Revellion: indeed not
Revellion: but atleast something
otaylor: With the magic 20 or so single letters you can type to change things, completely undocumented....
Revellion: otaylor: http://suzuka.anirev.net/~revellion/repeats-r200.png
otaylor: Certainly close
otaylor: There are a few things that are off though
Revellion: some rendering is subtly different
Revellion: only some fills seems to differ
Revellion: while the majority stays the same
osiris_: airlied: so why those patches aren't pushed upstream?
airlied: osiris_: some pepople said they break stuff I think
glisse: osiris_: iirc still issues with them
glisse: osiris_: so big texture are broken even with tiling ?
otaylor: Revellion: If you hit space, you'll get numbers. THat will help me explain what's off :-)
Revellion: white text on green, aaarrgh my eyes :P
osiris_: glisse: no, big textures seems to be ok with/without tiling. small textures are broken when tiling is disabled
airlied: yeah less that 16x16 seemed busted different on rs690
otaylor: Revellion: Interesting, more stuff broke on that sshot
Revellion: otaylor: compared to?
glisse: osiris_: but what there is still issue with texturing on rs690 beside small texture ?
glisse: i haven't followed this closely :)
osiris_: airlied: any chance amd could give us some info how to deal with small texs on rs690?
glisse: so i might have miss view episodes
airlied: osiris_: well the bug has the answer I think..
airlied: osiris_: we need to use tiling.
glisse: airlied: i think that's just the blit which is broken
otaylor: Revellion: The first one
Revellion: otaylor: can't see any noticeable difference between em
Revellion: oh wait nvm i do
otaylor: I ddund't notice 4x4 and 8x8 in the upper left being wrong, for example
Revellion: on the 4x16 too
glisse: i haven't checked deeply the code but it seems that it doesn't blit properly
osiris_: glisse: when I enable tiling, everything seems to be ok. with tiling disabled small textures are busted
Revellion: otaylor: odd behaviour
osiris_: glisse: and with tiling enabled there are some minor filtering problems
airlied: glisse: it works fine on !rs690 so something changed.
otaylor: Revellion: Well, it's not that odd, really, consdiering how busted things were on R300 before I started fixing it up
Revellion: yeah true
glisse: airlied: side note while i still have it in mind i think we can do mimap on npot texture
glisse: for r3xx/r4xx/r5xx trick seems to pad npot to a power of two
glisse: need to check spec if we then can actualy enable the arb extension
otaylor: Revellion: I'm thinking that there are two separate things going on here
otaylor: A) Something with small width textures (width == 4 || width == 8)
glisse: anyway zzzZZZzz time
otaylor: B) On the R300 you can repeat a NPOTxPOT texture in the POT direction as long and not in the NPOT direction, and that seems like it might not be working here
otaylor: B) might explain 23x1, 16x23, 32x23
Revellion: most of the rendering looks correct when looking at previous shot and new shot with subtract as the compositing mode
Revellion: just those odd one's
otaylor: Revellion: If you drag a window over the top, do you get constantly changing images where it is broken?
otaylor: (this wont' work if you are running a compositing manager, of course)
Revellion: non composited here so no worries
Revellion: otaylor: indeed
Revellion: the one that looked almost like a "coam" on one of the screenshot alternates
Revellion: between having lines sticking up 2-3pixels
Revellion: to disappearing on redraw due to moving the window above it
Revellion: otaylor: subtle changes but visible
otaylor: Oh, 4x16 in the upper middle?
Revellion: that one
Revellion: only one of i really noticed it clearly on
Revellion: but some others mightve behaved exactly the same
otaylor: Actually what I'm interesting in is whether that happens with the 23x1 at the upper right
otaylor: Actually, never mind,I know exactly what is going on there
otaylor: (it's sampling 16 pixels of source and stretching them out to 32 pixels)
otaylor: Revellion: Hmm, but that doesn't explain to me why 23x8 and so forth are exactly right
otaylor: If you want to do another build, can you edit radeon_exa.c and change #define RADEON_TRACE_FALL 0 to #define RADEON_TRACE_FALL 1 ?
Revellion: the build doesn't take very long
otaylor: Revellion: Then we'll be able to tell if the ones that are correct are ending up with software fallbacks
Revellion: otaylor: doing build nr4 with TRACE at 1
Revellion: installing it
Revellion: restarting X
otaylor: So the basic question is whether stuff about fallbacks gets added to Xorg.log when you hit 'r' to redraw everything
otaylor: (Hmm, that was an easier thing to do than dragging a window across the top...)
Revellion: otaylor: lol indeed
otaylor: there likely will be some stuff about fallbacks from the rest of your desktop
otaylor: And you'll get a whole bunch of stuff about falblacks if you turn text on (though that's something else that needs to be looked into in the driver)
Revellion: gonna see if i can filter out the entries that arent relevant
Revellion: otaylor: didn't clean out the whitespace ahead. hope it aint a problem
otaylor: Revellion: Ahah, yeah, what i was guessing at
otaylor: Ah partly stupidity on my part
otaylor: Revellion: thinking out loud mostly, part of what's going wrong is something I should have noticed from the code
leio: I see Owen is fixing my r200, nice :)
Revellion: how convinient :)
otaylor: OK, I completely understand what's going on with the width and height 23 columns (famous last words), and I can fix it, though the result isn't going to be as speedy as on the R200, but still should be way better than software fallbacks
Revellion: otaylor: any improvement be it minimal is still better than baseline performance with software fallbacks :D
otaylor: basically we need to draw every copy of the repeat separately, instead of being able to do entire columns/rows at once
spstarr: r200 is still faster than the r3xx :(
Revellion: spstarr: err, care to go into detail on that? :\
spstarr: Revellion: im still hitting many many software rendering fallbacks :/
leio: spstarr: r200 is very very very slow right now, I don't believe r300 can be worse... maybe with these patches it can ;p
Revellion: spstarr: aaah
spstarr: now, I could switch back to XAA
ghepeu: there's something wrong in the server, I think
Revellion: well this r200 with the release 6.8.0 was quite horrible with EXA
ghepeu: in the software implementation
Revellion: using a driver built from git master made a huge difference
spstarr: well this is git master
otaylor: Basically with xaa you get software rendering, which is oK, with exa, you get moving pixmaps back in forth drawing half with software, half with hardware
spstarr: right, but what makes no sense to me is why XAA is faster, when its all software rendering
otaylor: which is much worse than software. But once we eliminate all the fallbacks, should be much better :-)
spstarr: otaylor: theres a lot of fallbacks
ghepeu: without render acceeration (EXANoComposite) xserver 1.4.1 gives 110000 char/s, xserver git gives ~65000
leio: ping pong over relatively slow AGP bus
Revellion: meaning lots of ugly memcpy's
otaylor: spstarr: because software rendering isn't slow. Reading a pixmap back from video memory is slooow
leio: the only fallbacks I get on r200 are from NPOT and component alpha, I assume those patches intend to take care of the NPOT
spstarr: otaylor: which video memory will it use?
leio: though with agd5f we concluded the fallbacks aren't that big of a problem for my slowness
otaylor: Revellion: OK, I'm having some trouble figuring out what log messages come from what
otaylor: leio: are you using a recent gnome theme
leio: oh yeah
Revellion: otaylor: hmm?
otaylor: Revellion: going to give you some "driving instructions" here
leio: 2.22 one
spstarr: leio: do we have benchmark tools to test the r300?
spstarr: i want to give as much feedback i can
Revellion: otaylor: hehe
leio: but simple theme and other are terribly slow too
otaylor: leio: antialiased text?
spstarr: leio: tools that would trip fallback paths
spstarr: or some way of reporting a fallback when it occurs
leio: I'm hearing about glyphs going up one by one
spstarr: so Xorg people could figure out those paths
otaylor: leio: sorry, I mean sub-pxiel antialiased text? (color fringies)
leio: that too
spstarr: maybe some sort of xorgoops
leio: I'm willing to sacrifice that if you tell it's much better with regular anti-aliasing
spstarr: or have the X server dump a stack trace when a fallback to software rendering occurs
otaylor: Revellion: hit t three times and o once
spstarr: then it might help narrow down things no?
otaylor: Revellion: That should give you the upper right hand corner of what you were looking at earlier
otaylor: leio: I think sub-pixel antialiased text is all fallbacks at the moment (probably not for good reasons), and I think that's going to cause bad slowness
Revellion: otaylor: http://suzuka.anirev.net/~revellion/done.log
Revellion: otaylor: http://suzuka.anirev.net/~revellion/done.png
Revellion: logs and screenshot of result
leio: otaylor: probably the component alpha stuff I'm seeing in fallbacks?
Revellion: logs are from when repeats was already started before hand
leio: R200CheckComposite: Component alpha not supported with source alpha and source value blending.
leio: R200CheckCompositeTexture: NPOT repeat unsupported (8x22)
leio: these are my fallbacks on last check
leio: have TRACE_FALL disabled atm, my /var got full of 200MB X logs
otaylor: Revellion: Actually, what I'd like to get is _exactly_ what messages appear when you hit "r" once
Revellion: otaylor: sure
spstarr: or am I just talking crazy ? :)
Revellion: just gotta turn off some sources of extra output,
otaylor: Revellion: Which may be determinable from what you've given me, I'm just getting a little confused :-)
otaylor: leio: Yeah, thoughs are a) antialised text and b) gradietns probably from your theme
otaylor: leio: the patches that Revellion is testing shoudl fix b), I think a) is fixable as well
Revellion: otaylor: http://suzuka.anirev.net/~revellion/r-once.log
Revellion: this is cleanly just from repeats.py already up
Revellion: then r
Revellion: and output that followed it
leio: I believe agd5f was not sure if the r200 pixel shader supports fixing it or not and that some investigation is necessary. I can check if some stuff goes away without subpixel smoothing soon, when I can restart
Revellion: oops some garbage at the start of the log file
otaylor: Revellion: Somehow your files are ending up with a huge block of null bytes at the front ... not a big problem
Revellion: otaylor: yeah i just noticed
Revellion: tried to less it and got the same
Revellion: cleaned version up in its place
Revellion: if you want it
otaylor: I figured it out
otaylor: OK, that log is nice and clean ... I was getting confused by the width 193 textures in the other one and so forth
otaylor: That probably was coming from other sources
otaylor: So the fallbacks are just the ones I was expecting
otaylor: Very helpful
Revellion: R200TextureSetupCP: Width 8 and pitch 64 not compatible for repeat <= that one is spammed fairly a lot :)
Revellion: 193 is might been firefox
otaylor: Revellion: So the interesting thing is that the first two columns (4,8 wide) which have corruption, are apparently being with software fallbacks
Revellion: i closed it down and got cleaner results
otaylor: Revellion: Just to check if you hit 'd', repeats.py will dump a file called repeats.png to disk in it's current directory. Does that look fine?
otaylor: (rendered in software with libpixman directly from cairo, instead of involving the X server)
Revellion: comparing them
Revellion: otaylor: looks better ye
Revellion: no greeny mess
Revellion: on some of them
Revellion: dumped version from 'd'
otaylor: ok, no real surprise there, so probably means that it's something going wrong with copying the small textures video => host memory
spstarr: otaylor: you dont have any test tools for me to try for the r300 do you? :)
otaylor: spstarr: well, I know how things work on the rv350 :-). But if you want to build an ati driver with the patches from http://bugs.freedesktop.org/show_bug.cgi?id=15371 and http://bugs.freedesktop.org/show_bug.cgi?id=15333 (opposite order), it will be nice and fast at drawing theme gradients :-)
spstarr: for 15371 both of those or the latter?
otaylor: spstarr: Well, only the first matters, the second one is R100+R200 specific
spstarr: oh yes
Revellion: so basically the issue on the r200 is mostly the correctness of the rendering?
Revellion: the operation is not hitting software fallbacks or?
Revellion: or is it still slipping onto it?
otaylor: Revellion: As I understand it, you *are* hitting software fallbacks, and those are rendering wrong :-)
spstarr: syncs master
otaylor: Revellion: I can fix the patch so you donm't hit software fallbacks in this case, but the bug (whatever it is) with the fallbacks needs fixing
spstarr: otaylor: doesnt apply
spstarr: otaylor: against master?
spstarr: only one applies
spstarr: r300-repeating-source.patch goes in
otaylor: spstarrOh sorry, I told you the wrong bug number
otaylor: http://bugs.freedesktop.org/show_bug.cgi?id=15334 is the first patch, then the two (or just the first) from http://bugs.freedesktop.org/show_bug.cgi?id=15371
spstarr: r300-repeating-source.patch is ok and another one ?
otaylor: r300-repeating-source.patch should already be in master
otaylor: So I'm not sure how it applied
spstarr: repulls master
Revellion: be right back
spstarr: it looks to be merged
spstarr: applied both
otaylor: Revellion: OK, I think I'm going to declare "enough" on this for today. If you add yourself to the Cc on 15371, I'll post updates there, or maybe we can some other time take a look at this in a debugger. I think the next step is trying to figure out what code is actually rendering the incorrect copies
leio: otaylor: the r100/r200 followup fixup has the bug number wrong in commit message s/14333/15333, not that it's important
spstarr: otaylor: so i just will drop ati_drv.so and restart X
otaylor: leio: Yeah, I'm not exactly that good at that sort of detail :-)
spstarr: dont care for the others, no multimedia on the rv350 anyway
leio: otaylor: so those three patches should make life better for me?
otaylor: leio: r200? it will make things better, but probably not enough good to be worth it for now
leio: you mean worth using my computer? ;p
otaylor: leio: If you want to use your computer a) go to a simple gtk+ theme b) turn off antialiased text or go back to xaa :-)
leio: it's that bad, really. Combined with complete joke that is CFS scheduler in linux 2.6.24...
otaylor: sorry, subpixel-antialiased
otaylor: leio: Hopefully we can get these exa issues sorted out.
spstarr: ok here goes.
otaylor: leio: I can believe the "that bad" ... the reason I've been working on it is it was pretty hard to use on my laptop, and that presumably has more horsepower than a box with a r200
leio: you have a r300 or something then?
leio: I have a bloody 2.8GHz prescott, should be flying enough, but... ;p
otaylor: leio: Ah, desktop. May be less correlation between video card and cpu there :-)
spstarr: otaylor: interesting
spstarr: things seem faster
spstarr: what did those patches change in EXA? (without looking at the code)
otaylor: spstarr: big thing is no sw fallbacks for cairo horizontal and vertical gradients
leio: yeah, I actually swapped the r300 it came with with a r200, though own both still
spstarr: for cairo...
Revellion: otaylor: ah ok sure
spstarr: and what if im in KDE 4.1? :)
leio: then you are in the future
otaylor: spstarr: probably similar, unless Arthur is using server-side gradients (which lars knoll did implement after all), in which case you and everybody else will be completely screwed by the lack of acceleration :-)
spstarr: well something seems faster
spstarr: or maybe im delusional :)
spstarr: or git master has changes that i got as bonus
spstarr: (my git was a few days out)
otaylor: spstarr: I wouldn't be surprised ... a number of things that apps want to do will be much faster with this patch
spstarr: any other things you want me to test?
spstarr: or any benchmarking tools for r3xx?
otaylor: spstarr: Not really
Revellion: added myself into the cc
Revellion: going to hit the bunk myself i see
o_away: Revellion: BTW, thanks a lot for all the help. R200 users everywhere will thank you.
Revellion: 02:42 in the night
Revellion: o_away: you're welcome
Revellion: talk to ya later :D