rx__: Hello 3d world!
rx__: r500test?
airlied: rx__: hmm?
rx__: is that new? :P
airlied: rx__: thats the branch I started playing on a few days ago.
rx__: wasn't there a r500-fp branch
airlied: rx__: thats in the drm.
airlied: I lose at consistent naming.
rx__: ohh
rx__: yeah just caught my error
rx__: your RV530 detection sure is amusing
airlied: rx__: hehe .. bbl.
mcgreg: AMD Releases Microcode For All GPUs - thats sounds great , except for one things -> *This is the microcode found in the fglrx driver and it covers the Radeon R100 to R600 product families.*
mcgreg: since my experiences with fglrx aren't that great
mcgreg: but I uess thats just lack of knowledge from my side ;)
rx__: run some tests.. make sure there's no regression from using the new microcode
mcgreg: I suppose I'd need to compile kernel modules for that?
mcgreg: brb
berniyh: airlied: for the information, checked out the lastest mesa+xf86-video-ati git and with the new microcode finally on my RS485M OpenGL works fine and without any graphics errors
berniyh: tried ultimatestunts and Q3A
mcgreg: cool, that sounds great
berniyh: kwin + opengl in compositing mode still crashs, though
berniyh: but the nice thing is, that it works with xrender and with that even with descent performance, although it has to render a 1600x2400 screen (little bit too much for a little mobile chip? *g*)
mcgreg: 1600x2400 is indeed a large resolution :)
MrCooper: berniyh: works here with GL as well - make sure you disable direct rendering in the kwin configuration
MrCooper: there's some corruption though that isn't there with compiz
berniyh: MrCooper: does opengl run faster than xrender?
berniyh: because it is very smooth here, with xrender, so i won't really bother :)
MrCooper: think so
berniyh: the only problem is resizing, but i know, that is a qt and/or kwin problem
berniyh: since my big nvidia card goes down there, as well
berniyh: btw, Q3A ran with good performance as well, it was not completely smooth, but close
berniyh: keep in mind, that it had to render two screens there aswell
berniyh: i like that :)
MrCooper: berniyh: which card is that?
berniyh: 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP] [1002:5975]
MrCooper: ah, not sure GL compositing is expected to work well with that yet
mcgreg: you played q3 at 1600x2400? that would kill my x1300pro too, I guess :)
berniyh: fglrx was a bit faster, but i think only 10% or so, i can live with that
berniyh: mcgreg: no, it switched to clone mode for that one
berniyh: or not exactly clone mode i think, but something like that
MrCooper: Q3 is mostly a rasterization throughput test at that resolution
berniyh: hehe
mcgreg: but if it#s just 10% slower than fglrx, than it has quite good performace since fglrx is rather quick
berniyh: well, i can't really test it :(
berniyh: since i can't run fglrx
mcgreg: well, it runs crappy here too :)
mcgreg: but 3d is rather unsable, so I see no sense in using it
mcgreg: unusable
berniyh: the only thing that ran better in fglrx until now were 3D apps and i don't use those very often
mcgreg: googleearth? does it work well?
berniyh: didn't try
berniyh: let me install it and see
berniyh: hm
berniyh: after i activated xrender (and disabled it again) it doesn't like opengl apps anymore
berniyh: libGL warning: 3D driver claims to not support visual 0x23
berniyh: brb
berniyh: lol, that's funny, now it doesn't work anymore ^^
mcgreg: hmm from the git log I see "R5xx: bump textured video limits to 4096" - but when I start xvinfo I get "maximum XvImage size: 2048 x 2048" - shouldn't it be 4096x4096?
berniyh: (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib64/dri/r300_dri.so: undefined symbol: __driCreateNewScreen_20050727)
berniyh: (EE) AIGLX: reverting to software rendering
berniyh: might that be the problem?
berniyh: lets have another try
Terman: I'm working on a M54 machine (Thinkpad T60) and have just built the radeon driver and the drm.ko/radeon.ko from git head. xv is workin, hw scaling on the panel as well, but glxinfo tells me "direct rendering: no"
Terman: Any ideas what I'm missing or where I can find some sort of instructions?
MrCooper: Terman: does Xorg.0.log say direct rendering enabled?
MrCooper: berniyh: that looks like a mismatch between xserver and mesa
Terman: (II) RADEON(0): Direct rendering enabled
berniyh: hm
berniyh: X.Org X Server 1.4.0.90
berniyh: wondering why it worked before
Terman: that's the server version I'm using as well (opensuse-factory)
berniyh: btw, disabled AIGLX and it still shows that error
Terman: glxinfo segfaults after printing a table that starts with some hex-IDs
MrCooper: Terman: LIBGL_DEBUG=verbose glxinfo >/dev/null
berniyh: MrCooper: (II) RADEON(0): Direct rendering experimental on RS400/Xpress 200 enabled
berniyh: (II) RADEON(0): Direct rendering enabled
Terman: ah, that seems to point me in the right direction: libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so
Terman: ok, so it looks like my mesa is too old
Terman: where can I find documentation on which git/svn/cvs repo to use with the git-head of xf86-video-ati?
Terman: +for Mesa
MrCooper: Terman: xf86-video-ati doesn't really matter, just xserver and mesa need to match for AIGLX
Terman: xserver and mesa match
Terman: (at least I haven't touched them for a while :-) and things work with fglrx
Terman: hmm, let me verify that last statement
Terman: ok, fglrx doesn't like to be started after radeon -> have to reboot -> brb
funda3: will building mesa from git work with X server 1.4.99.901 or will i have to build X from git too?
MrCooper: funda3: building mesa per se doesn't have any particular requirements on X
Terman: ok, it took a bit longer: fglrx doensn't compile on my current kernel any more - so no cross check
berniyh: Terman: tztz, don't use -rc kernels *duck*
funda3: well, building mesa from git while keeping X at 1.4.0.90 gives me: (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib64/dri/r300_dri.so: undefined symbol: __driCreateNewScreen_20050727)
Terman: berniyh: live is hard - well, who needs binary only drivers now that radeon(hd) exist. 3D support would be a nice add on, but I've rarely used it with fglrx
berniyh: Terman: just making fun ;)
Terman: radeon supports hw-scaling and xv - the 1st is what I need for work, the second what I use regularly to watch videos
berniyh: i use 2.6.25 as well, but i pretty much compose my own kernel from various trees, so it's maybe a little bit different from what you are doing
Terman: berniyh: yes - I rarely build my own kernel - now that iwl drivers are in the kernel
loswillios: agd5f: cool, textured video works on my rs400!
MrCooper: funda3: as I said, for AIGLX the xserver and mesa snapshots need to match
MrCooper: i.e. either corresponding stable branches or master snapshots from around the same time
funda3: 1.4.99.901 is 2 weeks old :)
MrCooper: it's on a stable branch which branched off master long ago
berniyh: hm wait a second, 1.4.99.901 is that the 1.5 prerelease?
funda3: hmm... well, i'm trying it now anyway.. i'll switch to using master on both if doesn't work
funda3: berniyh: yes
berniyh: and master is 1.6 or 1.5?
MrCooper: hmm right, but there have been DRI driver interface changes on the master branches recently
Terman: which reminds me: it's been close to a year and several kernel versions that I've tried to get some hw to work - that's what holidays are for
MrCooper: berniyh: 1.5 has branched off master, but a lot of changes are still getting backported
berniyh: hm
Terman: MrCooper_: in order to fix the mismatch between my mesa version and the x-server: should it be sufficent to rebuild the mesa package with the current xserver installed or do I need newer sources?
MrCooper: Terman: you need a newer xserver or older mesa
MrCooper: the DRI interface entrypoint is hardcoded in both trees
MrCooper: though 20050727 sounds oldish for 1.4.99...
Terman: MrCooper: you are mixing my messages with someone else's :)
Terman: libGL error: dlopen /usr/X11R6/lib/modules/dri/r300_dri.so failed (/usr/lib/libmesa_private.so.1: undefined symbol: _glapi_Dispatch)
Terman: I'm running 1.4.0.90
MrCooper: ugh, no idea what /usr/lib/libmesa_private.so.1 is, you'll have to take it up with whoever provides that
MrCooper: this is between libGL and the Mesa driver and has nothing to do with xserver
Terman: hmm, libmesa_private is provided by Mesa, just like r300_dri.so
Terman: sigh
funda3: there are no errors in xorg.log for X 1.4.99+mesa from git, but exa on my 9500 is a lot slower and compiz might as well be using software rendering. i'm not sure if i want to try master..
Terman: ok, will now find out where the git(or whatever) head of mesa can be found
MrCooper: Terman: upstream Mesa doesn't have /usr/lib/libmesa_private.so.1
Terman: hmm, maybe is't a SUSEism
Terman: rpm -qf told me so
MrCooper: probably
MrCooper: you'll have to ask them how to use Git snapshots with their stuff
Terman: ok, have to get up - lunchtime is getting close :)
simpsonc: Insomnia is delicious. Reading today's logs now.
icewaterman: File r300_mem.c function r300_mem_alloc line 225
icewaterman: Ran out of GART memory (for 1048576)!
icewaterman: Please consider adjusting GARTSize option
icewaterman: how can i do that?
icewaterman: FBTexPercent <- is it this option?
MrCooper: "GARTSize"
simpsonc: airlied: I'm in your branch, testin' your 3D.
simpsonc: Will report in ten or so.
icewaterman: MrCooper: gartsize is no option (at least couldnt find it in the manpage
icewaterman: [drm] Initialized kernel GART heap manager, 5111808 <- u suspect it is 512mb already
MrCooper: icewaterman: indeed it's not in the manpage, but it exists nevertheless
MrCooper: it defaults to 8 MB
MrCooper: you can specify powers of two up to the GART aperture size
icewaterman: MrCooper: i remember having set 128mb on agp cards in the past
MrCooper: note that it'll statically allocate that much RAM even when it isn't all used
icewaterman: MrCooper: i have 2g of main memory, so it'll be ok
icewaterman: do i have to specify it in mb kb or bytes?
icewaterman: looks like mb
icewaterman: the thing is, cant i make it use more video ram instead of main memory? because my card has 256mb of main memory that are going to waste most of the time
MostAwesomeDude: Howdy, channel.
MostAwesomeDude: It's me, C. Simpson. Decided to switch to my "real" name.
MostAwesomeDude: airlied: 3D WORKS! glxgears works!
MostAwesomeDude: 2000+ fps.
icewaterman: MostAwesomeDude: what card?
MostAwesomeDude: icewaterman: RV535 M66 Radeon Mobility X1700.
icewaterman: MostAwesomeDude: with the new radeon driver? cool
bobbens: nice
MostAwesomeDude: Want screencaps? I got screencaps.
bobbens: i can't wait until we get shaders :)
MostAwesomeDude: bobbens: Shader support is what I originally worked on, an' I'm gonna go back to working on that.
bobbens: only the r5xx chipsets or us r3xx guys too? :)
loswillios: I hope the RS690 will be as good supported as the rs400 which i'm currently running
icewaterman: loswillios: rs690 is the integrated x1200 right?
TobiasTheCommie: MostAwesomeDude: the radeonhd driver or the radeon driver?
MostAwesomeDude: bobbens: You guys already have a frag shader.
bobbens: we do? probably git then
icewaterman: loswillios: i have one of those as well, would be great if my onboard graphics were supported because i can then get rid of my x850
loswillios: icewaterman: yes, i think so. my next laptop will have a x1250
MostAwesomeDude: TobiasTheCommie: It's in Mesa, but only with radeon.
bobbens: i really want to get around to playing with newer opengl features, haven't had a chance because of the driver, but now that amd is being nice...
MostAwesomeDude: bobbens: There's been r300_fragprog in Mesa for a bit, I think.
loswillios: icewaterman: i think it is supported already but i don't know the state
icewaterman: loswillios: my mainboard already has one, i am currently using the x850xt because i want open source 3d support.
MostAwesomeDude: You might be thinking of OpenGL 2.0 shaders, which aren't in Mesa.
bobbens: MostAwesomeDude: i'll wait for debian sid to get it, or if i get bored i'll upgrade
loswillios: icewaterman: rs6xx is similar to r5xx IIRC
bobbens: i'm hacking force feedback now anyways :)
MostAwesomeDude: bobbens: Oh, you're using Debian!
MostAwesomeDude: http://img156.imageshack.us/img156/7789/snapshot30ks5.png
MostAwesomeDude: Screenie.
icewaterman: MostAwesomeDude: the transparency, how did you get that working and how much performance does it cost?
loswillios: exa ftw
icewaterman: loswillios: i use exa already, just what program will i need for transparency and such
loswillios: a windowmanager that supports it
loswillios: eg the new metacity (gnome), xfwm4, …
icewaterman: loswillios: hm, i am using kde
loswillios: or xcompmgr
loswillios: also make sure to enable composite extension in xorg.conf
loswillios: kde's wm supports it also
icewaterman: oh, composite is disabled. do i need any additional stuff besides kde? or will kde 3.5.x do that natively?
loswillios: natively
icewaterman: thx, i'll try setting it up
MostAwesomeDude: icewaterman: Enabled EXA and Composite in xorg.conf.
icewaterman: MostAwesomeDude: already did so, i am atm trying to convince kde to use it
MostAwesomeDude: icewaterman: You will need xcompmgr. You will also want kompmgr.
MostAwesomeDude: kompmgr is the KDE wrapper for xcompmgr.
MostAwesomeDude: And then in Control Center, go to Desktop->Window Behavior.
MostAwesomeDude: The Translucency tab.
MostAwesomeDude: If you don't have Composite enabled, it'll be all grayed out.
icewaterman: MostAwesomeDude: composite is enabled
MostAwesomeDude: But the tab still doesn't work?
icewaterman: tab works, just no effect
icewaterman: but i do not have kompmgr installed
loswillios: hm, it's the RS600 ME in my new laptop
icewaterman: maybe i need to login again
loswillios: you need to restart X
icewaterman: loswillios: yes, i did, and now it works to some degree
icewaterman: but only window decoration is transparent, might have set it up wrong though
icewaterman: ah, here we go
airlied: MostAwesomeDude: just passing through, please work on frag shader..
airlied: MostAwesomeDude: it should be a lot easier now you have a stable baes.
MostAwesomeDude: airlied: Indeed.
MostAwesomeDude: I'm going to figure out how you're stashing the instructions (looks like just 6 dwords floating out there), and then start porting old code to new.
quicksilver: how much does the new microcode phoronix is talking about help?
MostAwesomeDude: quicksilver: It fixes a handful of chip-specific bugs, or so I'm told.
quicksilver: nods
MostAwesomeDude: At any rate, it works fine over here on my r5xx, but there's been a couple regressions reported.
loswillios: eis there something like XvMC in the pipeline?
MostAwesomeDude: Mm, doubtful.
MostAwesomeDude: I mean, there's the UVC on cards with AVIVO, but it's not opened.
GhePeU: MostAwesomeDude, does textured video work on your r5xx?
MostAwesomeDude: It would be like r300/r400 all over again. Years of reverse engineering.
loswillios: mmh
MostAwesomeDude: GhePeU: It has not worked yet. I have not tested since getting glxgears working, because I have things running on X that I don't want to die. :)
MostAwesomeDude: I should test it; lemme clean up the windows I've got running.
GhePeU: oh. I was hoping you could confirm my regression with the new microcode. I still don't know if it happens only here
GhePeU: (rv370 here)
MostAwesomeDude: GhePeU: You had a problem with compiz and render-to-target video, right?
MostAwesomeDude: Trying the cube or something similar while playing video?
MostAwesomeDude: Well, here goes.
MostAwesomeDude: Test 1: mplayer works.
GhePeU: yes
MostAwesomeDude: Test 2: simple seek works, which is farther than I've gotten before.
MostAwesomeDude: Test 3: Fullscreen works.
MostAwesomeDude: Test 4: FS with seek works.
MostAwesomeDude: Wow, I can use XV with mplayer. Sweetness.
GhePeU: I could easily repeat by launching totem (textured video output) on a viewport, switching to a second viewport, launching glxgears, switching back and forth for a while using the panel switcher, eventually closing and relaunching glxgears.
MostAwesomeDude: Oh, and for fun, gl2 works as well.
MostAwesomeDude: gl looks glitchy because of dumb frag shader, but I'm on that.
MostAwesomeDude: You should let agd5f know about the bug.
MostAwesomeDude: bridgman: My RV535 has direct rendering on gears.
bridgman: loswillios: I'm pretty sure we will be able to open up the IDCT block for XVMC;
GhePeU: I told him yesterday
bridgman: That's great news.
icewaterman: btw, how do i find out, how many texture image units etc. my card posseses?
MostAwesomeDude: I know! I'm so excited.
agd5f: yup got it
loswillios: bridgman: great news, thanks
bridgman: icewaterman, a lot of this is covered in the front section of the R5xx manual
agd5f: icewaterman: all the r3xx-r5xx units have 16 texture units
bridgman: or you could ask agd5f ;)
icewaterman: agd5f: ah, thx, so i will try setting that up
icewaterman: and texture coordinate units
icewaterman: ?
icewaterman: probably as well
bridgman: bty, someone earlier was concerned about us releasing "the microcode from fglrx"
agd5f: icewaterman: you mean rasterizers?
icewaterman: from the name i'd suspect them to be reservation stations for the operative units.
bridgman: if it makes anyone feel better we use the same microcode in the WinXP drivers
agd5f: 8 RS units
icewaterman: texture_corrdinate_units
icewaterman: thats what driconf says
loswillios: does anyone know what the ME in RS600 ME stands for?
agd5f: loswillios: ask marketing ;)
GhePeU: I bought a r300 card in october 2006 only because AMD bought ati and I hoped they would do the right thing
loswillios: heh I see
bridgman: re: ME my first guess would be "mobile something"
GhePeU: I'm happy I made the right choice
GhePeU: :)
MostAwesomeDude: loswillios: The RS600 is a laptop chip, right? So it's probably "Mobile Edition".
loswillios: yeah it's a mobile chip. i thought it maybe has a special meaning, but... ah ok MostAwesomeDude
loswillios: millenium edition would be cooler, though
icewaterman: agd5f: anyway, driconf cannot set 16, 8 seems to be the limit
agd5f: icewaterman: probably rasterizers then
icewaterman: agd5f: as i said, driconf will not let me set anything beyond 8
MostAwesomeDude: loswillios: That's what Microsoft said, too...
loswillios: haha
loswillios: now that my rs400 works so flawlessly I have to leave it for a rs600me :/
agd5f: icewaterman: it's probably rasterizers, but TBH, I don't recall what that option referred to off hand
MostAwesomeDude: If anybody is running r5xx and the brand-new git DRM, Mesa, and radeon, would they mind confirming a rather interesting bug/feature?
agd5f: loswillios: the rs600 shoudl work too
icewaterman: agd5f: also the rs690?
loswillios: it's the same AFAIK
agd5f: icewaterman: rs600 and rs690 are the same ship GPU-wise
icewaterman: and it works=
loswillios: rs600 = intel, rs690 = amd
agd5f: chip even
icewaterman: ah
icewaterman: nice, maybe i should try it then
icewaterman: what driver version will i need?
bridgman: yep. the RS600 and 690 both have 3D cores derived from the R4xx family
agd5f: icewaterman: latest drm/mesa/ati git
bridgman: AFAIK the fragment shader part is well understood; the challenge until
loswillios: cool, that means a lot of stuff is working already on rs6x0?
icewaterman: agd5f: ouch, thats gonna be a problem.
bridgman: recently was the vertex part -- RS6xx don't have programmable vertex shaders so
loswillios: icewaterman: there are instruction on x.org wiki
bridgman: the rest of the VAP block needed to be set up differently; docs seem to help
icewaterman: loswillios: thats not the problem
loswillios: bridgman: nice
agd5f: on the RS chips the VAP feeds directly to the GA inputs
icewaterman: loswillios: i did compile mesa & co in the past, but i'd rather like to stay with packages from my distro in order to keep maintenance work to a minumum
loswillios: icewaterman: yeah, see x.org wiki
agd5f: so you just pass the vertices straight through
agd5f: icewaterman: you can install it all in parallel in /opt/xorg or whatever
bridgman: off to work, bye
icewaterman: how good is the performance on the r690s? sufficient for google earth?
agd5f: icewaterman: try it :)
icewaterman: agd5f: good point
loswillios: agd5f: does full exa work already with rs6x0?
agd5f: loswillios: yes
loswillios: wow
loswillios: I take it the rs6x0 is basically a rs4x0 :)
MostAwesomeDude: http://img291.imageshack.us/img291/4410/snapshot31fa8.png
MostAwesomeDude: Hmm. Lemme get one more.
MostAwesomeDude: http://img170.imageshack.us/img170/3526/snapshot32pg7.png
MostAwesomeDude: Oh, much better.
agd5f: loswillios: more or less rv4xx, rather than rv3xx
icewaterman: in case the onboard card works, i can easily get rid of my x850 again - after a few days :)
loswillios: i see
MostAwesomeDude: agd5f: Am I right in assuming this is a problem with the dumb frag shader?
icewaterman: bbl.
agd5f: MostAwesomeDude: Xv or GL?
MostAwesomeDude: That's gl.
MostAwesomeDude: gl2 works fine.
MostAwesomeDude: Oh, and xv works as well. Finally.
loswillios: which is to prefer cpu-wise anyway? xv, gl, gl2, …?
loswillios: ie, which does the most stuff in hw
agd5f: MostAwesomeDude: the FS pass through in mesa should be pretty similar to the one used by the Xv code
agd5f: I've never really looked at what mplayer's gl code does
agd5f: loswillios: test and see :)
MostAwesomeDude: loswillios: gl2, requires OpenGL 1.4 but uses more HW
michaellarabel: agd5f || airlied: R520 (X1800XT) looks like it may have some problems with the latest airlied Mesa/DRM with glxgears.
MostAwesomeDude: michaellarabel: How so?
michaellarabel: When launching glxgears, the gears are missing
MostAwesomeDude: ?!
agd5f: michaellarabel: haven't had a chance to check out airlied tree yet ;)
loswillios: checks which OpenGL he has
MostAwesomeDude: michaellarabel: Are you using the glxgears from your distro, or the one in the Mesa git tree?
michaellarabel: glxgears from distro
MostAwesomeDude: loswillios: mplayer will let you know if gl2 can't run on your card.
michaellarabel: (Ubuntu 8.04 packages as of yesterday)
MostAwesomeDude: michaellarabel: Could you try the glxgears from Mesa's tree? progs/xdemos/glxgears
michaellarabel: Yeah
loswillios: damn, OpenGL version string: 1.3 Mesa 7.0.1
loswillios: updates
MostAwesomeDude: loswillios: Sorry, typo. Meant OpenGL 1.2.
MostAwesomeDude: All of the accelerated Radeons should work.
michaellarabel: Still a no-go using glxgears from Mesa tree
MostAwesomeDude: Hmm.
MostAwesomeDude: So, blank buffer, with nothing drawn...
loswillios: MostAwesomeDude: [gl2] You have OpenGL >= 1.2 capable drivers, GOOD (16bpp and BGR is ok!), seems to work
MostAwesomeDude: Could you try progs/trivial/tri ? You'll have to `make` in progs/trivial
agd5f: michaellarabel: did you add your card's ids to mesa and drm?
MostAwesomeDude: loswillios: That's it!
michaellarabel: Yes, of course.
loswillios: nice
loswillios: but cpu usage is higher than with XV
michaellarabel: I may pop in an RV530 or different chip and see if I experience the same problems.
agd5f: michaellarabel: yeah, I'm not sure off hand, haven't tested teh code yet
MostAwesomeDude: loswillios: Check glxinfo, make sure you're accelerated... Also you may have to rebuild mplayer if it's been a long while since you last built it.
glisse: agd5f: i believe r3xx/r4xx only have 8 texture unit active/working
glisse: agd5f: historicaly the design might have been 16
agd5f: glisse: right 16 units, but only 8 can be active (rasterizers)
agd5f: but you can pick from the 16 depending on your S
loswillios: MostAwesomeDude: is there a special mplayer ./config option regarding gl2? anyway, this is a rs400, support is maybe flaky since it always says Warning, xpress200 detected. :p
agd5f: FS
icewaterman: oh, btw. the r400 now also works with s3tc
icewaterman: given the libtxc_dxtn is installed
MostAwesomeDude: loswillios: Mine says "Warning, RV530 detected, all your base belong to us"
loswillios: haha
MostAwesomeDude: agd5f: My bug might have been due to system updates, which I forgot were running. Imma rebuild and try again.
icewaterman: MostAwesomeDude: a magic the gathering like statement would have been cool: all your deck is now mine :)
MostAwesomeDude: icewaterman: The difference feels rather academic each time X locks up.
MostAwesomeDude: But really, I mean, Gentoo system updates take forever.
glisse: michaellarabel: for r500 pipe initialization might be optimistic, which might explain why you dont see anythings
icewaterman: MostAwesomeDude: which is why i switched to debian and then to ubuntu eventually
michaellarabel: To anyone else who's tried out the latest code, what GPUs are you using? So I know which graphics card to try next.
MostAwesomeDude: michaellarabel: RV535, which is actually closer to RV515 than R520.
icewaterman: michaellarabel: i am going to try some x1200 but i need to compile stuff first
michaellarabel: Just popped in an RV515 to try
mcgreg: just read phoronix .. good job airlied :)
icewaterman: btw. if i compile the drivers, will i need radeon and r300 in DRI_DIRS
icewaterman: or is r300 enough?
MrCooper: r300 is enough
MrCooper: radeon is for R100
mcgreg: soi, to get this work, I'll need to get mesa git too?
icewaterman: mcgreg: yes
mcgreg: thx
mcgreg: icewaterman: when I'll come back later, I hope you can tell me your test-results :)
MostAwesomeDude: radeon holds a bunch of things shared among all radeon drivers, and if you build r300, then radeon will be built as well.
MostAwesomeDude: Okay, got it. 3D and Composite are not working together in a nice friendly way.
icewaterman: ok, i am now building mesa, libdrm was built and installed to /opt/lib already how can i point mesa to /opt/lib instead of using the installed old libdrm from the packages?
icewaterman: MostAwesomeDude: i disabled composite as well because of the performance impact on 2d
icewaterman: and for the most part it is unnecessary
icewaterman: radeon_screen.c: In function ‘radeonCreateScreen’:
icewaterman: radeon_screen.c:721: error: ‘RADEON_PARAM_FB_LOCATION’ undeclared (first use in this function)
icewaterman: hmm
icewaterman: it doesnt find my libdrm i guess
icewaterman: oh, and i think i know why
icewaterman: btw. will i need to build a new kernel module for the latest git drivers?
agd5f: MostAwesomeDude: yeah, 3D and composite don't get along, that's why we are working on dri2
icewaterman: btw, i was able to cross-compile libdrm (without any problems)
icewaterman: lets hope mesa doesnt run into similar problems
icewaterman: oh great, on i386 it doesnt find the drm.h i previously installed. with x86_64 there is no such problem though
icewaterman: libGL error: dlopen /opt/lib/modules/dri/r300_dri.so failed (/opt/lib/modules/dri/r300_dri.so: undefined symbol: drmBOUnreference)#
icewaterman: hmm
MrCooper: it's probably picking up a stale libdrm
agd5f: icewaterman: need a new libdrm
icewaterman: agd5f: but i compiled it
MrCooper: not that the r300 driver actually needs that symbol... but that's another story
icewaterman: ah, then i need to preload it as well
agd5f: icewaterman: well, it needs to find it :)
MostAwesomeDude: Mm, snes9x's OpenGL client runs.
MostAwesomeDude: My God, this is fun!
MostAwesomeDude: Oh, no, wait. We've got buggies.
agd5f: MostAwesomeDude: welcome to driver hacking :)
agd5f: MostAwesomeDude: it's eventaully drive you craxy
MostAwesomeDude: Remember the horizontal shear problem from fglrx's Xv? I've got it now, but only on snes9x. Mplayer works fine.
loswillios: hm, i wonder if i can make urxvt to use hw-transparency
icewaterman: MostAwesomeDude: maybe an issue with their microcode
agd5f: icewaterman: doubtful, probably more an issue with the command stream
MrCooper: that kind of tearing can only occur without double buffering
MostAwesomeDude: I think it may be snes9x not having active Linux devs...
icewaterman: agd5f: i do not need to compile a new kernel module, do i?
icewaterman: for the r690 stuff
MostAwesomeDude: Hmm, it stopped doing it.
MostAwesomeDude: Can't reproduce it.
icewaterman: thats bad
MrCooper: MostAwesomeDude: are you using a compositing manager?
MostAwesomeDude: MrCooper: Nope, flicked off Composite so I could test more 3D stuff.
MostAwesomeDude: Hmm. Going to try XAA and see if speed improves.
GhePeU: hi there. Option "EXANoComposite": does it disable only composite acceleration, that is, the driver uses the same codepaths it used before the r3xx-render branch was merged in?
GhePeU: zero-copy-tfp keeps working, rotation acceleration keeps working...
agd5f: GhePeU: that just turns off the exa compsite driver hooks
agd5f: GhePeU: same as radeon option renderaccel
agd5f: icewaterman: you don't need a new kernel, just new drm modules
icewaterman: agd5f: so i do need a new drm module.
icewaterman: not a problem, compiled them before
agd5f: icewaterman: yes
icewaterman: hmm
icewaterman: /usr/bin/ld: cannot find -lstdc++ <- requires this lib to build libGLU (32bit on amd64 system).
icewaterman: what version? libstdc++5 or 6?
natergator: agd5f: any insight into why AccelDFS defaults to off (allegedly due to AGP issues?)
icewaterman: i definately need a 32bit chroot env with a complete installation
natergator: icewaterman: what are you trying to build?
icewaterman: natergator: 32bit version of the driver
icewaterman: r300 with mesa & stuff
icewaterman: on a 64bit system because i will need it in order to have 3d in 32-bit games/apps
mattst88: I'd like to report that Mesa from git compiles with icc, and works fine, DRI included :)
natergator: ah. I can give you a distcc connection to my asus eeepc but it's the only 32 bit system I've got ;)
icewaterman: natergator: no thx, it seems i will need it too often anyway
natergator: word
icewaterman: maybe i'll even install an ubuntu 32-bit vm
natergator: mattst88: did you checkout 7.0.2 or are you using the most recent commits?
mattst88: most recent, from git
natergator: sweet
mattst88: I think I need to tweak some settings though
mattst88: before I upgraded everything to git, I got 6200 FPS from glxgears; now I get < 4000
mattst88: even the icc-compiled Mesa gets 3700
icewaterman: mattst88: glxgears is not much of a benchmark
mattst88: yeah, I know.
mattst88: I've also got quake3...
mattst88: I'll benchmark that in a few minutes.
icewaterman: mattst88: thats why you in the past had to type glxgears -iknowthisisnobenchmark in order to see the fps
mattst88: lmao
icewaterman: mattst88: nojoke
icewaterman: ok, ill have to install a vm before i can use the new driver. i'll get back
icewaterman: agd5f: if this was a 24h disconnect, you can have your router do that at night :)
mattst88: I find it funny that icc defines __x86_64__ but not __amd64__, __amd64, or amd64
agd5f: icewaterman: my DSL went down, so I had to switch over to the cable modem
icewaterman: agd5f: you have both?
agd5f: icewaterman: I work from home. internet is essential
icewaterman: agd5f: :)
icewaterman: mattst88: -iacknowledgethatthistoolisnotabenchmark <-- that was the option btw.
mattst88: hah, nice
mattst88: brb
icewaterman: agd5f: any specific reason why not to use both lines via a load balancer at the same time?
icewaterman: or do you already do that?
agd5f: icewaterman: different ISPs
icewaterman: well but i do not want to distract you from your work.
icewaterman: agd5f: you can connect both nevertheless
agd5f: they both are connected, I just had to change the routing on my PC
icewaterman: agd5f: you can have that automatically
agd5f: yeah I could
agd5f: but I tend to try and favor the cable modem because the bw is better, but the DSL tends to be more reliable
Goga777: will the support of XvMC implement in open source driver fro ati card ?
agd5f: Goga777: we hope to eventually
Goga777: it will concern for R500 and R600 ?
agd5f: Goga777: I think at least the r5xx still has the idct engine, not sure about the r6xx
glisse: agd5f: isn't a better video acceleration framework needed to actualy expose things ?
agd5f: glisse: yeah for h264 and such
MostAwesomeDude: glisse: There is technically the AVIVO unit, but I'm not sure what's in it.
agd5f: but mpeg1/2 should doable with current xvmc
glisse: MostAwesomeDude: not seeaking about that, speaking about which api we expose acceleration through
agd5f: MostAwesomeDude: avivo is just a marketing name for the "new" display controller, some parts are old though
glisse: xvmc is suited for mpeg1 & 2
glisse: not for newer format like h264
MostAwesomeDude: Ah.
MostAwesomeDude: Marketing strikes again.
MostAwesomeDude: So, earlier somebody was profiling the DRI. Can I just use oprofile to try that, or is there some specific profiler I need?
agd5f: MostAwesomeDude: oprofile will work
ghepeu: f*cking matlab
ghepeu: or matlab and X, if it is the case
OipOS: agd5f: How much work would implementing GLSL be at the moment?
MostAwesomeDude: OipOS: GLSL is taken care of by Mesa. The backend part, the frag shader, still needs to be rewritten for r5xx.
glisse: OipOS: i wouldn't encourage you on non gallium as i believe TG people focus on gallium and that glsl will stay in the current state in mesa
Goga777: glisse> xvmc is suited for mpeg1 & 2
Goga777:
OipOS: Hmm. What other missing extensions are worth implementing then?
Goga777: is it true ???
agd5f: OipOS: there are some proposals for updating xvmc or a new API to support newer formats
Goga777: I hoped that with xvmc I can see hdtv in h264
glisse: Goga777: well i am not a video expert but this the outcome of a discussion which happened somewhere maybe on xorg ml
OipOS: Proposals as in other GSoC proposals?
Goga777: a new API is not VAAPI ?
agd5f: Goga777: most hdtv is mpeg 2 however, at least the OTA and cable stuff
Goga777: agd5f, no most of the hdtv channels (around 99%) from sattellites in h264
Goga777: i mean Europe
agd5f: Goga777: well, ATSC and QAM are mpeg 2 IIRC
Goga777: dvb-c dvb-t also in h264
agd5f: interesting. I didn't know that
Goga777: that's why the support for h264 is very actually now
Goga777: there's mpeg2 channels for dvb-t dvb-c of course
Goga777: 50/50
Goga777: now some dvb-s providers in Europe move from dvb-s mpeg2 to dvb-s2 h264 for the channels with standard definition , not high definition
OipOS: agd5f: Then, would improving support for the newer cards sounds as a good proposal, or is it too meager?
agd5f: Goga777: save bandwidth :)
agd5f: OipOS: sure. what features did you have in mind?
OipOS: Well, I'm not too sure what's lacking for the r5xx and r6xx cards, but do they have 3D support yet?
OipOS: Or well, I could always put '3D support' as my primary goal, and some others(RENDER acceleration, etc) as secundary.
glisse: OipOS: 3D is big enough to keep someone busy for a while
rx__: :)
agd5f: OipOS: render support is largely done already :)
agd5f: OipOS: but 3D is a big project. I'd focus it down a bit
OipOS: Hmm. Any suggestions?
ghepeu: summer of code?
OipOS: Yes.
rx__: the tungsten guys should do a gsoc
Goga777: http://www.phoronix.com/scan.php?page=article&item=r500_glxgears&num=1 3D on R500 is working in experimental mode
agd5f: maybe a particular set of extensions or features you'd like to work on? or some infrastructual work like better support for gart memory
ghepeu: what about a decent gl benchmark and/or infrastructure for automatic testing of performance regressions/improvements?
agd5f: ghepeu: that would be good
OipOS: I'm not too known with the possible selections. Which extensions/features are still left undone?
OipOS: Hmm. That does sound reasonable.
agd5f: OipOS: or a simple test app that we could use to test the hw
agd5f: like an updated r300_demo
rx__: an updated r300_demo will take all summer?
OipOS: My thought exactly.
agd5f: OipOS: compare http://www.opengl.org/registry/ with the output of glxinfo
agd5f: rx__: depends
glisse: rx__: well a more advanced r300_demo might
glisse: like adding a simple framework to emulate basic gl things (matrix trans, ...)
rx__: interesting
glisse: also might be usefull for benchmarking ie pushing hw to the edge
OipOS: Though I'd rather work on adding new extensions/featues
OipOS: +r
glisse: OipOS: i might have one idea
glisse: but i need to look at some code first
OipOS: I'd like to consider as much as possible.
glisse: basicly is adding some hook to help to optimize fragshader (could work also for vertex shader but fragment matter much)
OipOS: Also, what about supporting DRI2?
rx__: i thought intel and dri2 hasn't even stabilized yet
ghepeu: OipOS, afaik that's HUGE
OipOS: A-hem. Alright.
glisse: i might show some progress on the dri2 front soon
rx__: glisse, dri2, gallium, what else do you have on the backburner? ;)
rx__: modesetting
rx__: man..
glisse: well it all comes with kmodesetting and code is there
aneas: [x] worldwide peace
glisse: only code unpublished i have is a new r300 demo using ttm :)
Tigerchen: aneas: are you on a miss-competition? ^^
OipOS: Hmm, how much work is left to do in the shader parts?
OipOS: Or is that somewhat the same as adding new extensions?
glisse: OipOS: well in shader we need to do some shader code shuffling
aneas: Tigerchen, in my opinion, with ehm 9/11 and tah war in iraq, ehm, considering, ehm, poor children and education, ehm
glisse: so having someone working on this would be valuable
rx__: aneas; world peace is limited to people with radeon cards ;)
OipOS: chuckles
glisse: especialy things like rescheduling tex lookup, use native swz, optimize vector & scalar pipe
OipOS: Sounds cool.
aneas: god intended it that way!
tilman: a shader gsoc could include converting ati_fragment_shaders to the arb fp's
tilman: so i get more fps in doom3 until ttm is done :p
MostAwesomeDude: OipOS: Big changes in frag shader. New format, native swizzles, native sine and cosine, different register flags...
glisse: tilman: you still haven't kill all the alien ? i thought we were safe ;)
OipOS: Aha, something very useful to work on. Hmm.
tilman: glisse: i only play once a year for about a week. i make progress very slowly ;D
MostAwesomeDude: ...alpha and RGB (scalar and vector) instructions can be done on the same cycle...
OipOS: And what's the deal with the indirect GLX_EXT_texture_from_pixmap that compiz warns about?
MostAwesomeDude: ...and, of course, it must be uploaded indirectly, like the vertex shader.
MostAwesomeDude: I've been looking into it just a bit.
OipOS: glisse, how long do you think you need for looking into that code?
glisse: OipOS: i am writting a proposition which give deeper details
OipOS: Alright.
OipOS: Though working on the shader gets me most thrilled at the moment.
MostAwesomeDude: OipOS: Getting the frag shader done and working, and also working on the Mesa backend to bring it up to speed, would probably fill a few months.
MostAwesomeDude: But the shader by itself poses only a few weeks' challenge.
OipOS: Hmm, maybe I could go for the shader itself, and working on some new extensions.
berniyh: hmpf, back to stable mesa, too bad ;)
berniyh: but was a nice experiment and good to see, that basically it works
MostAwesomeDude: glisse: On another note, what is required for HW TCL on r5xx?
glisse: MostAwesomeDude: well i haven't looked at difference with r3xx is there any ? beyond routing register
MostAwesomeDude: glisse: Good question. I assumed it hasn't really changed, but I don't know enough about r300 to say for sure.
glisse: anyone code where is fragprog code of mplayer ?
agd5f: MostAwesomeDude: the vertex is pretty much unchanged
agd5f: just a few new instructions
MostAwesomeDude: agd5f: Hmm. Would it be possible to turn on TCL right now, and then get it sped up with new stuff later?
MostAwesomeDude: Or should we wait for stuff like the frag shader first?
agd5f: MostAwesomeDude: it should work more or less
agd5f: is it disabled now?
MostAwesomeDude: agd5f: Yeah, airlied marked the chip_family as no_tcl.
MostAwesomeDude: Which is why glxgears spends 30% of its time in r300_quad, lawl.
MostAwesomeDude: Which is why glxgears spends 30% of its time in r300_quad, lawl.
MostAwesomeDude: ...WTF, doublepost.
OipOS: The up key is a blessing and a curse at the same time...
agd5f: MostAwesomeDude: try it :)
MostAwesomeDude: agd5f: Aye aye, cap'n!
mcgreg: icewaterman: back ... so, whats you results? did you get glxgears hardware-accelerated?
icewaterman: no, not yet, turned out in order to get it working i need both 32 and 64bit version of the driver and i am setting up a 32-bit vm in order to get it compiled as cross-compiling was unsuccessful
TobiasTheCommie: for those working on the 3d for the r500 right now... i have an RV530(X1600) and i get "libGL error: XF86DRIQueryDirectRenderingCapable failed" from glxinfo
TobiasTheCommie: relax, i didn't expect anything usefull, just wanted to give it a swing and see how it worked on my card... :)
MostAwesomeDude: agd5f: Profile and glxgears counts suggest TCL is still falling back to SW despite being enabled.
agd5f: MostAwesomeDude: add some printfs and see what's going on
MostAwesomeDude: agd5f: Aye. Also, do you have any idea where r300_quad is defined? It doesn't appear to actually have a function body anywhere in DRI...
MostAwesomeDude: agd5f: Got it. Apparently TCL is only flicked on by request.
MostAwesomeDude: No, wait.
MostAwesomeDude: Argh. Recompiling Mesa.
TobiasTheCommie: haha, just realized that i run from the master, not the r500 test branch, so i can't even see if it works on my card.. stupid me
TobiasTheCommie: :)
MostAwesomeDude: agd5f: The good news is that I'm now getting 3200+ fps on glxgears.
MostAwesomeDude: The bad news is that nothing's being displayed.
MostAwesomeDude: So the TCL regs are wrong, probably.
icewaterman: MostAwesomeDude: which would account for the additional speed :)
glisse: MostAwesomeDude: and now you have somethings to play with ;)
agd5f: MostAwesomeDude: compare the VAP setup with the code for exa render or textured video
berniyh: hm, may I ask, what is the point of Gallium on Windows?
agd5f: berniyh: for use a a driver stack
agd5f: GL and D#D front ends can be built on top of it
agd5f: D3D
berniyh: ah, ok
jkt|: evening
jkt|: closing my thinkpad t60's lid when only LVDS is configured to have display and then opening it again causes heavy image corruption (flashing grid of large rectangles) than can be fixed by switching outputs
jkt|: this is on quite a recent git (less than three days, I guess) and X1400
agd5f: jkt|: yeah, the bios is messing with the hw when the lid button is pressed
agd5f: I haven't sorted out how to turn it off reliably yet
MostAwesomeDude: Hey, are there any progs in Mesa that emit frag shader programs?
TobiasTheCommie: would anyone be able to help me set the correct frequency for the tv-out on the r500? i've made a bug report some time ago, but i am eager to get it fixed, and willing to sit and play with the code, i just need to know where to fiddle around..
RoiDuClapier: Tried the latest git xf86-video-ati on my r3xx card but EXA is still slow as hell. I compile mesa/drm/ati from git
RoiDuClapier: Should I update xorg-server as wll?
RoiDuClapier: ell
RoiDuClapier: well
mattst88: does DRI work for you?
RoiDuClapier: Yes
mattst88: I had to upgrade xserver before DRI worked.
mattst88: oh, ok
RoiDuClapier: But I'm with xserver 1.3 branch
RoiDuClapier: It is slow with GTK apps
RoiDuClapier: especially
RoiDuClapier: Compiz starts with a withe screen too
ejs1920: I have EXA working as good as XAA, on xserver 1.4.0.90, you might need options "MigrationHeuristic" "greedy" and "AccelDFS" "true"
RoiDuClapier: ejs1920: Ok
RoiDuClapier: Will try a more recent xserver and those options
ejs1920: MigrationHeuristic is the important one i think
ejs1920: oh, but i haven't tried the new r3xx-render code yet
icewaterman: the more i read here, the longer i want to stay with my x850 :)
RoiDuClapier: ejs1920: You mean that you are using xf86-video-ati-6.8.0 ?
ejs1920: no, older git snapshot, after 6.8.0
ejs1920: because i like to leave X running
agd5f: RoiDuClapier: hmm. are you sure it installed correctly?
RoiDuClapier: agd5f: I am pretty sure since after the update and a reboot direct rendering works
agd5f: RoiDuClapier: hmmm
agd5f: RoiDuClapier: what chip?
glisse: OipOS: what i was thinking of http://dri.freedesktop.org/wiki/R300FragmentProgramOptimization
berniyh: su
RoiDuClapier: agd5f: 9550 pro
RoiDuClapier: Don't remember the chip
agd5f: RoiDuClapier: that's the same card I have
RoiDuClapier: agd5f: The only packages I need from git are ati/mesa/drm ?
agd5f: RoiDuClapier: for exa all you need is ati
agd5f: the rest should be fine with teh distro versions
agd5f: RoiDuClapier: did you set the prefix when you installed it?
RoiDuClapier: I use an ebuild from the gentoo x11 overlay
agd5f: I guess make sure they include the latest bits
RoiDuClapier: ok
RoiDuClapier: Now it is ok with EXA. I have add MigrationHeuristic and AccelDFS to xorg.conf
RoiDuClapier: But now compiz is sluggish!
RoiDuClapier: I don't need compiz anyway, it is just for the fun to put the new features to the test!
OipOS: checks link
OipOS: I uh...have little understanding about what is talked about there.
RoiDuClapier: EXA crashed X
RoiDuClapier: I think I will let you guys play with that and wait for a new version to hit portage tree ;)
TobiasTheCommie: pokes his radeon driver, but is still being stupid on tv-out
icewaterman: TobiasTheCommie: i never really managed to get tvout working on any platform with any card
OipOS: I wonder, how valuable would making a gallium ati driver be?
icewaterman: finally my virtual machine using kvm is setup
icewaterman: now i can bake the radeon driver
glisse: OipOS: gallium is valuable mostly starting from r300 family
TobiasTheCommie: icewaterman: with closed driver i have...
TobiasTheCommie: icewaterman: but with opensource driver i can get it in black and white, or i can get it in colour where the picture is rolling left to right..
TobiasTheCommie: so close
icewaterman: TobiasTheCommie: i have had a dozen of cards and none worked with my tv neither windows nor linux
glisse: OipOS: if you are interested by my proposal on frag optimization i can help you to go through it
TobiasTheCommie: icewaterman: then i feel lucky
OipOS: Yes, please, elaborate a bit more :)
TobiasTheCommie: i've been using tv-out constantly for the last.... hm... 7 years i think...
glisse: OipOS: i posted link above
glisse: http://dri.freedesktop.org/wiki/R300FragmentProgramOptimization
OipOS: Yeah, I read it. But it didn't make much sense to me.
glisse: well this is a key stone for improving performance and usabilities of r300/r400 especialy tex reshuffling
glisse: OipOS: i guess you need to get familiar a bit with ARB fragment program
OipOS: Guess so.
OipOS: Does it have anything useful for r500/r600?
icewaterman: glisse: this fragment optimization looks like optimizing for the pipline
glisse: well same kind of things will have to be done for r500
glisse: for r600 too likely
glisse: but this won't need same kind of change
glisse: icewaterman: yes its optimizing for the hw pipeline but the tex shuffle is also important so we don't reject program which overpass the indirection limit
glisse: this happens for instance with mplayer gl output
OipOS: What exactly is the indirection limit?
glisse: while hw can run such program
glisse: OipOS: see in references
icewaterman: glisse: those reorderings should be done by compilers, right?
icewaterman: i mean then you can have them automatically put them into an improved order
glisse: icewaterman: llvm isn't the right place for such kind oof improvement
glisse: this is low level improvement which i don't believe we can easily add to llvm framework
glisse: i think that a post stage on TGSI program might be the way to go
icewaterman: glisse: i am not familiar with llvm just with compiler flow, and standard compilers do have also low level optimizations in the backend
glisse: well i would need to go deeper in llvm to see if llvm can do what i am thinking of
icewaterman: glisse: what is llvm anyway?
icewaterman: ah, dont bother found it on wikipedia
glisse: http://www.llvm.org/ this is going to be used in gallium for glsl and others things like that
icewaterman: ah, if you use the entire set, you can also apply high-level optimizations. however this is gonna be a lot of work
OipOS: I think I'd rather increase the shader functionality than improving existing things.
icewaterman: OipOS: unfortunately the driver programmer always has to live with what there is
icewaterman: and not what he'd wish to have
glisse: OipOS: well shader for r300/r400 is pretty much complete, r500 is missing but simpsonc is trying to understand how to do it
glisse: icewaterman: llvm already work in gallium and is already producing optimized code for processor
icewaterman: glisse: ah, so you wont have to deal with that end
icewaterman: i dunno what gallium is though
glisse: icewaterman: no, either you do a backend for llvm either you ask llvm to produce TGSI and then do optimization like i presented
glisse: icewaterman: http://www.tungstengraphics.com/wiki/index.php/Gallium3D
OipOS: That was a weird sentence. Hehe.
icewaterman: ah, now i understand what you are trying to do
icewaterman: i am not very familiar with graphics-processors, i only deal with compilers on embedded systems which allow for optimizations during compile-time that take up to weeks :)
glisse: icewaterman: well fragment program are compiled once too :)
glisse: icewaterman: i have yet never seen a gl program asking for recompilation of the fragment program at each frame, i hope to never face such broken program
OipOS: glisse, what would you say is most needed or most valuable at the moment?
glisse: OipOS: strawberry icecream....hhhhmmmm :)
OipOS: Lol.
OipOS: I'm just having a hard time choosing.
glisse: OipOS: well if simple and well defined way to improve 3d support for radeon were easy to write we would have written such things since long time
OipOS: The difficulty part of it is not really of that big importance.
glisse: OipOS: if its for gsoc difficulty matter
OipOS: Well, kind of. Time is the limit.
glisse: not only time, it depend on the people too
OipOS: Though I can start on something that is outside of the timespan, and call it 'making a begin with function X'
OipOS: True, but I like a challenge.
glisse: well i think that we better have well defined aim if we want to keep having money from google
glisse: anyway right now i cant think of any other things beside simple r500 fragprog for mesa
OipOS: Not that I own an actual r500 card. Heh.
OipOS: Ah well, I'll have to weekend to think about it. Thanks for all the ideas.
icewaterman: i really would like to work on that compiler thing, but i do not have sufficient time atm, in six months i'll have finished my diploma, then i'll have a little more time (will see to i get a 40h/week job ) :)
OipOS: I'll be quite busy with all kinds of stuff this summer.
OipOS: Mainly GSoC if I get accepted, but I probably have to take some math courses to get accepted into university.
icewaterman: glisse: at my university we have a chair for graphic systems and such, maybe one of the professors wants a diploma thesis in that area, if you can specify what you want i could forward it - that way you'd get some free help :)
icewaterman: i assume the latest git drivers are at least supposed to work with standard r3xx r4xx cards as well :)
agd5f: icewaterman: yup r1xx-r6xx
icewaterman: agd5f: i'll soon test the git
berniyh: hm, one question
berniyh: will a larger virtual size affect performance?
berniyh: 2D and/or 3D?
ajax: it depends.
berniyh: ok, example:
ajax: one of either the 2d or 3d engines (possibly both, don't remember which) can't address tiled surfaces bigger than some maximum.
ajax: i know on r300 to r500 that maximum width is 3968
ajax: it's possibly smaller on r200 and below
berniyh: I've got an IGP, RS485M, currently the virtual size is 1600x2400, would extending it to 3200x2400, so I can switch between horizontal and vertical setup
ajax: but tiled surfaces are definitely a performance win
berniyh: [...] mean worse performance
acid_: hi i have a radeon 7500 mobility, when direct rendering is on i get worse performance then with direct rendering off
agd5f: lots of limits to take into account
ajax: also, if you allocate more memory to framebuffer, you have less available for textures. so if the texture set you want _just_ fits in memory now, it might not fit if you make the virtual bigger.
ajax: other than those two things, a bigger virtual shouldn't materially affect performance
berniyh: hm, ok
berniyh: then I'll try it
icewaterman: btw. i just loaded the newer kernel module driver and it claims beeing version 1.28.0 20060524
icewaterman: sounds like it is older
juanjose1: hello
OipOS: olleh
icewaterman: ok, latest git seems to be faster with glxgears on my x850
mattst88: icewaterman, weird. it was slower for me
OipOS: mattst88, weird. It didn't change the speed at all for me
OipOS: grins
mattst88: who knows :)
PSYCHO___: for me it slowed for apx 100 fps so no problem :)
icewaterman: mattst88: but i have false textures in ut
mattst88: hmm, didn't test ut2004.
icewaterman: mattst88: maybe i just should recompile libtxc
icewaterman: or well, i will just temporarily delete it
icewaterman: yepp, those errors were related to libtxc
juanjose1: hello everyone... i am partymola, but from my workplace ;)
juanjose1: i have radeon driver working, but no dri, and no accelerated opengl (i have mesa :()
juanjose1: it seems that having dri/drm working in freebsd is going to be difficult
juanjose1: but... can i have accelerated opengl without dri/drm???
icewaterman: juanjose1: no
juanjose1: ok
juanjose1: so fixing dri/drm means having opengl
icewaterman: this is because dri/drm is the acceleration api for opengl on freebsd
juanjose1: that's supposed to be done entirely by the operating system, isn't it?
juanjose1: having dri/drm on has nothing to do with the driver, right?
juanjose1: i mean, it's freebsd's people "fault", or radeon's people (you) "fault"?
MostAwesomeDude: juanjose1: OpenGL is provided by Mesa. Speedy rendering is provided by DRI/DRM.
icewaterman: juanjose1: drm/dri is the api, the driver is radeon
MostAwesomeDude: You can have OpenGL just with Mesa in software, but it's slow.
juanjose1: but having dri/drm and mesa opengl... will that have a big performance boost or not?
juanjose1: in case of nvidia drivers, it uses opengl diff from mesa's
icewaterman: juanjose1: yes
icewaterman: it will be way faster than software rendering, except if you have a really ancient card and a modern processor
juanjose1: well, i have a new laptop, with a dual core... and glxgears works at 350fps
juanjose1: i think i can have a gooood performance boost with drm :D
icewaterman: juanjose1: for comparison: i have a dual core athlon with 2800MHz each core and they are way too slow for getting googleearth working at decent speed with software rendering
juanjose1: i have dual core athlon 1.9ghz :)
MostAwesomeDude: I have 500fps without, and 2000fps with.
juanjose1: but, well, 2D works pretty fine
juanjose1: with the last changes in the last 2-3 days in git
juanjose1: i have been able to play several XV accelerated videos at the same time
juanjose1: without rendering problems
juanjose1: and i even use EXA now perfectly :)
juanjose1: (though no improvement in performance)
juanjose1: but, hey! it's awesome anyways :)
icewaterman: well there are problems with s3tc textures
icewaterman: this is kinda funny. when playing ut with s3tc textures far away look frenzy screwed and when you get near to the screwed textures, they start looking ok again
icewaterman: ut2003 crashes on start
icewaterman: File r300_texstate.c function r300SetTexImages line 301
icewaterman: DXT 3/5 suffers from multitexturing problems!
icewaterman: now i'll remove the x850 and try the rs690
icewaterman: lets see if it works at all :|
rivanvx: ivanvx
ghepeu: icewaterman, I think that's bug 8056 (http://bugs.freedesktop.org/show_bug.cgi?id=8056)
ghepeu: there're working patches but they seem to be in the limbo
icewaterman: ok
icewaterman: and there seems to be no 2d support on rs690
icewaterman: 3d support is available, but extremly slow
icewaterman: glxgears show about 435fps
icewaterman: googlearth crashes
loswillios: icewaterman: hm..
icewaterman: ut shows also wrong or defective textures
icewaterman: they stay defective on approach
icewaterman: brb, need to revert to my graphics card
icewaterman: ok, here i am, back with my x850. and btw. i will not use my 1200 card because it sucks, not because of you guys, but signal quality at the vga port is quite poor
icewaterman: but i noticed that on windows as well, so it is hardware not driver related
RoiDuClapier: Is it the right place to report my expirement with the lastest git driver?
RoiDuClapier: experiment
josemaria: yes
RoiDuClapier: OK so
josemaria: icewaterman: return it and ask for a refund lol
RoiDuClapier: My feeling is that EXA works well despite sometimes seeing a little lag in windows repainting
josemaria: and but a nice model :D
josemaria: what card model have you got?
RoiDuClapier: Asus 9550 pro
RoiDuClapier: But for 3d, it is completely unusable
RoiDuClapier: Way too slow
josemaria: have you got DRI?
RoiDuClapier: Yes everything was setup properly
RoiDuClapier: Google Earth even crashed X
josemaria: glxinfo reports that direct rendering is on?
RoiDuClapier: Yes
josemaria: ooops, a crash is a big thing
josemaria: and with XXA, there are no crashes?
RoiDuClapier: I even tried to upgrape drm and mesa to git versions
RoiDuClapier: with XAA no crash
josemaria: what about 3D performance?
RoiDuClapier: With XAA, good overall 3d performances as well
josemaria: i see
josemaria: well, as far as i know, EXA is experimental
josemaria: maybe a developer can help you better
RoiDuClapier: I know
josemaria: after the crash, did you get some message in the Xorg log file?
josemaria: anything that can help debugging the problem¿
RoiDuClapier: But so many people here seem to have godd 3d perfs with EXA enabled
RoiDuClapier: No messages that signaled an error
josemaria: well, i have no DRI and Mesa 3D ...
josemaria: not even with XAA
josemaria: so i am envious of you lol
RoiDuClapier: OK
RoiDuClapier: :)
RoiDuClapier: But I had to tune my confs to get good perfs
josemaria: changed the confs gave you a big or a small increment of performance?
josemaria: and what changes did you do? :)
RoiDuClapier: At first it did not want to work in AGP mode
RoiDuClapier: But I found that it was AGPFastWrite that caused that
josemaria: so you enabled or disabled it?
RoiDuClapier: After removing the offending option, every thing began to run smoothly
RoiDuClapier: disabled
icewaterman: josemaria: well, i like the mainboard, but the integrated graphics sucks, besides the board was quite cheap, so i cant expect too much
icewaterman: and the x850xt is way faster
RoiDuClapier: And add to disable fallback for Google Earth
josemaria: well, my laptop costed me 400 euro... i can't complain too much either lol
RoiDuClapier: had
icewaterman: and was 20 bucks, so whatever
icewaterman: josemaria: the mainboard was 45€
josemaria: well, integrated cards use to suck :D
RoiDuClapier: Mainely due bye the fact they share main ram with the motherboard
RoiDuClapier: by
RoiDuClapier: I think
josemaria: and because they are cheap models with less circuitry
agd5f: icewaterman: rs690 has 2d support, all radeons except r6xx do
josemaria: yesterday we bought a mainboard who had an integrated soundcard... and it's really an USB sound card connected via an internal USB bus :/
icewaterman: agd5f: xvinfo didnt show up anything
agd5f: icewaterman: xvinfo has nothing to do with 2D. it shows you Xv adapters which are for video acceleration
agd5f: icewaterman: also, rs690 has Xv support, you just need to update your driver
icewaterman: agd5f: sorry, i meant xv :)
icewaterman: agd5f: ah ok
icewaterman: but there is still the bad video quality due to cheap hardware
RoiDuClapier: josemaria: I changed my mainboard two years ago and finally ended up plugging my "old" SBLive because the sound quality sucked... You have the quality you payed for ;)
icewaterman: agd5f: first i thought it was just a gamma issue
agd5f: icewaterman: ?
icewaterman: agd5f: not the drivers fault
agd5f: icewaterman: if you haven't even tried the driver how do you know?
icewaterman: agd5f: at least the vga port serves cheap video signal
icewaterman: agd5f: i tried the driver
agd5f: xv works fine on my rs690
icewaterman: agd5f: it showed no adaptors present
RoiDuClapier: Anyone knows wich scaling algorithm is use by radeon hardware ?
icewaterman: agd5f: but i only replaced r300 and mesa stuff, so probably i missed the 2d part
icewaterman: but the video quality i meant was not the video playback quality
icewaterman: i meant the video signal arriving at the monitor
agd5f: icewaterman: ah ok
agd5f: RoiDuClapier: whatever the hw implements
icewaterman: simply desktop, it looked like it had been lightened up, but reducing gamma didnt help and the same issue appeared on windows
RoiDuClapier: agd5f: And what does hw implements?
icewaterman: ok, my mainboard with integrated graphics was 45€ and the x850xt was almost 10 times as expensive when it was released so you can expect better parts beeing used :)
agd5f: RoiDuClapier: don't know
RoiDuClapier: agd5f: I tested mplayers lanczos scaler and found a slight difference with the hardware scaler
RoiDuClapier: agd5f: It was slightly better with lanczos
agd5f: RoiDuClapier: could be. you can also adjust most aspects of the transform engine using Xv attributes
agd5f: that might improve things
RoiDuClapier: Is the scaler can be corrected by microcodes?
agd5f: RoiDuClapier: no
josemaria: maybe, but i think that'll hurt performance. lanczos is not very performant, right?
josemaria: dang!
agd5f: RoiDuClapier: you could write your own scaling or use the lanxzos one with shader instructions
RoiDuClapier: josemaria: lanczos works fine on DVD resolutions with a decent processor
josemaria: what mplayer option do you use to activate it?
RoiDuClapier: josemaria: -sws 9
RoiDuClapier: josemaria: with -vf scale
josemaria: ok
josemaria: will try it later
icewaterman: i can still help debug driver for x850 :)
josemaria: i can help too
josemaria: ... complaining lol
RoiDuClapier: agd5f: So an XvMC extension that supports H264 would use shader instructions?
TobiasTheCommie: can someone explain to me how texturedvideo is different from xvideo, i've tried google but i don't really find anything...
agd5f: RoiDuClapier: it could for some stuff
TobiasTheCommie: in which way is texturedvideo better?
agd5f: TobiasTheCommie: the both expose Xv adapters, they just implement the functionality with different parts of the chip
TobiasTheCommie: oki
agd5f: textured video uses the 3D texture engine to render the video
TobiasTheCommie: i just keep hearing texturedvideo is superior
agd5f: an overlay uses an overlay
agd5f: it has advantages
TobiasTheCommie: so, it isn't something where texturedvideo uses the avivo chip(or something other) to help decode video
TobiasTheCommie: damn
icewaterman: RoiDuClapier: some people once implemented solving of complex math problems by transforming them into opengl programs :)
agd5f: on most hw there is only one overlay, while you can render as many textures as you want
agd5f: so you you can display several several videos at once using textured video
ghepeu: textured video is also composite friendly
TobiasTheCommie: i could do that with normal xv as well
agd5f: with an overlay the data is overlaid during scan out so it can't be blended or redirected so it doesn't work with composite
icewaterman: agd5f: i once had an nvidia card, and they managed somehow to allow playback of serveral xv videos
agd5f: icewaterman: yeah they probably uses textures or YUV scaled blits
TobiasTheCommie: agd5f: i will admit that i've never noticed a problem with xv while composite have been on... but maybe i just think i had composite on and really didn't...
icewaterman: agd5f: besides i fail to see why one would want to play back 2 videos at once?
TobiasTheCommie: oh well, in any case, very enlightening, thanks agd5f
ghepeu: TobiasTheCommie, just move a window over the video
icewaterman: except if he wants to immitate robot-chicken
agd5f: TobiasTheCommie: you can turn on the extension, but but you need a composite manager like compiz or xcompmgr to use it
ghepeu: the part of video over the shadow becomes black instead of being blended
ghepeu: *under* the shadow
TobiasTheCommie: ghepeu: i have always had the video on display 0.1
agd5f: icewaterman: video conferencing
TobiasTheCommie: and no windows on display 0.1
TobiasTheCommie: so, that sitation never happened for me :D
agd5f: TobiasTheCommie: that's another issue with overlays, they can only be sourced to one crtc at a time, so your videos can span multiple heads
agd5f: can't
TobiasTheCommie: agd5f: ah, i have seen problems while compiz have been running
TobiasTheCommie: hence why i don't run compiz anymore
TobiasTheCommie: but, you say, with texturedvideo i can use compiz at the same time?
agd5f: TobiasTheCommie: yes
agd5f: and you can have alpha blended wobbly windows
TobiasTheCommie: very very nice
TobiasTheCommie: :D
TobiasTheCommie: i look forward to that
icewaterman: agd5f: ok, thats indeed an useful application
edgecase: ok apparently X300 will boot up with composite out, using the 7-pin Component HDTV cable
edgecase: woot!
edgecase: works with s-video cable also
MostAwesomeDude: Howdy. Looking through TCL, is there any reason why the old programs won't work for the r5xx?
MostAwesomeDude: Or maybe I'm just not emitting them right.
airlied: MostAwesomeDude: I hadn't checked if I had enabled TcL..
airlied: but wierd it didn't work.
MostAwesomeDude: airlied: I used "chip_flags = RADEON_CHIPSET_TCL" at the appropriate place and was rewarded with a blank window.
MostAwesomeDude: I figure it must be some emission problem.
airlied: at least it doesns't hang. :)
MostAwesomeDude: Yeah.
MostAwesomeDude: airlied: Yeah, just went over the register docs. There's no differences in the vertex shader from r300 to r500 on paper.
RoiDuClapier: Hi guys, I'm back with hardware video playback questions. Is it planned by AMD to release doc about that matter in the near future?
RoiDuClapier: I'm not talking about XV but mpeg2 hw decoder
airlied: MostAwesomeDude: I'll take a look later, leave TCL off for now, and play with frag shader :
MostAwesomeDude: 'k.
dmb: 3d for r5xx yay!
dmb: guess not yet for x1400 mobility?
TobiasTheCommie: i believe it is in the r500 branch, and not in the normal trunk yet...
TobiasTheCommie: not sure though..
dmb: is there a link to web git for the r500 branch?
dmb: TobiasTheCommie: where is that branch?
MostAwes1meDude: ...
MostAwes1meDude: Stupid IRC, not knowing who I am.
MostAwes1meDude: Oh well.
MostAwes1meDude: airlied: Okay. So I'm using screensavers to test shaders. They run slow because of SW TCL, but they run ugly because of broken shaders.
airlied: MostAwesomeDude: yeah you should be able to do get the r500 shaders to r300 levels at least with the current tree,
airlied: I'll get some more time post-Easter to fix the go fast :)