soreau: Seems the code under 'get modes' is nearly the same as what 'Set display0/1 priority' code does
Lutz_Ifer: what videocard does #radeon recommend for a new desktop computer?
soreau: Hell, maybe I'll just try Option "DisplayPriority" "HIGH" and see what happens :P
soreau: Gah (WW) RADEON(0): Option "DisplayPriority" is not used
wayland76: Lutz_Ifer: I recommend a FireMV 2400 so that you can use multiple displays. But you first have to tell us what your needs are -- Do you want to play games? Have multiple screens? Something else?
MostAwesomeDude: I would *not* recommend a FireGL. Shit's spendy.
MostAwesomeDude: You can have multiple displays with any multiple-output card, and there's plenty of 'em.
Lutz_Ifer: atm i'm running a dual-monitor setup, and i'd like to keep that. another important point is that it just WORKS (ati xpress 200m took me about 2 years to get it to work, and even now there are plenty of glitches etc), including 3d acceleration, preferrably using open-source drivers
soreau: agd5f: There's no corruption without kms regardless of that option. Only happens with dri2 and X doesn't recognize the option
agd5f: soreau: that option only works with non-kms
agd5f: right now
soreau: and I have no idea what to do in order to get it for kms
soreau: Does the only change need be made in r100.c?
spstarr: well i have a kernel built, now i need firmware and im good to build mesa finally
agd5f: soreau: port this code to kms: http://pastebin.com/m504e9df8
agd5f: soreau: port this (http://pastebin.com/m504e9df8) to r100_bandwidth_update
agd5f: soreau: you'll either have to force it on or add a module option to set the priority high
soreau: agd5f: I found that code but it looks suspiciously similar to the code in r100.c where airlied pointed to http://pastebin.com/m6b1a6203
agd5f: soreau: rdev->disp_priority == 2 won't happen since there's no module option
agd5f: so make it if (ASIC_IS_R300(rdev)) { to force it on
soreau: ok
DanaG: oh hey, who was it that had the AMT and wifi stuff?
DanaG: It looks like AMT+iwlagn finally works.
soreau: agd5f: Yup, that fixed it for now
soreau: agd5f: Can Options in xorg.conf set module options?
soreau: or how does that work
agd5f: soreau: nope
spstarr: doh
spstarr: koji wins
spstarr: your kernel is done before me ;)
spstarr: aborts
agd5f: need to add them as kernel module options or make them runtime adjustable by adding htem to sysfs
soreau: agd5f: Funny you mention sysfs because on boot I get a message saying udev might not work because I need to disable SYSFS_DEPRECATED but I don't think I'm supposed to do that
spstarr: agd5f: yes, having the gpu settings in sysfs lets userspace people create gui tools to adjjust stuff
spstarr: adjust
spstarr: via PolicyKit and fun
spstarr: all sorts of interesting things
soreau: agd5f: Anyway, thanks :)
agd5f: soreau: np
soreau: and udev works fine afaict btw
agd5f: soreau: not sure what SYSFS_DEPRECATED refers to
vehemens: agd5f: saw your vertex shader comment. any idea how long the work will take?
agd5f: vehemens: few days maybe a week
spstarr: hmm that's a funky boot up sound
spstarr: a lower squeal to higher pitched to none
agd5f: vehemens: you can work around it (at least for engine) by re-compiling the shader for every draw
agd5f: teh vertex shader
vehemens: i'm still learning the basics. you suggesting something from the advanced class.
Nightwulf|work: hi all
spstarr: agd5f: when do you think the gallium work will begin for r6xx/r7xx/some tree name i can't remember :)
MostAwesomeDude: spstarr: When I get to it.
spstarr: or will it be easier to port the newer mesa dri code to gallium
spstarr: MostAwesomeDude: do you think it will be easier to port it over ?
agd5f: spstarr: when the current 3d driver is further along
airlied: and when the kernel works
spstarr: was just wondering
Zajec2: that prediction... should it improve performance?
spstarr: well, eventually we want to cut away from mesa dri framework to just strictly gallium?
spstarr: or will we have this dual track for sometime?
airlied: until gallium drivers work
airlied: and are more useful
spstarr: fair enough, i haven't seen any really in use
spstarr: I guess it is good that we have this dual track, the proven approach vs 'unproven'
airlied: I might get shot for suggesting the only shipping gallium driver is binary ;-)
spstarr: ha
spstarr: mesa built, time to install all this stuff and test EXA corruption issues
spstarr: i might try 3D limited
airlied: glisse: can you look at the SQ_CONFIG stuff you don't do in KMS kernel?
airlied: glisse: we may need to do some of that in userspace if you removed it from the kernel
airlied: home &
spstarr: oh bad
spstarr: glxgears
spstarr: Xlib: extension "GLX" missing on display ":0.0".
spstarr: Error: couldn't get an RGB, Double-buffered visual
spstarr: i cant even run any OpenGL
spstarr: oh wait...
spstarr: this may be cause of the generated xorg.conf..
spstarr: will confirm
spstarr: bad
spstarr: glxinfo
spstarr: name of display: :0.0
spstarr: Xlib: extension "GLX" missing on display ":0.0".
spstarr: Error: couldn't find RGB GLX visual or fbconfig
spstarr: no GL at all
spstarr: no GLX extension?
spstarr: ooh
spstarr: n/m
spstarr: er
spstarr: yeah i got problem
spstarr: at least 2D has no corruption so far
mikkoc: glxgears doesn't work with mesa master
mikkoc: IRQ's not enabled, falling back to busy waits: 2 18
mikkoc: Mesa: Initializing x86-64 optimizations
mikkoc: Mesa: 3Dnow! detected
mikkoc: drmRadeonCmdBuffer: -22
spstarr: i dont even get that far today
spstarr: it just fails to find a GL visual :)
mikkoc: i updated libdrm and xf86-video-ati too... just in case..
mcgreg: you broke mesa? ;)
mikkoc: i have r620
spstarr: mcgreg: I didn't
spstarr: no GLX extension even
spstarr: libglx.so is there
spstarr: uh oh
spstarr: (EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/libdricore.so: undefined symbol: _glapi_SingleThreaded)
spstarr: another broken symbol
spstarr: no wonder :)
spstarr: it just totally blew up
mcgreg: I said yolu broke mesa :P
spstarr: hehe
mikkoc: spstarr: u need to recompile xserver i think
spstarr: this is newest X server in rawhide :P
spstarr: boo
mikkoc: http://www.phoronix.com/forums/showpost.php?p=88753&postcount=330
mikkoc: did u recompile it?
spstarr: my 3D stop ends here then until rawhide builds
spstarr: looks for a new X build in koji
spstarr: there is but i dont know if its new enough
spstarr: so i will just hold on 3D and be thankful 2D looks not corrupted at all now :)
spstarr: vt switching however
spstarr: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 19
spstarr: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 29
spstarr: [drm:radeon_cp_indirect] *ERROR* sending pending buffer 25
spstarr: DMAR:[DMA Read] Request device [00:1b.0] fault addr 0
spstarr: DMAR:[fault reason 07] Next page table ptr is invalid
spstarr: DRHD: handling fault status reg 3
mcgreg: thats not really looking nice ;)
spstarr: DMA issues with GPU?
spstarr: hence the stallout
Zajec3: someone should change topic here :)
Zajec3: to same "experimental 3D"
nanonyme: Hmm, by backlog sounds like the threading symbol issue really was an issue to someone else too... Surprising there's only one person complaining though.
airlied: osiris_: I think s3tc used to also enable if lib dxtn was installed
nanonyme: Actually slightly dubious that the only other problem system was with the same distro as I had.
g-zu: nanonyme: not at all, I'd guess you have quite a lot of custom things on your system which don't come with the distro
nanonyme: airlied: Any speculations? :) Is there any reason why Rawhide could break worse by the missing symbol problem than other distros? (I assume you know the new components better than I do)
airlied: sounds liek something broke the libGL/dri interface
airlied: and aiglx got hit
nanonyme: Yeah, you're right and I know the commit.
nanonyme: Mostly wondering if there's any reason why it should affect new X.org components more than old ones.
nanonyme: Since the only other person than me complaining about it was spstarr and he has Fedora Rawhide too.
airlied: it depends on how the X server is built I suspect
fpoibaf: I am having the same problem on Ubuntu...
nanonyme: Oh, thanks. ;)
nanonyme: That's a relief.
nanonyme: It was a generic glapi thing, I *expected* people to have problems. I was shocked not to hear more people complain...
nanonyme: Should've affected all Mesa drivers.
fpoibaf: nanonyme: http://www.phoronix.com/forums/showthread.php?p=88742
fpoibaf: from comment 327
nanonyme: The funky part of the commit is that it only breaks things if you restart X.
nanonyme: If you just do make install, you might have the false belief that it works fine.
nanonyme: Oh, agd5f had the solution there. <3
glisse: airlied: i pushed X recycling patch to the ddx
glisse: bit improved since yesterday avoid doing any realloc
nanonyme: As in, recompile X server.
nanonyme: Will try straight away.
fpoibaf: nanonyme: http://marc.info/?l=mesa3d-dev&m=125119106917083&w=2
nanonyme: Hmm.
nanonyme: If it was up to me, I'd just revert the commit until the the symbol gets into a release version of X server but luckily it's not. ;)
nanonyme: According to that conversation.
fpoibaf: a git revert don't work with current mesa master
nanonyme: Eh, what?
fpoibaf: git revert 17090cf3efb0db8fa01b502a9c0df27cbd1a67da
fpoibaf: error: Entry 'src/mesa/glapi/glapi.c' not uptodate. Cannot merge.
fpoibaf: fatal: merging of trees 3349ca203b1e89fffc6d64776b5902f69dbaf0a2 and 3f70139561702fef36b04c7d9f9c6b9a0eb74527 failed
fpoibaf: Automatic revert failed. After resolving the conflicts,
nanonyme: git revert 17090cf3efb0db8fa01b502a9c0df27cbd1a67da # done
nanonyme: fpoibaf: The problem is your repo is not uptodate.
nanonyme: Not that it wouldn't work.
nanonyme: Make sure you don't have any uncommitted local changes.
fpoibaf: it's updated but it does not work here
nanonyme: Works here. ;)
fpoibaf: are you on latest master?
nanonyme: Yea, just did a git pull
nanonyme: You could try git reset --hard && git pull
nanonyme: Then seeing if it still complains on revert.
nanonyme: Anyway, nice to finally understand the issue properly.
fpoibaf: I am doing a new git clone
nanonyme: Waste of effort bandwidth...
nanonyme: Doing rm -rf * && git checkout -f in your git repo does the same thing.
nanonyme: Effort and bandwidth even.
JohnDoe99: linux bd :beer: :)
nanonyme: Fine, waste of beer. ;)
fpoibaf: ok, it works with git reset --hard && git pull
nanonyme: You probably had uncommitted local changes.
nanonyme: (or weren't at latest git)
nanonyme: Unsure which causes it.
nanonyme: Having uncommitted local changes might prevent you from getting ot latest git in any case.
fpoibaf: I had no local changes, I was after a clean git clone
nanonyme: Hmm.
nanonyme: I dunno. Sometimes seems like files end up in unsynchronized state even when you don't touch them.
nanonyme: One of those little mysteries of life.
suokko: nanonyme: Threading symbol doesn't affect many people. for example I have package version for AIGLX and another self compiled in /opt. So I can run both without problems ;)
nanonyme: :p
fpoibaf: suokko: how do you switch between the two, with export LIBGL_DRIVERS_PATH
suokko: fpoibaf: +LD_PRELOAD for libGL.so
jcristau: or LD_LIBRARY_PATH.
suokko: that works too
suokko: And is probably he better option
suokko: /he/the/
fpoibaf: Ah, OK, indeed I noticed it that with LIBGL_DRIVERS_PATH only changed the drivers dir but not the libGL...
nanonyme: suokko: I still think it's not a very nice commit though. :p
suokko: nanonyme: But it as to be done :/
nanonyme: suokko: First in X server, then in Mesa?
nanonyme: Should've avoided breakages.
suokko: nanonyme: Did you tough that loading old dri driver might fail after x change? ;)
airlied: I'm sure there'll be some discussion on the mailing list
airlied: its already been mentioned
nanonyme: suokko: I didn't read anywhere that it should break new libGL.so + old DRI driver, just new DRI driver + old libGL.so.
nanonyme: Either it wasn't said clear or it's a one-way breakage.
suokko: I don't know. I didn't review the changes
nanonyme: I doubt it'd be so bad if we'd have an unused symbol in X server until the release lands in distros.
nanonyme: (or at least until the changes end up in a release at the very least)
suokko: When will mesa 7.6 release come? Is there some release feature list?
airlied: not really whenever Brian decides generally
airlied: we used to have to beat releases out of him for X.org releases
nanonyme: Btw, would EXANoDownloadFromScreen affecting corruption under Compiz imply EXA and OpenGL are still battling for control of the GPU? :)
nanonyme: (instead of co-existing peacefully)
suokko: Sounds like exa might not do some cache flush or wait foridle
nanonyme: Read from forums it helped for someone with r600.
nanonyme: suokko: Hmm, yeah. Maybe it's waiting for 2D engine to be idle instead of 3D engine to be idle at some place? :3
nanonyme: (dunno exactly what that would do in an r600 since it doesn't even have a 2D engine)
suokko: nanonyme: probably just enough to check that cache flush happens after and before text rendering :)
nanonyme: (actually seems wait for 3D engine and 2D engine is lower level anyway)
nanonyme: Ergo unrelated. Your guess is probably better.
nanonyme: Appears r600 has its own R600DownloadFromScreen in any case.
nanonyme: (which does RADEONWaitForIdleCP)
nanonyme: suokko: Hmm, if I install over system libraries with the threading race handling commit reverted and then another set non-reverted and use environmental variables to use the ones with it non-reverted, it should work?
suokko: nanonyme: yes. You will need 2 local git branches for that so one of them has the revert commit ;)
nanonyme: Well, not necessarily unless I want indirect rendering...
nanonyme: Just need something that X will like when it wants to initialize dri.
nanonyme: Wonder if it would seriously just be easier to fix X server and be done with it. :P
suokko: It is easier. You just have to add the symbol to glx module.
nanonyme: Just did that.
nanonyme: glapi.h's seem to be at least roughly identical.
nanonyme: The sucky thing is that eg my inputproto is too old so I have to update a few dependencies too.
nanonyme: (that's what you get for living between two X.org releases, I guess)
nanonyme: suokko: But yeah, if this is all the change that's required, should be no harm putting it into X server first and only then into Mesa.
nanonyme: thinks
nanonyme: Since the variable doesn't get read in X server
nanonyme: (or even putting it into glxapi.h's on both sides first and adding handling into Mesa later)
nanonyme: Maybe even have a version bump in glx.
suokko: I wonder why it required renaming of a variable
nanonyme: As far as I've understood it didn't.
nanonyme: Agh, glapi, not glxapi. >.<
nanonyme: bumps head instead
nanonyme: suokko: "Since _glapi_Context or _glapi_Dispatch are no longer reset, _glapi_SingleThreaded is tested instead, before accessing them."
nanonyme: That's the important sentence as far as I can see.
suokko: nanonyme: It removed threadsafe variable and replaced it with new ont
nanonyme: suokko: To me that sounds like two variables.
suokko: -static GLboolean ThreadSafe = GL_FALSE; /**< In thread-safe mode? */ vs +GLboolean _glapi_SingleThreaded = GL_TRUE; /**< In single-thread mode? */
nanonyme: Blah, right.
nanonyme: That's a good point.
nanonyme: The first one's static though, the second one's extern.
nanonyme: Erm.
nanonyme: Non-static even.
nanonyme: (extern naturally in glapi.h's)
nanonyme: As in, ThreadSafe probably wasn't shared between X server and Mesa either.
nanonyme: (and as a choice for a name as a shared variable it's quite a poor one)
suokko: yes. It requires symbol change anyway if done thatway
suokko: wonders what would be cost to have per thread variables in single threaded case
nanonyme: I suspect it'd create quite a bit more confusion in X server if they'd have introduced ThreadSafe there.
nanonyme: (Since it doesn't imply X server is threadsafe, just that glapi is threadsafe)
nanonyme: So yeah, I think the name change is perfectly justified.
nanonyme: (if you want to implement it that way)
nanonyme: (implementing it that way does create a chicken and the egg problem though)
suokko: wonders why pthread_getspecific is expensie call
nanonyme: Right, I'm done with my monologue. Carry on. ;)
nanonyme: Arrrgh.
nanonyme: Doing the change in X server wasn't enough. :(
suokko: I think that pthread_getspecifig should be as fast as glapi implementation to check for threading if we just get data to the first block
suokko: too bad that means function call overhead. So if we just could inline that call it should be perfect solution ;)
suokko: So problem looks more like that gcc can't do link time optimization (which would help a lot in mesa code too if there was link time inlining for some functions)
nanonyme: Yeah, gcc sucks, let's make a better utility. ;P
jcristau: or you can build with tls and you don't have that problem
hifi: pcc
nanonyme: jcristau: Hum?
nanonyme: Oh, right.
jcristau: afaict the problem only exists if !defined(GLX_USE_TLS)
nanonyme: Is this yet again one of those patent problems?
jcristau: no
nanonyme: Why's it disabled by default then?
jcristau: not all platforms have tls
nanonyme: Ah.
suokko: pthread_key_create looks naive solution :P for loop to find free thread local slot ;)
nanonyme: jcristau: Which Linux distros do you know that *do* enable it?
suokko: That is going to hurt performance if application is creating large number of thread local variables
jcristau: nanonyme: for mesa? debian and ubuntu at least.
nanonyme: jcristau: No, on X server side.
nanonyme: Since it apparently needs to be explicitly enabled on both sides.
jcristau: yeah we enable it on both
jcristau: since server 1.5 and mesa 7.2 or so
nanonyme: Hmmm, wonder if it's on Fedora.
nanonyme: Apparently no.
nanonyme: jcristau: Yeah, you were right. Works now.
nanonyme: And yeah, found out the reason too.
nanonyme: Fedora doesn't have GLX TLS because SELinux doesn't play along with it properly.
jcristau: that's sad.
ajax: well, more because i haven't bothered to fix it to be selinux-friendly.
ajax: on the grounds that anyone worrying about dispatch speed is ricing the wrong bit of their civic
ajax: PGA though
jcristau: now i'm wondering if i should pass --enable-selinux to mesa configure..
suokko: ajax: Someone has raised worry about the speed already when not using thread local variables all the time
nanonyme: ajax: What's the actual problem with GLX TLS and SELinux? Haven't found any issues yet with threaded OpenGL.
nanonyme: Everything I've been able to find so far has been you saying in a bug ages ago it doesn't work. :)
nanonyme: Determining if it's still broken is a tad hard when one doesn't know when exactly it should be broken.
suokko: Try to trigger one of bug reports
jcristau: enable it. look for avc denial errors.
nanonyme: suokko: It was a bug report of missing symbols due to missing GLX TLS ages ago...
nanonyme: jcristau: None that I can see.
nanonyme: jcristau: And I didn't pass --enable-selinux to Mesa configure. Only now learned there was such a switch. :)
jcristau: nanonyme: i didn't know about it before looking at rawhide's mesa.spec 20 minutes ago :)
nanonyme: Interesting...
nanonyme: I suppose I should enable it for consistency then.
nanonyme: (though it obviously isn't required)
nanonyme: What's the point of having applications be SELinux-aware anyway? :P Isn't the point of SELinux just make sure the programs don't do stupid stuff? ;)
nanonyme: (which might influence application writers to write more secure code for non-SELinux platforms too)
nanonyme: Apparently --enable-selinux isn't required and has a negative impact on performance.
nanonyme: Should probably be removed.
suokko: nanonyme: You don't have strict enough selinux configuration
nanonyme: suokko: Well, at the very least should be disabled in Fedora since I'm using Fedora configurations. :)
nanonyme: s/should/might be able to/
suokko: nanonyme: But if Fedora user configures stricter selinux settings there has to be thatextra code
nanonyme: suokko: Surely then the problem is between the monitor and the chair?
suokko: Not really. Someone might want to prevent execution of code from outside system libraries so SElinux would prevent mesa from allocating page with execution flag set.
suokko: or better say outside distro binaries
nanonyme: I thought it did do that by default.
nanonyme: Well, it's not like I couldn't take compiling X server and Mesa myself.
agd5f: nanonyme: EXA and GL don't "fight" for the GPU. they accelerate 2 different APIs. DFS on radeon has been problematic for some users since it was added.
agd5f: rendering to small buffers in vram (which is what is done with DFS) seems to have caching issue with small pixmaps. the rendered data doesn't always seem to hit system ram before the CPU copies it out to the pixmap
suokko: agd5f: Which one is first in cp? cache flush or scratch register write?
agd5f: suokko: cache flush
suokko: just checking ;)
agd5f: suokko: http://bugs.freedesktop.org/show_bug.cgi?id=18397
glisse: agd5f: btw did invalidating hdp cache before cpu access helped in those cases ?
agd5f: glisse: I don't think so IIRC, but it's been I while since I looked at it
_Groo_: hi/2 all
_Groo_: im having a problem with today mesa/ddx/drm with dri2 build
_Groo_: AIGLX error: dlopen of /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_SingleThreaded)
glisse: agd5f: rs400 is combios only right ?
_Groo_: anyone knows whats the problem?
_Groo_: glisse: hi glisse
agd5f: glisse: yes
_Groo_: hi agd5f
MrCooper: glisse: we aren't reading via the HDP there
_Groo_: im using latest git for mesa/drm and ddx, latest linus rc6 (still didnt updated to 7 but it shouldnt be an issue)
fpoibaf: _Groo_: you have to revert a patch:
fpoibaf: git reset --hard && git pull && git revert --no-edit 17090cf3efb0db8fa01b502a9c0df27cbd1a67da
_Groo_: fpoibaf: in mesa?
fpoibaf: yes
_Groo_: fpoibaf: or ddx or drm? lol
_Groo_: fpoibaf: ok testing
glisse: MrCooper: i wonder if hdp cache is involved in dma to sysram don't think so thought
_Groo_: devs, any ETA on the auto scaling implementation for LVDS display?
_Groo_: are compressed textures working now (AKA googleearth bug)
agd5f: _Groo_: probably sometime in the 2.6.32 timeframe
_Groo_: agd5f: ok, for both features?
agd5f: _Groo_: I'm not familiar with the second issue
_Groo_: agd5f: could you guys blog when youll be adding stuff to the 2.6.32 kernel, or a new blog post about using git branches for new stuff?
_Groo_: agd5f: googleearth and other apps use compressed textures which arent implemented yet (theres an open bug by me)... it crashes the app
agd5f: _Groo_: I'll try and let you know when I add the scaled modes by default
_Groo_: agd5f: thanks
suokko: simple test app to test the pixmap corruption: copy data in memory, request UTS, copy data in vram, request DFS, copy data in memory. That way we can later check which data is corrupted and if the data is later correct in memory (too fast access or cache issue)
suokko: Any possible problems that I forgot to test with that?
agd5f: suokko: you might not be affected :)
suokko: btw, Is that corruption only with agp or also with pcie?
suokko: agd5f: I have buggy agp to test it with ;)
agd5f: suokko: all. agp/pci/pcie, but only certain users are affected
suokko: and My glyph cache gets corrupted sometimes even if I limit gart sizes to 128M
agd5f: suokko: agp is always a problem. DFS is disabled by default on AGP
suokko: That glyph corruption happens only when I run some 3D applications
suokko: agd5f: not in kms. And I have some corruption even when I disable DFS
agd5f: suokko: does it go away when you use pci mode?
suokko: I didn't see that corruption in pci mode but I didn't either play nexuiz or any that kind of 3D game so I'm not sure if it fixes the problem
suokko: nanonyme: Can you check, fix and improve build instructions that I just wrote to the wiki? http://xorg.freedesktop.org/wiki/radeonBuildHowTo
suokko: agd5f: That kind of small program could be given for user having the problem and we could get useful diagnostic info what is broken in that hw
MrCooper: suokko: have you tried radeon.test=1?
MrCooper: ah yes, you did
suokko: MrCooper: yes. it fails after 128M
MrCooper: well it does basically what you described :)
suokko: Does it do that data copy to check when error happens?
glisse: suokko: via chipset right ?
suokko: And does ittest different size operations? :)
glisse: iirc
MrCooper: yeah and no
glisse: i don't think operations size matter too much
suokko: So in case a small transfer is problematic
suokko: location only?
glisse: well small operation might be hitting the wc stuff
glisse: i think there is a way to ask the gpu to flush wc buffer
MrCooper: glisse: WC matters only for CPU writes, not reads
suokko: But it would be nice if there as user space application that was simple to run fro running system ;)
glisse: MrCooper: gpu has a wc buffer too
MrCooper: I think it's something between the GPU and CPU which isn't covered by the flushes / busy checks
glisse: MrCooper: iirc the wc cache of the gpu is in the mc somewhere, iirc i saw it mentioned in some doc
glisse: can't remember which
agd5f: you can turn off wc in the HDP
agd5f: but I don't think that affects gart
suokko: What about adding some extra data to end of transfer which we can check for ready status? (optional feature for problematic hw configuration)
suokko: If the end of transfer is guaranteed to be the last part transfered
agd5f: I suppose we can pad the xfer to a size large enough to affect the problem, then just skip that data when we copy from gart to pixmap
agd5f: s/affect/avoid/
Terman: suokko: hust a hint on the url you pasted above: I copy additional kernel modules into /lib/modules/`uname -r`/extra/ (opensuse 11.1)
Terman: and run depmod -a afterwards
Terman: also, the page displays }}} near the very bottom
suokko: Terman: good point. Do you want to do the changes? :) (help is welcome)
Terman: suokko: sorry, not during the next two days
suokko: I can do it too. But I think quality improves if there is more editors doing minor improvements
MrCooper: agd5f: I think suokko's idea is actually neat: put sentinel data at the end of the transfer and then wait for that to appear
agd5f: MrCooper: yeah :)
suokko: MrCooper: only problem is that if transfer can happen out of order (like for cpu cache)
ajax: nanonyme: it requires that the application be in allow_execmem_t, ie, that it can have writable code segments.
ajax: nanonyme: one, that's the sort of thing that makes security holes a lot easier to exploit. two, that's a _lot_ of applications to label, since labeling is per-app not per-DSO.
nanonyme: ajax: Check.
Sinuvoid: Mate
nanonyme: That too.
Luzipher: suokko: I like your build instructions on the wiki. Does give me a better understanding of why to do something ;) You might want to add the option to patch one's kernel sources for "Experimental 3D support for r600/r700" with agd5f's patch at http://www.botchco.com/alex/xorg/http://www.botchco.com/alex/xorg/0001-radeon-drm-Add-3D-support-on-r6xx-r7xx-chips.patch
MrCooper: Luzipher: it's a wiki
Luzipher: yeah, but I'm not allowed to change the page and I can't find a registration link ... :)
Luzipher: ah ok ... forget my last comment ...
suokko: I think that register link is a bit too hidden there.
agd5f: MrCooper: this seems to fix DFS for me: http://www.botchco.com/alex/xorg/fix_exa_dfs.diff
suokko: agd5f: Wouldn't it be better if you just pad the transfer to 32x32 at minimum?
suokko: Maybe not
agd5f: suokko: I thought about that, but if the image lies at the end of vram or something you may run into an issue
suokko: yes. That is the safest way to do it
MrCooper: agd5f: cool, hopefully that'll do the trick for everyone...
suokko: agd5f: Does that work also for less than 16x16 images?
agd5f: suokko: I hope so
agd5f: works for animated cursors. whatever size those are
Luzipher: hm, I added the changes for patching kernel sources to the wiki and fixed a few typos.
suokko: Luzipher: thanks
Luzipher: np :)
suokko: It looks like old drm interface was not multilib safe :/
nanonyme: I hope the new one is though.
BeteNoire: hi
BeteNoire: anybody alive to help? :)
nanonyme: Does undead suffice?
chainsawbike: or maybe sleep-irc'ng
glisse: BeteNoire: ask your question
BeteNoire: yep, i'd prefer undead :)
BeteNoire: btw. my screen goes white/gray when switched to tty
BeteNoire: sometimes laptop hangs, sometimes not
BeteNoire: its a x200m card
BeteNoire: didnt happen with fglrx but ati stopped supporting this chip :/
glisse: BeteNoire: using radeonfb ?
phoenix64: argh, "Mass version move, cvs -> git" - hit the limit of my free email account -.-
suokko: Quite small limit for mailing list box
BeteNoire: glisse: suspecting that it may cause a problem i disabled it, but the problem is still
phoenix64: suokko, web.de, 500 emails max
suokko: It was only 650 mails ;)
suokko: dri+mesa total
glisse: BeteNoire: module might still be there
glisse: you sure radeonfb is not active ?
BeteNoire: disabled in config
BeteNoire: kernel rebuilt
glisse: BeteNoire: does issuing vbetool post when in console helps ?
BeteNoire: ?
glisse: ie when not under X
glisse: when switched to a tty
BeteNoire: not under x and switch to tty?
BeteNoire: sry, i don't get it
glisse: switch to a tty
glisse: ie not under X
glisse: crtl-alt-2
glisse: for instance
glisse: well where you see the bug
glisse: if i understand under X everythings is fine
BeteNoire: yes, it is fine
suokko: Does anyone object patches "radeon: Fix all compiler warnings." and "radeon: Add -Werror to compiler options."? http://cgit.freedesktop.org/~suokko/mesa/log/?h=small_patches
glisse: so switch to a tty where you see the bug and do as root vbetool post
glisse: and see if it helps
BeteNoire: but i see nothing when try to switch to tty
suokko: i don't know if there is more warnings in 64bit build. And -Werror could be optional somehow
suokko: But is there easy way to implement -Werror so that it is enabled only for builds from git?
glisse: BeteNoire: you will have to do it blindly or log from a remote computer
BeteNoire: oh
BeteNoire: ok, i'll try
BeteNoire: i'll run ssh
Esmil: suokko: This is the build log of your small_patches branch on my 64bit system: http://home.imf.au.dk/esmil/suokko.txt
Esmil: It fails
suokko: So there is some 64 bit problems there. I hate stdio :/
soreau: doesn't care for 64bit os'
soreau: Even if I had a 64 bit platform I'd run 32bit os on it
suokko: There is -m64 to test build :)
Esmil: soreau: Heh, I'm waiting till they stick a 64bit processor in a netbook to buy one. I know its mostly superstition but it feels nice to get rid of a lot of 386 baggage ;)
fluorine: hi
fluorine: I was wondering if someone could explain to me the reason behind the large difference in 3D performance between the R300 driver and fglrx
[Enrico]: well the first i can think is that radeon team has the gpu specs after....... years?
nanonyme: soreau: It's not like 64bitness would be bad, really. It's multilib that's an enormous pain in the arse.
[Enrico]: fluorine: making a video driver is hard and really time expensive, fglrx devs has the gpu spec as soon the hardware is ready. radeon guys can have them only when amd "donate" them, so years later
fluorine: hmm
rxt0: Does AMD released FULL docs of R500?
[Enrico]: fluorine: anyway in my expirience there is a difference in performance, but not so large, ok sensible, but not large
fluorine: [Enrico]: what about reverse engineering the fglrx binary?
glisse: fluorine: we lack hiz, memory management, good shader compiler and we are slowed down by security check
[Enrico]: rxt0: for 3d and 2d yes (at least i think), but not for powersave or hdmi
[Enrico]: fluorine: it is even more time expensive
[Enrico]: fluorine: and result are not really perfect
soreau: fluorine: We don't want fglrx code or that driver
[Enrico]: fluorine: try imaging you want to understand a car engine without opening the car!
soreau: glisse: Security check?
fluorine: glisse: yes, but can't you look at the fglrx code to see how the hardware works? or better yet, imitate what it does
fluorine: glisse: by 'code' i mean the assembly
glisse: fluorine: we know how the hw works there is pretty much nothings we can learn from fglrx
suokko: fluorine: That is not legal
[Enrico]: fluorine: if you can easly read the assembly code eheheheh, btw that is not legal in USA
glisse: beside good shader compiler
glisse: and i think it will takes more time to figure shader compiler algorithm by look at flgrx asm than trying to do one by ourself
[Enrico]: that's sure :D
[Enrico]: glisse: btw can i ask if there is some news on the llvm side?
glisse: soreau: i don't think fglrx kernel checks that what userspace sends is safe
glisse: we do
fluorine: where do I go if I want to help out?
fluorine: witht the radeon code, I mean
glisse: no one is working on llvm afaik
Zajec3: glisse: whas is "hiz"?
soreau: glisse: ah ok
suokko: Zajec3: HyberZ is the marketing name
[Enrico]: glisse: ok thanks
glisse: Zajec3: a trick to discard early as much as possible tile
glisse: iirc on r100 hyperz allowed somethings like 40% boost in perf under quake
fluorine: hmm, this is disappointing
glisse: so hyperz is likely one of the things that could allow us to close the gap with fglrx
fluorine: especially since fglrx has dropped support for mobility x300
Zajec3: sound nice, promising
suokko: fluorine: http://dri.freedesktop.org/wiki/R300ToDo
soreau: fluorine: The good news is now that amd has released ati specs, the devs can actually look under the hood and make better drivers. Since amd has relatively recently bought out ati, the development has only just begun
fluorine: how recent is 'recent'?when will the better driver be released?
glisse: fluorine: we are fixing bugs and polishing memory manager
glisse: this takes time
fluorine: so when?
glisse: once we have a solid api which match previous performance we will look into improving the driver
[Enrico]: fluorine: likley only after when gallium will be ready, so more than one year
fluorine: [sigh]
[Enrico]: s/when//
glisse: and there is no timeframe, could be tomorrow if all the monkey in the jungle decide to start coding on the driver
DanaG: grr, stupid intel wifi... AMT still breaks it.
[Enrico]: lol glisse
fluorine: this is very disappointing
fluorine: oh well
fluorine: [13:01]
soreau: fluorine: The answer is "when it's ready". If you'd like to contribute your time and code, you are now free to do so since we're working with OSS here
suokko: "fluorine: http://dri.freedesktop.org/wiki/R300ToDo"
[Enrico]: i wonder why amd released the 3d specs, but not the powersave one...... and also the hdmi
rxt0: don't remember if R500 supports HDMI..
fluorine: soreau: thanks
[Enrico]: rxt0: r600 does, and they have realeased also the r600 specs
[Enrico]: 3d specs*
rxt0: yes, I knew r600 does, but r500?
[Enrico]: powersave and hdmi must be still revesed
[Enrico]: rxt0: i have no idea for r500 sorry
fluorine: 'this page does not exist' soreau
glisse: we support hdmi
fluorine: have you even checked your link?
[Enrico]: i have only a r{2,3,6}00
glisse: we support some of the powersaving
[Enrico]: glisse: i know, but it was reversed
[Enrico]: at least if i remeber well
nanonyme: glisse: Btw, is it true that proper r600 KMS+mm requires interrupts?
[Enrico]: what i mean is. the most secrect thing in a GC is the gpu 3d specs, so why not release the powersave one (which is important, but not secret at all i think)
nanonyme: Heard such claims at one point.
[Enrico]: well anyway powersave is easier to reverse i guess
suokko: [Enrico]: Bridgman has said that powermanagement requires black magic and voodoo because of problematic hw
[Enrico]: lol
[Enrico]: suokko: yeah i've heard him too
soreau: fluorine: I did not give you that link, suokko did. But it worksforme http://dri.freedesktop.org/wiki/R300ToDo
suokko: /usr/bin/ld: i386:x86-64 architecture of input file `../common/utils.o' is incompatible with i386 output :) Nicer error for compiling with -m64
[Enrico]: o.O
glisse: also good powermanagement is really only doable with kms
[Enrico]: kms for the win!!!!
[Enrico]: well kms has a huge development these days, so it is not so far
[Enrico]: there is also the stagind driver in the .31 rcX :D
bridgman: Enrico; we wrote 3D specs first because devs were ready to use them, and because 3D needed the most development time
[Enrico]: staging*
[Enrico]: bridgman: well indeed, 3d comes first
bridgman: agd5f wrote some initial power management code for radeon, and others ported it to radeonhd
[Enrico]: bridgman: and i approve the choice
bridgman: dynamic power management isn't going to happen until after kms anyways
[Enrico]: well static is better than nothing anyway :D
[Enrico]: [and anyway my cards doesn't have powersave since it is a laptop -> no fan]
suokko: (We would need control panel for radeon to control power management in real time)
agd5f: suokko: exposing knobs via sysfs so they can be used by gpm, etc.
[Enrico]: anyway i didn't know that powersave need kms too, so this exmplain my doubt
[Enrico]: thanks to all for the teach :D
bridgman: yeah, it doesn't strictly need it, but it does need some way to combine information from modesetting, 2d accel and 3d accel
[Enrico]: bridgman: inderstood :D
bridgman: and since kms gives us that for free, doing PM after KMS seemed to make sense
[Enrico]: it makes indeed
[Enrico]: it's a waste of time do it before if you have to rewrite it for ksm
[Enrico]: kms*
nanonyme: notices no one answered his question
suokko: nanonyme: You can do busy wait in kernel too but many wouldn't like it ;)
hbbs: I've give a spin on F12 alpha and doesn't boot, I'm assuming is something related to KMS on APG GPUs?
agd5f: nanonyme: doesn't require interrupts
glisse: hbbs: did you try adding radeon.agpmode=-1 to cd boot cmd line ?
[Enrico]: hbbs: you can also try with nomodeset to disable kms
hbbs: glisse, [Enrico] : see that's the issue. It is impossible to use it that way. It keeps laggintg to redraw and to slow to video playback.
[Enrico]: no clue sorry
glisse: hbbs: but it works ?
hbbs: glisse, I will do just that.
hbbs: brb
Zajec3: bridgman: ping
Zajec3: bridgman: Christian requested HDMI docs, even under NDA as long as he can release on GPL
Zajec3: bridgman: that's because there is some magic in HDMI/sound block on newer chipsets
Zajec3: registers seem to need some special setting for audio over HDMI
Zajec3: bridgman: did you read that? can you provide him docs?
BeteNoire: glisse: my laptop hanged totally on vbetool post :||||
nanonyme: agd5f: Great. So it can be done even before IRQ docs get out. :3
glisse: BeteNoire: you are not using kms ?
glisse: and you didn't do vbetool post while X was on top ?
BeteNoire: kms?
glisse: kernel modesetting what is your kernel version ?
BeteNoire: 2.6.30
glisse: BeteNoire: so X wasn't on top when you did vbetool right ?
BeteNoire: wasnt
hbbs_: glisse, Yes, it works. I'm using the F12 Live CD x86-64 right now. But like i've told you, is too slow to move a window around, it lags.
hbbs_: it will be proper KMS support to ATI Radeon AGP hardware on the next kernel?
glisse: hbbs_: we are working on that
glisse: hbbs_: you should open a bug with lspci -vnnx output
hbbs_: glisse, thank you for you guys hard work.
hbbs_: glisse, where I should open it?
BeteNoire: ok, so i do vbetool post on my laptop connected to it via ssh risking another hangup, right?
glisse: hbbs_: bugs.freedesktop.org with radeon as module
glisse: BeteNoire: after switching away from X ?
hbbs_: glisse, ok, I'll do that.
BeteNoire: RS482M- TEST BIOS BR#13207A
BeteNoire: it is written on my screen
BeteNoire: nothing happens
BeteNoire: what now
BeteNoire: glisse: ↑
glisse: BeteNoire: so you have a working console now ?
BeteNoire: no :|
BeteNoire: that was via ssh
glisse: type enter on your keyboard
glisse: you should see the console
glisse: or switch to a different tty
glisse: not the X one
BeteNoire: cant switch to anything on laptop
BeteNoire: typed dmesg via ssh and now it hangs
BeteNoire: with a bunch of same messages: [drm] wait idle failed status : 0x80010140 0x00000000
hbbs_: glisse, should I open on Bugzlilla Mesa Drivers/DRI/Radeon?
DanaG: hmm, try sudo chvt 1, via ssh?
DanaG: or 2, or some number.
glisse: hbbs_: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
glisse: component DRM/radeon
hbbs_: glisse, ok
BeteNoire: hangs after pressing enter
BeteNoire: i can ^C
glisse: BeteNoire: well you are experiencing gpu lockup
BeteNoire: X is taking 98% of cpu
glisse: you not alone https://bugzilla.redhat.com/show_bug.cgi?id=498457
BeteNoire: oh, i think ati engineers should use that card too
BeteNoire: everyday
BeteNoire: and their children and partents
BeteNoire: but what can i do to get it working?
glisse: we will be looking at that bug at one point
BeteNoire: ?
glisse: well you can still start hacking too
glisse: but gpu lockup are hard to debug
glisse: painfull
AndrewR: suokko, ping
BeteNoire: im in big pain since xorg and fglrx and radeon and kernel are not working together well
BeteNoire: what else can cause me more pain? :)
suokko: AndrewR: pong
glisse: BeteNoire: you are using fglrx with radeon driver?
glisse: you shouldn't
BeteNoire: no, i am not
AndrewR: http://pastebin.com/m2b3b78c2 - is this normal for r200 and current mesa in dri2 mode, but with ~.31-rc6 kernel?
glisse: things to avoid: radeonfb, fglrx+radeon,
BeteNoire: glisse: i know that from my trial and error probes :)
suokko: AndrewR: yes. That is feature in rc7 kernel
AndrewR: suokko, one mment, i have rc7+ compiled but need reboot for installing it
suokko: Oops. That overflow :)
suokko: Not what Itough about .sorry
AndrewR: suokko, thanks for all your work!
suokko: AndrewR: DRI1?
hbbs_: glisse, done https://bugs.freedesktop.org/show_bug.cgi?id=23513
mikkoc: just got this: http://pastebin.ca/1542105
mikkoc: everything from master, ~10 hrs ago
mikkoc: -rc7 kernel
mikkoc: with kms
spstarr: agd5f: there is some corruption with DDX and scrolling
spstarr: Zajec3: bridgman reads backlog of channel and will reply when he is able to :)
Zajec3: spstarr: yeah, know that... his habits ;)
spstarr: airlied: the GNU libc crash should be fixed if -16 is built, drepper might have a fix i will test
spstarr: Zajec3: heh
nanonyme: "radeon: Fix all compiler warnings." slights a tad ambitious. :)
nanonyme: s/slights/sounds/
nanonyme: Brain borkage.
nanonyme: suokko: Hrm, what's the reason you can replace radeonCreateContext with r100CreateContext there. (noted there's also r200CreateContext)
nanonyme: goes to read more source
nanonyme: Ah, so that's the first one in chain, actually.
nanonyme: Nevermind.
nanonyme: Nice. :3
nanonyme: const struct __DriverAPIRec driDriverAPI does look slightly hacky to me though. :P
suokko: nanonyme: yes
suokko: It would be better if it was nonconst and we could modify if we need different function. Like for kms and non-kms
nanonyme: But yeah, even though the commit revealed things about the drivers I don't necessarily like that much, good job. ;)
kdekorte: Any progress being made on the texture corruptions that appear in directmode, but don't in indirect mode on r6xx .. ie menus in quake3?
agd5f: kdekorte: I think it's related to bug 23469
kdekorte: agd5f, you think that will also fix the info display in engine as well?
agd5f: kdekorte: could be
kdekorte: agd5f, so is that a big effort to fix? For example to use option 1 where you just recompile when the format changes can you put that call in and test it?
agd5f: kdekorte: the fetch shader part is
agd5f: recompiling the shader isn't too hard
kdekorte: agd5f, would it be worth making that patch and seeing what issues that fixes?
agd5f: kdekorte: sure
kdekorte: agd5f, what variable keeps track of the vertex format? Or should I even bother looking into this, cause I think this is over my head.
agd5f: kdekorte: something like this might work: http://www.botchco.com/alex/xorg/r600_recompile_vs.diff
kdekorte: agd5f, ok I'll play with that
suokko: agd5f: Which would be better: Having one large shader to all fetching or many small that all are loaded to vram and you just pick the right one?
suokko: didn't read the docs about fetch shader yet
agd5f: kdekorte: the vtx format is in vb->AttribPtr
agd5f: see r700SetupStreams
agd5f: suokko: could take several approaches
agd5f: the hw has a sperate fetch shader that decouples vertex fetch from the actual vertex shader
agd5f: so ideally, we'd compile the vertex shader once, and then build fetch shaders to deal with the variable vertex formats
suokko: So we would have problem is user shader handles variable vertex formats
kdekorte: ok, I got that patch working, but in r700SetupVertexProgram if the vp->loaded line 344 is comment out it end up locking the program...
kdekorte: I need a way to unload the shader I think
agd5f: suokko: you could make one big shader, but then you'd have to add flow control to select which fetch clause you wanted to select
kdekorte: I think I am running out of memory or something
agd5f: kdekorte: yeah, you need to release the shader bo. it should be happening when we unref the bo in r700runrender
kdekorte: yeah that line is gone now...
kdekorte: anyway, I have to go... I emailed you what I had
kdekorte: agd5f, ahh I had missed that in the patch
kdekorte: ok it works now... but doesn't fix the info display
kdekorte: and the quake3 textures are still borked...
kdekorte: so it fixes some things, but not all
agd5f: kdekorte: probably need to double check that the fetch clauses are getting setup right
kdekorte: anyway... got to go... be back later
Zajec3: could someone sum up http://www.botchco.com/alex/xorg/r600_recompile_vs.diff ?
Zajec3: this forces recompilation, right?
Zajec3: first solution
Zajec3: does it work?
nanonyme: Zajec3: Try out?
Zajec3: nanonyme: there was some discussion about locks up
Zajec3: wanted to know if I should change sth more, more than this patch
Zajec3: don't like reinveting wheel ;)
nanonyme: 00:02 < kdekorte> agd5f, ahh I had missed that in the patch
nanonyme: Sounds to me like a human error.
nanonyme: (which is why it's nicer to just give that kind of stuff for patch to do)
nanonyme: Recompiling myself and seeing soon how it works.
nanonyme: As expected, a significant decrease in performance... Then to see what it fixes. :)
nanonyme: Hmm, corruption still in OpenArena including which I got a segmentation fault when it closed.
nanonyme: Actually tons of other stuff too including double frees + corruption messages.
Zajec3: :(
Zajec3: sry, i'm just too busy to test now
Zajec3: including potential lock up
nanonyme: It didn't lockup for me.
nanonyme: But it didn't help with corruption either.
nanonyme: And made libc spit out various errors.
W0rmDr1nk: hi
W0rmDr1nk: I am still getting mouse pointer corruption on x11-drivers/xf86-video-ati-6.12.2-r1
agd5f: W0rmDr1nk: do you know what commit that corresponds to?
W0rmDr1nk: no - sorry i might be unclear
W0rmDr1nk: have gotten mouse pointer corruption since i started using it with dual screens
W0rmDr1nk: so its not regression
W0rmDr1nk: see its better than it was in x11-drivers/xf86-video-ati-6.12.1-r1
W0rmDr1nk: allot better
W0rmDr1nk: but now there is like special case corruption - which also happened in prev version (dunno what causes it)
agd5f: W0rmDr1nk: does Option "EXANoDownloadFromScreen" in the device section of your config fix it?
W0rmDr1nk: basically i see one corner of arror part of mouse pointer in a verical row - about 3x the height of a mouse pointer
W0rmDr1nk: did not try
W0rmDr1nk: will give it a try
W0rmDr1nk: other thing is - shortly after this special case corruption my system hangs
W0rmDr1nk: and I cant really figure out which part
W0rmDr1nk: Xorg log doesnt seem to have any crash info - and dmesg neither
agd5f: W0rmDr1nk: still sounds like you may need a newer version of the driver
W0rmDr1nk: I can go to 6.12-branch i think
W0rmDr1nk: or the branch - let me check something
agd5f: W0rmDr1nk: you should try git master or the stable 6.12-branch
agd5f: I'm not sure what x11-drivers/xf86-video-ati-6.12.2-r1 corresponds to
MostAwesomeDude: 6.12.2 + gentoo patches. I could go look it up.
MostAwesomeDude: Patches are in http://dev.gentooexperimental.org/~scarabeus/xf86-video-ati-6.12.2-patches-02.tar.bz2, haven't actually seen them yet.
W0rmDr1nk: but does it sound like a problem that should be fixed ?
W0rmDr1nk: in later versions ?
W0rmDr1nk: or does it sound like it might be just like something different completely
MostAwesomeDude: agd5f: Looks like 43 cherry-picks from master.
W0rmDr1nk: cos the change from 12.1 to 12.2 was improvement
agd5f: W0rmDr1nk: there have been a lot of important bug fixes since 6.12.2 was released. that's why we have the stable branch
W0rmDr1nk: I see
agd5f: not all distros keep up to date with it though
W0rmDr1nk: ok - will try branch tomorrow
W0rmDr1nk: if doesnt work will go to master
nanonyme: is starting to develop a feud against indirect rendering
W0rmDr1nk: is EXANoDownloadFromScreen same as AccelDFS option ?
W0rmDr1nk: cos I dont see EXANoDownloadFromScreen in man
chithead: W0rmDr1nk: you are looking at the wrong manpange, "man exa"
chithead: manpage*
MostAwesomeDude: EXANoDownloadFromScreen is an exa option, AccelDFS is a radeon option.
nanonyme: That explains quite a bit...
W0rmDr1nk: awe chithead is rihgt
nanonyme: Hmm, no X with r600 KMS yet, seems.
nanonyme: (at least here)
nanonyme: Then again, I might not have all the newest commits...
nanonyme: airlied: Is there some tree with all the newest r600 KMS parts atm?
airlied: nanonyme: no
nanonyme: airlied: Do you intend to push them first upstream or to Rawhide? :)
airlied: nanonyme: rawhide has it alread
nanonyme: Oh, right.
nanonyme: Guess it's not enough for my chip then.
nanonyme: airlied: Did it require some ddx changes or other such changes?
nanonyme: I may have diverted a bit from generic Rawhide here, wondering if it affects the results...
airlied: no DDX is whats in master
airlied: we don't have accel yet
nanonyme: I don't mean accel, it's just that X lockups for me on start.
airlied: ah someone else reported that
nanonyme: Expecting that when the mm is in good enough a shape for accel, I'll get to know somewhere. :3 Just puzzled since you said you could start X but I haven't yet been able to do it once.
nanonyme: (of course could be a hardware difference but I'd first assume software ones)
airlied: what hw you got?
nanonyme: rv670
nanonyme: Plymouth boot and fbcon work fine, X just locks up.
agd5f: airlied: master doesn't work for me in shadowfb mode either on r6xx. I get a missing symbol error exaLookupPixmapPrivate
agd5f: with kms
agd5f: works if i force exa and disable all the accel hooks
airlied: oh I wonder what we broke there
nanonyme: *yawn*
metala: *yawn_too*
spstarr: airlied: is Xorg rebuilt against mesa for today?
airlied: spstarr: we don't build server against mesa
spstarr: well the DRI interface broke
spstarr: (
spstarr: EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/libdricore.so: undefined symbol: _glapi_SingleThreaded)
spstarr: (EE) AIGLX: reverting to software rendering
airlied: spstarr: you are behind the time
airlied: not sure why you don't pull first and ask qs later
spstarr: a day is a lifetime in radeon it seems :)
spstarr: pulls
nanonyme: spstarr: Just bad timing, sounds like.
nanonyme: The commit wasn't there *that* long.
nanonyme: (but yeah, "git pull && make clean && make" is a good routine; should probably alias it :3)
suokko: airlied: Is it possible that one application would have multiple cs where it writes relocation for same bo to more than one cs same time? (I'm just thinking to optimize write_reloc because it shows as 2nd highest cpu user after _tnl_draw_prims)
suokko: It would be very fast if bo hand direct pointer relocation. But if there is possibility for multiple cs in one application that shares bos then I would need linked list (or search tree or hash table if someone wants to make it scale well)
spstarr: nanonyme: a little more complicated, i repackage git masters of them in RPM
spstarr: i just chuck out the Fedora tarball and patches where applicable
suokko: I guess KISS should work until someone hits the problem with multiple cs
airlied: we only have one CS at a time
W0rmDr1nk: hi
W0rmDr1nk: what is kernel mode setting ?
bridgman: w0rmdr1nk; moving modesetting from the X driver into the drm (aka kernel driver)
suokko: airlied: http://cgit.freedesktop.org/~suokko/drm/commit/?id=8f1d7f1aa82bc227bd36e959bb5415fa6afc862d
bridgman: adding an API from X driver to drm so X driver can pass mode change requests down to the kernel
bridgman: KMS builds on a kernel memory manager which lets drm, X driver and 3D (mesa) driver all share memory buffers
bridgman: the first shared memory buffer being the frame buffer ie what you see on the screen
airlied: suokko: ah yes that is something we tried to avoid before
airlied: suokko: due to threads I think
bridgman: I'm talking to myself again, right ?
yangman: bridgman: yup
suokko: airlied: What about them?
edt: boy the 3D experimental for R600/R700 really _is_ experimental
airlied: suokko: I think in the future we may have to have multiple cs
suokko: airlied: That what I was thinking :)
airlied: if you have multiple contexts with shared bos it could happen
suokko: But loop is way too slow
suokko: yes. But We need O(1) solution there. There is huge amount of relocations in a cs
airlied: how much speed increase you get with that?
suokko: 4% for xmoto
suokko: I haven't benchmarked anything more complex. Maybe I sohuld test nexuiz or sauerbraten
nanonyme: edt: What did you expect? :D
suokko: For multiple cs situation naive linked list in bo would give O(1) to number of relocations
nanonyme: It's not like developers are hiding perfectly working drivers behind their backs. ;)
suokko: airlied: How space check will work with multiple cs? Can they share that single space check value?
airlied: suokko: yeah I was thinking about that
airlied: it might be nice if we could make a test case that makes it happen so we can play with it ;-)
suokko: One option would be giving thread local data for bo
suokko: airlied: there is mesa demo for that
suokko: It crashes legacy bo handling in exit ;)
airlied: the whole cairo-dock issue makes it messier as well
airlied: shared contexts suck
suokko: Only problem in thread local data for bos is that creating keys in glibc is also naive and O(n) time so not nice for large number of bos
suokko: (I did look the source today)
MostAwesomeDude: airlied: Can't we get a reckoning on whether the crap cairo-dock pulls is okay?
airlied: its okay
airlied: I talked to aaronp about it
MostAwesomeDude: Ah, alright.
airlied: its not pretty but it it should work
MostAwesomeDude: So then do we need to be more aggresive in flinking BOs?
MostAwesomeDude: Or did you figure something else out?
airlied: I think we could share stuff at a different level
airlied: so we don't get two DRI2 connectiosn
suokko: airlied: One option would be using hash table for relocations
suokko: *thinks about std::unordered_map*
MostAwesomeDude: suokko: No. Bad. Stop thinking about STL.
edt: nanonyme I was hoping googleearth would work - here is hangs X. About the only 3D that works is glxgears. Anything else either fails to start or crashes X shortly after starting.
edt: s/here is hangs/here it hangs/
airlied: thats what experimental pretty much means
nanonyme: Hanging X probably isn't expected if you aren't running OpenGL compositing though.
nanonyme: With the current state of the driver running indirect OpenGL is pretty much asking for your X server to crash.
airlied: thats what experimental pretty much means
nanonyme: Yups.
edt: it last about 10 mins using kde 4.2's opengl support
nanonyme: Just yank all compositing off if you want to try the driver.
edt: thats what I have done for now (xrender gives me some function via exa)
suokko: and kde 4.2 has its own problems
edt: suokko as does almost all software...
edt: glxgears does work - about 400 f/s with todays drm & mesa trees
edt: hw is amd 790gx chipset with RS780D detected.
bridgman: that sounds low; what is your engine clock ?
bridgman: not really low but a bit low
edt: bridgman it is low vs ati's drivers which got 1400 - with an experimental driver I do not expect near the 1400...
edt: (II) RADEON(0): Default Engine Clock: 500000
bridgman: I'm getting over 900 with an rv620 which has similar hardware; there's a performance hit from going through the hypertransport bus rather than having local memory but didn't think it was that high
bridgman: 400 sounds like software rendering
edt: software is much slower. Glxinfo and the X log both say its using some acceleration
bridgman: ok; you might have a VBIOS that sets low engine clocks by default as well; I think you can look in your xorg log and see what engine and memory clocks are being used
nanonyme: edt: And glxinfo|grep renderer mentions R600 as expected then?
edt: (II) RADEON(0): crtc(0) Clock: mode 154000, PLL 153990 ? Other wise the only Engine/Memory are like the above 500000/400000 respectivily
edt: Nanonyme - it reports: OpenGL renderer string: Mesa DRI R600 (RS780 9614) 20090101 TCL
nanonyme: Yups, fine then.
edt: but also gives: esa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
nanonyme: edt: Are you using powersaving, btw?
edt: no
edt: to be more specific, power saving is disabled in the kernel, I am using screen blanking after about 20 mins
nanonyme: I meant in xorg.conf.
suokko: airlied: I think I have 3 solutions to relocations problems. One is to use hash table for look up in cs. Second is linked list in bo to simulate thread local variables. Third is using thread local data in bos. (Maybe somehow trigged so that we need only one key for all bos)
nanonyme: But yeah, apparently not.
edt: not via xorg.conf
suokko: Hash table sounds too much implementation for gains if there is no generic implementation which can be reused
nanonyme: Texture compression isn't really important. Iirc patent-encumbered and you have to install it yourself.
edt: nice to know what a message mean though
DanaG: read that "Iirc" as lowercase "LIRC".
airlied: suokko: like xf86drmHash.c?
airlied: though not sure how generic that is
suokko: airlied: Sounds like something that should be looked at
nanonyme: Patent/something else that makes it undesirable to distribute with Mesa.
nanonyme: Don't remember the background exactly.
suokko: But I still don't know if hash table beats thread local variables in bo
suokko: hmm. thread local variables have one problem if applications uses multiple threads for same context :(
airlied: thats generally illegal
suokko: So it should in fact be context local variables for bos
suokko: airlied: I think it is allowed in opengl specification if client serialized operations
edt: nanonyme looking at the xorg log It would seem that the driver does not use the 128m of ddr3 cache that the chipset has (unless the bios does this transparently)
airlied: yeah I think thast the case alright
nanonyme: edt: Something about PCI BAR size there?
bridgman: edt; I think I was confusing with performance numbers before agd5f accelerated the back-to-front buffer copy; that's when the IGPs were keeping up with discrete vram
nanonyme: edt: Or what did you mean? Does it use only part of the memory available or what?
edt: (II) RADEON(0): Detected total video RAM=393216K, accessible=262144K (PCI BAR=262144K)
nanonyme: Hmm, right.
nanonyme: So yeah, the inaccessible part requires memory manager to be used.
bridgman: not sure if that includes sideport memory or not; the open drivers aren't using sideport memory yet
bridgman: agd5f is trying to figure it out in his spare time, but of course he doesn't have any
nanonyme: bridgman: How well documented is that?
nanonyme: edt: As of now the driver can use at most the amount of memory denoted by PCI BAR.
nanonyme: s/now/yet/
nanonyme: Gah, should jump into bed already.
bridgman: a good rule of thumb is "if it was well documented we would have released it already" ;)
nanonyme: :P
edt: gathered that - and bed would be a good idea here too (we just completed a SAP upgrade at work and support is 'fun' right now - I do need my sleep)
edt: later
bridgman: bye
nanonyme: Cya.
edt: nite nite
agd5f: edt: you are likely already using the sideport memory. I think the default is generally to interleave it with UMA memory
JohnDoe: morning
soreau: night