Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-28

Search This Log:

Telek1: Question: Why does anisotropic filtering on the R700 currently make it MORE pixelated?
soreau: because aa is not supported yet?
Telek1: Can you expand on that?
MostAwesomeDude: It's probably not set up right.
MostAwesomeDude: AA's not needed for anisotropy.
soreau: I read that as anti-aliasing.
soreau: tries to rest
Telek1: nods, "Well anything above value 1 in driconf causes it to pixelate, it appears the same amount from 2-16, and otherwise doesn't seem to affect anything"
MostAwesomeDude: There used to be a good anisotropy demo in Mesa, dunno where it went.
Telek1: Well, at least the check pattern is gone when exiting from GL mode now :)
Telek1: nods.
eosie: MostAwesomeDude: is arlied in this channel at weekends?
MostAwesomeDude: eosie: Sometimes.
ZeZu: can anyone tell me where some of the register offset come from in ati docs ? IE: hidec:0x00...
ZeZu: the index'd ones make sense, but not all of them have index/data regs, nor doesn't it specify the offset or address of some
ZeZu: Even if lspci listed two memory regions, it doesn't make sense if there are 8 reg. regions, the m76 doc is a lot easier to follow but i'm working with a pre-R600 embedded chipset
eosie: MostAwesomeDude: you might review the patches I've sent to the ML today, but as you said a few days ago, arlied should probably look at them too
MostAwesomeDude: eosie: If they work on r500, they'll probably work on r300 too, but I'd really like airlied's input, or at least his "shouldn't break anything."
eosie: openarena just works on r300g, some levels of xmoto too (some others dump CS), the only thing that hardlocks now is glean/glsl1, which seems to be purely related to shaders (also I got a hardlock while playing with fragment shaders by simply changing an expression in GLSL)
soreau: OA and neverball work with r300g here on my rv350, Enemy Territory does not work per se but at least it doesnt crash (unplayable faulty graphics)
MostAwesomeDude: Wow.
soreau: MostAwesomeDude: The splash screen to OA does only greyscreen and some things in the neverball menu do not display but both are playable with performance hit
Telek1: Yeah, R300 support has always been quirky. :( I was actually getting ready to play around with it a day or two ago, but I either blew up my 9800, or overcapacitied my power supply.
eosie: soreau: that seems to be related to gen-mipmaps, I don't know of any other case which gives faulty graphics
soreau: This is only possible with setting LIBGL_DRIVERS_DIR globally, does not work on a per-app basis
soreau: m64+ (N64 emu) works too, just slow as heck
soreau: These are really the few apps Ive tested though
Nightwulf: hi all
Telek1: Hello!
eosie: soreau: you can test the patch series I sent to the mailing list today and report if it helps, if you like... some unfriendly shaders should work now
soreau: eosie: I would but I am not at my ati box atm
bttb: Hi all
soreau: eosie: Curious, what do you mean by unfriendly shaders?
Telek1: Shaders that are out to kill you....r system :)
soreau: Meaning some not so friendly shaders may be better now?
eosie: yes
soreau: Telek1: I dont experience any crashes here unless I commit to raping my box :P
soreau: eosie: I may take a look tomorrow
Telek1: soreau: Lucky you :) When my system's not actually crashing, it's breaking in annoying and reboot requiring fashions :)
soreau: Telek1: You must have one of those new age chips ;)
Telek1: Sadly with linux and open source drivers, it seems like anything newer than 2002 is a 'new age' chip :D
eosie: e.g. if VS writes to TEX1, TEX2, TEX3, and FS reads TEX1 and TEX3
lowkyalur: hi all. does anybody know how to fix a "r300VertexProgUpdateParams:Params exhausted" error?
soreau: I think I got this rv350 in 03ish and has served me well throughout the years
soreau: lordheavy: Which chip, kernel and version of mesa?
Telek1: soreau: 9xxx cards were pretty good for quite a few years, I skipped three generations thanks to them, and only ended up with the R600 because 128 megs of vram just wasn't enough :)
soreau: Telek1: I have 9600 256MB
Telek1: Pair of 9800 pros, original, and an AIW :)
Telek1: The AIW is the one I think just fried :( Powered up, posted, made a couple weird chars at the bottom of the screen, then refused to post when I rebooted :(
soreau: MostAwesomeDude: Im surprised at your being surprised ;)
soreau: I figured yuod at least test at one point or another
MostAwesomeDude: soreau: Nope.
Telek1: Hey what's going on with the mach64 drivers, did they ever get fixed?
soreau: MostAwesomeDude: The strange thing is, compiz with per-app basis shows fine until cube or wall (works but with gradient colors) but r300g globally compiz is dark silhouette windows but cube works ok
soreau: s/wall/expo
soreau: cube+expo is both gradient colors or works with global setting
osiris: glisse: ping
osiris: or airlied
eosie: soreau: could you post a screenshot?
spreeuw: cool
spreeuw: OpenGL renderer string: Mesa DRI R600 (RV730 9490) 20090101 x86/MMX+/3DNow!+/SSE2 TCL DRI2
spreeuw: OpenGL version string: 2.0 Mesa 7.8-devel
spreeuw: 1GB vidmem passive cooling
spreeuw: 2349 frames in 5.0 seconds = 469.764 FPS
spreeuw: looks like twice as fast as the 3450
spreeuw: wow impressive
spreeuw: HD ut2004 runs like a charm
ossman: spreeuw, what branches are you running to get GL 2.0 on a r600? :)
ossman: I thought GLSL wasn't done yet
spreeuw: ossman: head with an uncommented define
spreeuw: just for testing
spreeuw: when I enabled glsl in nexuiz just now it crashed the card
ossman: Not quite ready then :)
spreeuw: http://phoronix.com/forums/showpost.php?p=101481&postcount=7
spreeuw: nexuiz is a bitch on the system anyway
spreeuw: will try some simpler games like dangerdeep now
spreeuw: Caught exception: compiling of shader failed : /usr/local/share/dangerdeep/shaders/water.vshader
spreeuw: Stack trace: (5 frames)
spreeuw: nevermind ;p
spreeuw: if you disable the shaders in the game it should work like a non 2.0 build I guess
spreeuw: hmm doesnt render water at all
hifi: still waiting for my HD 4650
spreeuw: the only stuff lacking at the moment is s3tc
spreeuw: after that its as good as older radeons for me
spreeuw: only multiple times faster ;p
eosie: spreeuw: do you have libtxc_dxtn?
spreeuw: eosie: yep
spreeuw: it just broken on r600
spreeuw: its reported by everybody
spreeuw: it works on r300
eosie: maybe it's not implemented yet
adamk: spreeuw, It does not work properly on r300.
spreeuw: nowadays you mean?
spreeuw: in any case it was less problematic
spreeuw: and slews of games didnt have the s3tc init problems
adamk: spreeuw, It never worked on r300 for games such as ut2004, doom3, etc. As far as I know, it never worked on r300 for any game that used multitexturing.
adamk: Neverwinter Nights was the only game I ever saw libtxc_dxtn work with properly.
spreeuw: I have had a working vegastrike
spreeuw: which can not run without
spreeuw: its an open sores game
osiris: airlied: I think we should add and an implicit flush to radeon_bo_map if given bo is referenced by cs in write domain and we are mapping for reading, or bo is referenced in read domain, and we're mapping for writing
osiris: airlied: that would eliminate all the radeon_bo_is_referenced_by_cs and radeon_firevertices calls all around the code
Ronis_BR: hi all
Ronis_BR: is there a way to KMS and UVESAFB to coexist?
Ronis_BR: I mean, to change what I'm using at the boot time?
BioTube: no
BioTube: KMS uses fbcon
Ronis_BR: So I can choose to boot with KMS or with uvesafb?
BioTube: correct
Zajec: at boottime should be possible
Zajec: by just blacklisting one of two
Ronis_BR: Zajec: uvesafb is built-in
Zajec: after booting switching is impossible i think
Zajec: ah
Ronis_BR: Zajec: I have no ideas how to disable it
BioTube: don't use a vga= parameter
Ronis_BR: BioTube: it doesn't use vga=
Ronis_BR: BioTube: it use video=uvesafb:
Ronis_BR: but It isn't working
Ronis_BR: when I enable KMS things becomes wierd :)
Zajec: Ronis_BR: so... what you actually want?
Zajec: Ronis_BR: disable KMS?
Ronis_BR: If I doesn't enable KMS by default, how can I enable it after?
Zajec: radeon.modeset=0
Ronis_BR: Zajec: the problem is if I enable KMS by default, than uvesafb doesn't work
Zajec: Ronis_BR: if you boot without loadin radeon, without using vesafb, you can modprobe radeon modeset=11
Ronis_BR: Zajec: so I haven't enable it, but how can I enable now?
Zajec: *1
Ronis_BR: I'll trt
BioTube: Ronis_BR: you need to load fbcon to get a terminal with KMS
Ronis_BR: BioTube: I know
Zajec: BioTube: i think fbcon is in-kernel and it loads with radeon
Ronis_BR: Zajec: if I pass modeset=1 to boot time does it work?
BioTube: Zajec: it can be built as a module
Ronis_BR: well I'll try
Zajec: BioTube: didn't even know
Zajec: BioTube: ah, yes, i recall sth
Zajec: BioTube: anyway someone suggested me here to built it in, so I always did
Zajec: not sure, maybe doesn't matter
BioTube: radeon needs it to work right but doesn't load it, so that's probably why
Ghworg: Running the piglit quick test suite locked up my machine, mouse would still move and magic sysrq worked, but nothing else would
Ghworg: Is this a known problem on r600 kms?
zhick: i'm feeling a little adventurous today so i decided ill give the r300g stuff a try :> do i need a special kernel-module or will a regular 2.6.32 kernel do the job?
BioTube: gallium just need KMS
zhick: ok
zhick: any other stuff i need to pull from branches? mesa, ddx?
adamk: I would use mesa from git. Any DDX recent enough to support KMS should work, I believe.l
zhick: nice, thanks. :)
adamk: And there are no special branches for r300g... It does take some special flags to ./configure in Mesa though.
ossman: MrCooper, I'm looking at drm_vblank_post_modeset() and I'm afraid I don't see it doing what you claim
ossman: it's basically only fiddling with some state variables
ossman: I see nothing touching the vblank counter, much less compensating for it going backwards
ossman: I take it there is something more involved here than those two functions?
MrCooper: ossman: actually you're right, there used to be more complicated logic but now the idea is mostly to enable the vblank interrupts and keep the userspace counter up to date like that; the rest of the logic is spread across various functions, see e.g. dev->last_vblank[] usage
ossman: MrCooper, I'm going through that entire file, and to be honest I'm having trouble understanding why those pre/post functions are needed
ossman: any application waiting on vblanks will have increased the reference count, prevent ints to be turned off
MrCooper: it's certainly complex, I suppose you can't just believe me that they are? :}
ossman: MrCooper, I'm feeling I need to understand this to provide a proper solution for my problem :)
ossman: the counter is incremented a step at a time, not by reading the hw counter
ossman: so why do we even care what the hw counter is?
ossman: whenever it's allowed to drift away is either when no vblank events occur, or when noone is interested in vblanks
MrCooper: hmm good points actually
ossman: MrCooper, do you have a test case that breaks with improper vblank handling?
MrCooper: there could still be problems if e.g. someone were to observe the counters between large intervals
ossman: I'm thinking we can just rip out the hw counter stuff. But a test case would be prudent
MrCooper: ossman: this was all discussed to death on the dri-devel list...
ossman: but there is no guarantee that the vblank counter is stable enough to be used as a clock source
ossman: turning off the monitor via DPMS will stop the "clock", making it drift away from wall clock anyway
ossman: MrCooper, got a reference?
eosie: osiris: I absolutely agree with your idea about implicit flushing in radeon_bo_map if a buffer is referenced by CS, I've come across the same issue in gallium
MrCooper: it doesn't need to be a clock source, just to reflect the number of frames generated by the CRTC
MrCooper: ossman: not offhand, shouldn't be hard to find though
ossman: MrCooper, I'm not sure I see the use case for keeping track of the CRTC's frame count. Not considering the complexity required to maintain it...
ossman: goes searching for that thread
ossman: anyone here familiar with the RMX?
spreeuw: [__main__] <72367> Too many texture samplers (8, max is 8)
spreeuw: what could this mean?
spreeuw: seems the driver tells the game this
spreeuw: that it has 8
ossman: spreeuw, the game tries to feed the driver more a more complex program than it can handle
eosie: interesting, wine emulates fragment.position for us
MostAwesomeDude: Yep, it should always be pre-calculated for us.
eosie: I was thinking about an implementation of this feature and the most feasible solution appears to be adding some new code when it's in TGSI IR, not RC IR, so that Draw can support it too
tball: Hello
tball: How stable is powermanagement for kms?
tball: anyone tried it?
Zajec: tball: wait for IRQs
Zajec: tball: then I'll able to release sth usable
tball: Zajec, Doesn't it work at all?
tball: Zajec, I really really want to use the oss drivers instead of fglrx. I just need powermanagement. It is ok if its alittle buggy
Zajec: tball: it downclocks your engine by 50% which can be wrong (too much in some cases == corruptions or even lock up) and it produces black line for a one frame sometimes due to lacking IRQ
Zajec: i try to get too many things done before .33, start being tired :)
tball: Zajec, You are doing a good job, and everyone a favor
tball: Thank you for that
tball: I think a lot will use the oss drivers, when the powermanagement is done. Thats the most important right now
tball: Zajec, Anything I can test / do?
Zajec: tball: not now really
Zajec: tball: come back after IRQ release :)
Zajec: i should have something then :)
Zajec: and I try hard... but still am newbie in that whole kernel world :)
gabrimonfa: Hi all. I have a problem with dual head. The two displays start in cloning mode at each reboot. I've to use randr to have the desktop extends on both
Zajec: gabrimonfa: gentoo randr howto describes trick for that with xorg.conf and monitors
Zajec: but I couldn't make it work
Zajec: not sure if that works
gabrimonfa: My xorg is very simple. Just specify Virtual size and which display should be "LeftOf" the other. Moreover all works with radeonhd (I'm using a RV600)
Zajec: it's not gentoo, it's http://www.thinkwiki.org/wiki/Xorg_RandR_1.2 - sorry
TCW_: how likely is it that older radeon drivers cause wine'ed games not to run / run with errors?
TCW_: older == 6.12.3 in this (my) case
TCW_: oh, and x1600 card, rv520 chip
gabrimonfa: The fact is that with radeonhd all works, also with different version of xserver-xorg. And that issuing randr command all works also with radeon. I'm wondering if there is something radeon-specific to not have to issue randr command at each login
tlp: a lot of Wine games don't work even with the latest drivers because they don't yet support GLSL
TCW_: tlp, GLSL?
tlp: GL Shader Language, I think. That support will come after Gallium matures, as I understand it.
tlp: http://www.x.org/wiki/RadeonProgram
tlp: check out that page
tball: Zajec, Do you have an idea when irq support is released?
tlp: Wine stuff is at the bottom
TCW_: tlp, oh thanks... that page is useful :)
tlp: yep
tlp: Some stuff does run in Wine, but usually the older games.
tlp: MDK2 runs flawlessly because it's OpenGL 1.x
tball: Well you can activate opengl 2.0 in the driver
tball: At least with r600+
tlp: hm
tball: Just fetch mesa git, and uncomment #define GLSL_TEST in r600_context.c.
Ivanovic: hiho
tlp: cool, I didn't know that.
tlp: Is that with traditional Mesa?
Ivanovic: i got some problems getting git master to build using a live ebuild on gentoo due to some "bad programming stuff"
Ivanovic: * Function `drmGetDeviceNameFromFd' implicitly converted to pointer at radeon_dri2.c:339
tball: tlp, yes it is
tball: Actually it almost runs Heroes of Newerth
Ivanovic: complete log output: http://pastebin.com/m57c6d7f3
jcristau: Ivanovic: you need newer libdrm
Ivanovic: jcristau: you mean newer than libdrm git master?
tlp: tball: cool. Have you tried anything else?
TCW_: damn it, so still nvidia is the only way to go if one wants / needs full gfx support in GNU/Linux :/
Ivanovic: jcristau: i am running kernel 2.6.32-rc7, libdrm git master, mesa git master plus (older verison now since latest does not compile) xf86-video-ati git master
tlp: TCW_: Well, there are the proprietary drivers. Have you tried those?
tball: tlp, No actually I just read a thread about it. I haven't tried because of the lacking powermanagement support
tlp: This channel is just for the free software drivers
TCW_: tlp, _plese_! Don't mention the fglrx-crap! :)
tlp: tball: do you have a link to that thread?
tball: tlp, http://www.phoronix.com/forums/showthread.php?t=20432
tball: tlp, see the last pages
tball: TCW_, fglrx runs just fine on my computer
tball: TCW_, I rather want radeon oss drivers, but fglrx is ok until powermanagement arrives
Zajec: tball: it's written and IP-reviewed, just some last checks, doubts
jcristau: Ivanovic: hrm. radeon_dri2.c doesn't include whatever header defines drmGetDeviceNameFromFd?
Zajec: tball: as main IP-review is done, should be really fast
jcristau: s/defines/declares/
Zajec: but of course noone will give you days :)
Zajec: tball: *personally* i hope we will see that in next week... maybe two
Zajec: it's just me, don't refer to that as something sure
tball: Zajec, Sure thx for info
TCW_: tlp, I prefer ati chips as eventually a perfect and free driver will evolve there... but yet not there. I had hope 2009 would be the year with _full_ support for at least r5xx chips...
tball: But will the code be out, right after the release of the IP's?
tlp: TCW_: Me too. I'm using an nVidia card until that happens though. My motherboard has an r600 card built into it, and I've got a machine at work with an r500 card, so I track the progress of the free drivers pretty closely.
Zajec: tball: err? ... when they finally decide it's OK and safe to release it, Alex will get signal and will release it :)
tball: Zajec, Maybe I didn't understand you. The IP-review, isn't that the docs for IRQ?
TCW_: tball, ymmv... and that is all about fglrx to say. For some it runs ok, for some it is just crap. Some combinations (xorg, kernel, driver, ...) work flawlessly, some just don't. It is kinda gambling if fglrx does work the way you want it too.
Zajec: tball: not docs
Zajec: tball: it's reviewing written code
tball: Zajec, ahh ok :) Sweet
Zajec: legality, safety, parents...
tball: patents? :P
tball: I hope
Zajec: *patents
tlp: wow, cool.
Zajec: :)
tball: :P
tball: I don't hope the devs have to ask their parent for permission to release the code
tlp: Linux graphics are finally getting out of the dark ages. :p
Ivanovic: jcristau: uhm, where is it meant to be declared, do you know this?
tball: parents*
Zajec: tball: :D
Ivanovic: a grep in the plain folder does not help
Ivanovic: (just finds this single occurence of the line)
TCW_: tlp, the thing is... I can feel the radeon foss drivers are _almost_ there. I bet the day I put a nvidia card in my main workstattion is the day the foss drivers for ati chips _work_! One reason for this is just... bad luck, the other one laziness ;) it can take months before I swap cards :D
jcristau: Ivanovic: xf86drm.h, from libdrm
tlp: hehe, they already work quite well for most things :p
Ivanovic: jcristau: uhm, you mean the declaration wich is inside such a block? #define DRM_EVENT_CONTEXT_VERSION 1 (...) #endif ?
tlp: oh, I forgot you mentioned you have an r5xx chip. I guess that completely rules out fglrx for you.
jcristau: Ivanovic: #endif comes after #ifndef _XF86DRM_H_
TCW_: tlp, yep, but that is just another reason why I will never try fglrx again.
jcristau: Ivanovic: #define is not a conditional
Ivanovic: ah, right, sorry, am too sleepy already
jcristau: Ivanovic: but yeah, that declaration.
Ivanovic: ;)
Ivanovic: hmm, got 3 inclusions of that very file inside the git checkout that i got
Ivanovic: argh, okay, this is a strange one
Ivanovic: you are right that the libdrm version was too old, somehow this head was not updated correctly when i rebuilt the package
Ivanovic: after an emerge -C libdrm && emerge -1 libdrm the other package does build as expected
wirry: what was the command to boot without kms?
jcristau: nomodeset on the command line
tlp: tball: I don't have a very solid technical understanding of all this stuff, but do you know why Gallium is said to be a prerequisite for GLSL if traditional Mesa has GLSL support?
adamk: To my knowledge, no one has said that gallium is a prerequisite for GLSL :-)
adamk: Just that it makes implementing support for shaders easier :-)
Ghworg: tlp: Because the devs don't want to write GLSL support twice. Might as well just as write it for gallium now since that is the future
tlp: ah
MostAwesomeDude: You can have it both ways, you know.
wirry: hmm i was looking for "radeon.modeset=0" but it doesnt work :/
Ivanovic: wirry: have you compiled the module into your kernel?
Ivanovic: if drm is not compiled in the kernel, this one will obviously not work
Ivanovic: ;)
wirry: it should be inside the kernel..im trying to check
wirry: the last update killed my X
ossman: MostAwesomeDude, are you and Richard working on the same compiler, or do we already have two r600 GLSL compilers? :)
Ivanovic: lsmod | grep radeon should do it
wirry: http://dpaste.com/126330/
wirry: anything wrong with it?
tball: tlp, exactly as they said :)
wirry: well..the problem was: i could not access the pc as the network was down
adamk: wirry, It's hard to say as it's not complete :-)
wirry: hmm..
wirry: well..
MostAwesomeDude: ossman: I haven't even started.
wirry: dunno why its not complete
wirry: but thats everyhing i can get
ossman: MostAwesomeDude, I thought you said you had some basic first steps
wirry: i started and killed X per ssh
MostAwesomeDude: ossman: Yeah, but I haven't started on a shader compiler.
ossman: MostAwesomeDude, so you meant you had started the rest of the gallium code, not the compiler specifically?
MostAwesomeDude: ossman: Right.
ossman: nm then :)
wirry: i think i got the problem...
wirry: could be that /usr/src/linux points to a wrong (not installed) kernel recompiling xf86-video-ati could break X?
jcristau: no
jcristau: userspace shouldn't go look in /usr/src/linux. ever.
wirry: (and install of course)
tball: Zajec, Will powermanagement work right after the irq code is released?
ossman: MostAwesomeDude, are you familiar with the RMX
soreau: Well I'll be..
soreau: Seems there is no difference between using gallium globally or not, it was just a coincidence a mesa upgrade must have made around the same time
MostAwesomeDude: ossman: Not really.
ossman: I noticed it's what's hooked up to the TV DAC, so it is one thing that needs to be examined if it's causing the issues
soreau: eosie: I can't reproduce the color gradient for expo or cube anymore but when I run compiz it looks like this http://omploader.org/vMmhqdQ
soreau: eosie: This is how it looked when I first tried gallium a couple months ago, then it was 'compiz was fine except crazy colors for expo, cube and other plugins that used texture' and now it is back to this
soreau: I will try latest mesa update in a bit to see if it looks any different today
ossman: MostAwesomeDude, another question for you then. :)
ossman: MostAwesomeDude, do you know if UMS turns off unused CRTC before or after configuring the active ones?
ossman: KMS does it after, but it seems my hardware likes it better if it's done before
Zajec: tball: not everything, not right after
Zajec: tball: we will need to add callback reclocking from IRC handler
Zajec: tball: that should be easy
Zajec: tball: calculating minimum engine and memory without AtomBIOS will be easy as well
Zajec: tball: however sb (me?) will need to port AtomBIOS PowerPlayInfo table reading from radeonhd
Zajec: i could do this even nowe before IRQs release
Zajec: tball: but i'm busy with backlight redesigning
tball: Zajec, cool. You are an busy man
Zajec: unfortunately ;)
Zajec: i just wanted to add backlight controll to radeon kms driver
Zajec: and I ended redesigning whole backlight device class :)
tball: :D
tball: Zajec, how and when did you start with driver development?
MostAwesomeDude: ossman: I haven't done any real modesetting code, so I'm not a good resource. :T
ossman: MostAwesomeDude, yeah, I guess airlied or agd5f are the experts, but they seem to be doing other things during the weekend. slackers ;)
Zajec: tball: year ago
Zajec: tball: i needed hdmi audio and there was some old obscure patch from Christian for radeonhd
Zajec: tball: didn't work for me
tball: Zajec, So you figured it out yourself
Zajec: tball: i spent weeks comparing registers when using fglrx and radeonhd and finally told Christian what registers enabled audio for me, he fixed patch :)
ossman: MostAwesomeDude, do you have any r300 hw there though?
Zajec: tball: yeah, myself unfortunately
Zajec: tball: it's hard
ossman: or anyone else here that also has radeontool installed?
tball: Well comparing registers sounds very tiredsome
Zajec: tball: would be much easier if I could spend some time with developer IRL
tball: Zajec, well you do now? :)
Zajec: tball: if you call IRC IRC (in real life...) ;)
Zajec: IRC IRL
Zajec: i can talk with devs on IRC
Zajec: but would like to spend few days sitting with someone who could explain drivers
Zajec: sitting IRL = in real life ;)
tball: Ahh
Zajec: tball: what is "dk" ? where r u from
tball: :)
tball: Denmark
Zajec: ah :)
tball: You?
Zajec: pl. Poland
tball: :P Then we are neighbours
tball: Almost
wirry: finally - X works again and i have opengl2.0 \o/
mcgreg: congrats wirry
wirry: dunno what it was...after updating xf86-video-ati X stopped working...after i updated the kernel, libdrm, xorg-server it now works again
airlied: osiris__: that sounds mostly sane ;-)
airlied: though I'm not sure I want it in bo_map
airlied: at some stage we want ARB_sync but we want to probably make a new mapping interface for that
osiris__: airlied: hmm, ok. for now we need to remember to add flushes where needed.
osiris__: airlied: can you look at my r300-blit branch? it doesn't work on UMS. somehow bo relocs are broken
mwk: what hardware support does radeon have for preventing one application from writing over another's BO?
mwk: is there some sort of vm?
airlied: osiris__: we can just do it under kms ;-P, I'm not near any radeon hw until tomorrow
airlied: osiris__: how many places to we bo map?
airlied: esp with read vs write differences
airlied: I would guess sw fallback entry is the main one
osiris__: airlied: many: dma bo, textures (image migration to miptree, texsubimage), oq
osiris__: airlied: probably others
osiris__: airlied: no need to run it. it fails with cs emition error. dmesg says: [ 5119.936101] [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed
osiris__: > range check (reg=4540 sz=1)
airlied: osiris__: that sounds like a state emission problem
airlied: osiris__: probably caused by a missing state flush
MostAwesomeDude: mwk: None. It's all done in the kernel.
mwk: MostAwesomeDude: so, the kernel parses the command stream somehow and makes sure noone does anything naughty?
osiris__: airlied: no, it's the new blit code that causing it (and it doesn't use the state atoms)
airlied: oh oops this is ums
MostAwesomeDude: mwk: Yep.
airlied: its a pity it doesn't print out the offset
airlied: osiris__: sounds like userspace doesn't do the reloc
mwk: and what about memory access instructions in shaders?
airlied: so the kernel gets 0
osiris__: airlied: yeah, offset is 0
mwk: the ones that GPGPU uses...
osiris__: airlied: but I'm not sure why it doesn't emit reloc properly
airlied: osiris__: okay so its the userspace reloc processing then
airlied: osiris__: so dma bos should never be in a write domain btw
airlied: so the flush shouldn't affect them
airlied: textures are the only thing
osiris__: airlied: flush affects the dma bo too, because we the gpu need to execute current commands, before we change data in the bo
airlied: osiris__: yes but the implicit flush won't affect it
airlied: or else we'll flush too often
airlied: osiris__: you see I changed the mapping in master?
osiris__: nope
airlied: http://cgit.freedesktop.org/mesa/mesa/commit/?id=bd13e6e5e2403ada2098e3a07c0af4b4ba989ab7
airlied: i want to clean up some of the mess i made with cmdbuf/dma buf
airlied: I need same thing in ddx to do proper batching
airlied: osiris__: it might be worth asserting on write_reloc failing
airlied: we don't check its return code
osiris__: airlied: looks good
airlied: and in theory it can return einval in UMS
osiris__: airlied: there's one thing we could do to speed up fbos. e.g. teximage gets allocated with TexFormat RGBA8888_REV, then when attaching this image to framebuffer the format is changed to ARGB8888. finally when we want to render from this image, we need to migrate the image (which is very expensive) because of different formats of miptrees
airlied: osiris__: so we should change how we allocate textures? I thuoght about it and didn't like the chance of regrsesions
osiris__: airlied: I'd say we need to support more render target formats, and in case of unsupported format properly report an error in radeon_validate_framebuffer (just like intel does)
airlied: osiris__: I think we expose most of the render targets formats already
osiris__: airlied: for 4 bytes formats, there's only one ARGB8888 - while we could support RGBA8888, RGBA8888_REV and ARGB8888_REV
airlied: okay that sounds saner, just need to figure which chips can do what
airlied: I'm not sure r100/r200 can do all of them
osiris__: airlied: r300-r500 support full swizzling
osiris__: airlied: it's done in R300_US_OUT_FMT_[0-3]
ossman: airlied, are you familiar with the UMS code that disables all CRTCs and encoders before loading a new configuration?
ossman: agd5f is the one who committed it originally
airlied: ossman: not really
ossman: airlied, shame. I'm wondering if something similar is needed in KMS
happycube: looking @ r300g - i think CS-checking's the last big thing missing... at least on rv515
ossman: airlied, reading the vblank counter from CRTC 2 doesn't cause a hang if I do it (and turn the CRTC off) before getting into KMS' fiddling with the config
ossman: airlied, also, you have a few copy-paste bugs in radeon_legacy_output.c :)
ossman: BIOS locking is done incorrectly for TMDS and TV
airlied: ossman: we don't have a file called radeno_legacy_output.c
ossman: airlied, sorry. mixing up things between the userspace driver and the kernel one
ossman: it's radeon_legacy_encoders.c
ossman: airlied, would a patch like this be acceptable: http://pastebin.com/m5db84b79 ?
airlied: ossman: don't think that'll work too well
ossman: avoids the bug here at least :)
airlied: we need to work out what the bug is, what state the crtc is in when it hangs
ossman: I'm more or less out of ideas though, so I'm going to need help with that
ossman: airlied, one idea was that it is the RMX that's causing problems. I'm not really sure how it's configured, so I don't know how to test that theory
airlied: ossman: that could be it alright
ossman: the BIOS hooks the TV up to the RMX, hence the thoery
airlied: wierd not sure why it uses rms
airlied: since it already has a separate tv scaler
ossman: airlied, it could be me interpreting things wrong. hang on and I'll check the regs again
ossman: airlied, RADEON_DISP_OUTPUT_CNTL 10000008
ossman: and RADEON_DISP_TVDAC_SOURCE_RMX (0x02 << 2)
ossman: bit 31 is not in the headers, so no idea what that is
ossman: airlied, what would be interesting to test here?
airlied: ossman: boot with modeset off, turn off the RMX source there, and load radeno with kms maybe
ossman: booting with modeset off and then enabling it has been my general debugging mode as it tends to lock up now and then otherwise
ossman: just clear that bit with radeontool?
airlied: yup
ossman: let's see what happens
ossman: airlied, btw, which CRTC is the RMX fed from? Couldn't see a control register for it
ossman: always CRTC 0?
airlied: must be
airlied: yeah rmx is always crtc 0
ossman: airlied, still hangs :/
ossman: airlied, does that mean the RMX can be ruled out, or is there more to tesT?
airlied: well it sounds less likely
airlied: the fact reordering the code helps, sounds like we just need to shut things down before setting them up somewhere
ossman: airlied, given that the drm layer has most of the control in KMS, I'm not sure how to do that
airlied: the prepare hooks maybe or dpms off bits
ossman: hmm... odd.. radeontool is able to disable CRTC2
ossman: but it doesn't work when KMS tries to do it
airlied: it could be because something else gets disabled first
airlied: it sounds like some ordering
ossman: airlied, what should we shut down then? encoder? crtcs? everything?
airlied: well crtc or maybe dacs
airlied: need to try a few things until it stops hanging
ossman: one problem is that I don't think the KMS code has the same redundant state variables so we know what to turn back on again
airlied: we generally don't support unloading kms
ossman: airlied, I think this is a matter of moving those variables up to the DRM layer
ossman: airlied, does the KMS code touch any of the settings BIOS has set up? or is everything as-is until something calls the modesetting routines?
airlied: ossman: we leave things the same until we set the mode
airlied: we do turn off some bits when we set the memory controller up
airlied: so we enable/disable crtc scanout
airlied: r100_mc_stop
ossman: airlied, hmm... there is an "enabled" member of radeon_crtc
ossman: but I can only find it being read, not written
ossman: airlied, I suspect the code should be looking at crtc->base.enabled instead
amarks: how do i turn on dpms from userspace?
amarks: rather than waiting for it to idle out
amarks: ok, xset dpms force standby works
sgcb: hey guys, I've got an rv630 and I'm unable to startx, screen just freezes with cursor in top left corner
sgcb: i get no errors as far as i can tell, xorg log just stops at line 413: http://pastebin.com/db019225
airlied: sgcb: what X server is that?
airlied: might want to get a 1.7 released server
sgcb: airlied: now that you mention it, I usually keep desktop/laptop synced with debian unstable/experimental repos...
jcristau: experimental has 1.7.0 since some time
sgcb: but now that i compare logs it seems like my laptop never got the update somehow
physical: hiya guys
physical: im wondering if anyone could perhaps give me some advicwe
ossman: airlied, yay! success!
ossman: disabling encoders was insufficient, but disabling crtcs got things running
physical: awsome
ossman: hmm... although... that would be roughly the same my earlier hack did
physical: just hating on my gfx card at the minute
physical: well hating on ati rather
physical: having so many issues with stability
soreau: physical: What seems to be the problem exactly?
ossman: airlied, this is the tweak I've added, roughly based on what the radeon DDX does: http://pastebin.com/m4ac786ad
ossman: airlied, now is this acceptable in the drm core, or do we need to move it to the radeon driver?
physical: well
physical: soreau im not quite sure
physical: hd 5770, its not even causing bsod its just giving me the funky multicoloured screen of doom
soreau: physical: The open radeon driver does not support HD5770 for 3D yet
soreau: and we dont support fglrx here (see topic)
soreau: Plus, linux does not have such a thing as BSOD
soreau: ;)
physical: ah but it won't even let linux install there is my issue :P
DanaG: At least not right now.
DanaG: KMS will make the full-screen thing possible.
soreau: physical: Then I assume you are running windoze now and want to install linux?
physical: aye
physical: not found a distro that likes the i7 950 and the hd5770 yet
soreau: That is beyond the scope of this channel unfortunately, maybe you can try #linux
honk: Plus, linux does not have such a thing as BSOD <-- I think kernel panics qualify as bsod replacement
soreau: honk: Nope, they don't.
honk: yeaah they do ;p
DanaG: Itw on't be a BSOD until you get a message that tells you the useful info.
DanaG: Kernel panics are just a blinking-caps-lock-of-death.
DanaG: Or, if your system is like mine, caps lock turns on, and stays that way. Doesn't even blink.
soreau: You guys can all go to #linux. Bye.
DanaG: has finished making his point, and switches back to "lurk".
honk: DanaG: useful info? bsod?
honk: heh
DanaG: Stop 0xSOMETHING is at least google-able.
honk: do the never versions of windows even show those? ;P
honk: I thought they stopped doing that ;)
honk: anyway.. kernel panics show useful information, too. if you manage to see 'em ;)
MostAwesomeDude: Actually, with KMS, panics *do* cause a BSOD.
MostAwesomeDude: And all the panic data is dumped to screen.
DanaG: Is that framework already in place?
DanaG: If so, cool.
soreau: MostAwesomeDude: I have never seen a blue screen
DanaG: Now I just need those new power-savings patches to go into some git tree, so I don't have to manually apply them.
MostAwesomeDude: soreau: Have you ever had a panic with KMS enabled? Caps Lock flashing, etc.?
MostAwesomeDude: I haven't seen it myself, but I've seen photos. It's pretty cool.
soreau: MostAwesomeDude: Yes I have, there are plenty of modules that will do it reliably
soreau: The screen does not change, instead it freezes in the flashing lights
DanaG: Is it something like this thing? http://infohost.nmt.edu/~holstien/Blog_Images/Panic_080725.jpg
DanaG: that's Apple there.
soreau: In any event, there is no bsod since there is no blue screen
honk: a bsod doesnt really have to be blue ^^
soreau: By definition, it does.
soreau: honk: Did you know bsod is an acronym? :P
MostAwesomeDude: Hm. jbarnes would know what it looks like, but I don't think he's in on weekends.
jcristau: soreau: b can be black, too :)
honk: I know what bsod means. I also know that you can change the color even in windows ;P
soreau: jcristau: Ok, you have me there :)
honk: that doesnt change what it _is_ just what it looks like
Dr_Jakob: MostAwesomeDude: ping, are you on OFTC?
Dr_Jakob: Heh speaking of BSOD there should be a WSOD http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/6881.html
ossman: airlied, proposed fix: http://pastebin.com/m3d9f3403
AndyWas: zajec: just emailed info about the RV730 HDMI audio hack for radeonhd
Zajec: AndyWas: just replied :P
Zajec: thanks :)
AndyWas: Prosze bardzo...
Zajec: AndyWas: huh :) didn't expect to meen any driver hacked from my country ;)
Zajec: *hacker
AndyWas: Half...
Zajec: ACTION going sleep, leaving kernel compiling :)
Zajec: ACTION good night
Zajec: AndyWas nice work, again :)
AndyWas: Other half English! ;-)
AndyWas: You are 2 hrs ahead...
AndyWas: Same here!
MostAwesomeDude: Dr_Jakob: Pong. I'm not on OFTC at the moment, but I could be.
Dr_Jakob: MostAwesomeDude: I was talking to the gc-linux guy(s), he went to sleep already but I told him where to find you :)
MostAwesomeDude: Dr_Jakob: Ah.
MostAwesomeDude: Yeah, that's one of those things I was thinking about tackling during winter break, but I think I'll do shatter instead.
MostAwesomeDude: Just for ajax. :3
Dr_Jakob: Heh
Dr_Jakob: It would be a nice project, but yet again no time at all.
Dr_Jakob: Its a shame there is no gallium for FF
MostAwesomeDude: Yeah, it's on the backburner along with "nouveau for xbox."
Dr_Jakob: One thing that would be nice to salvage would be the texture code from st/mesa.
eosie: soreau: compiz works flawlessly here, please try git master + this: http://old.nabble.com/-PATCH-0-6--r300g%3A-vertex-shader-outputs-mapping-and-rasterizer-setup-rework-ts26550488.html
soreau: eosie: On which chipset?
eosie: RV530
soreau: I have rv350
soreau: According to adamk, there are a lot of differences between running gallium on r5xx and r4xx
soreau: But I will try the patch and let you know
MostAwesomeDude: Please do try it out. I'm not sure when I'll have time.
MostAwesomeDude: (For a maintainer, I sure do seem to not maintain very often...)
PinkFreud: hey, folks. using the radeon driver for a radeon hd 2400 card. is it possible to convince fullscreen sdl to work with this driver?
soreau: MostAwesomeDude: heh. I'll try it out right now
PinkFreud: for the moment, with a dual-head setup, trying to have an sdl app go fullscreen causes the app to stay windowed, and both displays to mirror each other.
soreau: eosie: Do I want all 6 patches?
PinkFreud: is this a known issue?
soreau: PinkFreud: Curious, which app is it?
eosie: soreau: you can omit the first two
soreau: eosie: I assume they're already in master?
eosie: not yet
PinkFreud: soreau: so far, any app I try. mplayer -vo sdl ..., dosbox, scummvm, ...
PinkFreud: all behave the same when I try to fullscreen them.
soreau: PinkFreud: I don't know of this issue at least.. what happens when you try to go fs?
PinkFreud: soreau: er, exactly as I described above :)
soreau: eosie: Should I grab the first two also or are they only for r5xx or what?
soreau: PinkFreud: Oh yes, that :P
soreau: PinkFreud: Which kernel and version of mesa?
PinkFreud: Linux mordor 2.6.32-rc8 #2 SMP Sun Nov 22 13:32:15 EST 2009 x86_64 GNU/Linux
PinkFreud: and running mesa 7.6
soreau: Maybe you should consider trying latest mesa
soreau: latest libdrm and ddx wouldn't hurt either
PinkFreud: er, thought that was latest
soreau: mesa git is already at 7.8
PinkFreud: ahh
eosie: soreau: well, they basically don't do anything, so you don't have to use them
soreau: eosie: heh. I hope the others will apply cleanly without them then
PinkFreud: hmmm. glxgears is also failing. thought 2.6.32 was supposed to have a working drm driver for rv610
eosie: they surely will
soreau: PinkFreud: What is the output of 'glxinfo|grep renderer'?
PinkFreud: IRQ's not enabled, falling back to busy waits: 2 0
PinkFreud: OpenGL renderer string: Mesa DRI R600 (RV610 94C1) 20090101 TCL
soreau: well irq is still not implemented but you still should try latest libdrm, mesa and ddx and with KMS as well
PinkFreud: http://pinkfreud.mirkwood.net/drm_dmesg.txt
PinkFreud: I just noticed those sitting in dmesg
soreau: eosie: http://pastebin.com/m1404bbc
eosie: soreau: :(
PinkFreud: soreau: bleh. trying to stick with debian packages as much as possible on here.
soreau: PinkFreud: Then you'll be waiting for stuff to get fixed for a long time
soreau: eosie: I can't even get patch 1 to apply :P
PinkFreud: not that I have a problem with using debian's unstable repo - but I prefer sticking with package management
soreau: eosie: Any idea why they wont apply?
eosie: soreau: it seems like a mistake in copy-pasting from nabble, could you give me your email address?
soreau: eosie: Sure, oreaus at gmail dot com
eosie: ok, sent
soreau: eosie: Yup you were right
soreau: Building now
eosie: cool
PinkFreud: hmmmm
PinkFreud: according to what I'm seeing on arch linux forums, the errors I'm seeing in dmesg are related to the kernel not having drm support for the card.
PinkFreud: op fixed it by going to 2.6.32-rc6. I'm on -rc8, and I'm seeing the errors.
PinkFreud: strange.
airlied: you need a new mesa I guess
airlied: the api isn't stable until the kernel releases
airlied: the fact that some distro ship stuff before that means they shuold also shpi the fixed up bits
PinkFreud: iirc, mesa 7.6 was the version which added support for r600
PinkFreud: hmmm
soreau: eosie: Yup, compiz totally works now :D
eosie: great
airlied: no mesa 7.6 just happened to have r600 code in it, it was finalised
PinkFreud: airlied: what do you mean 'just happened'?
eosie: soreau: and BTW when exactly it did not work?
airlied: PinkFreud: the code went into mesa, and mesa got released, but the r600 driver wasn't in a reallly ready state
PinkFreud: ahh
soreau: eosie: What do you mean? It has that dark screen/silhouette thing going on with latest master r300g
PinkFreud: still - people are apparently convincing that driver to work.
PinkFreud: I'm just wondering why I appear to be unable to :)
PinkFreud: ahhh, nevermind.
PinkFreud: looks like the api did change with rc7. gah.
eosie: soreau: yeah I mean exactly this... so the patches fixed it?
soreau: eosie: Correct.
PinkFreud: soreau, airlied: thanks
soreau: eosie: And, alpha blur looks like it wants to work so badly :)
soreau: eosie: Whoa, fisheye mode is crazy cool now too ;)
soreau: fisheye is way faster on gallium than classic mesa even though it displays more or less garbage
soreau: you can see the effect but it does not show what's under the cursor but instead some random bits
soreau: Wow, even showmouse textures work
soreau: I must try some games now
eosie: soreau: where can I find the fisheye? and what do you mean by "alpha blur"?
soreau: water works too, this is amazing
eosie: glad to know it works
soreau: eosie: ccsm>Accessibility>Magnifier>General tab>Mode for fisheye and ccsm>Effects>Blur Windows>Alpha Blur (enable it and make sure Alpha blur windows are 'any' then use a transparency like Alt+Scroll on windows)
soreau: The Blur Filter type is also a factor of alpha blur
eosie: the fisheye appears to behave exactly like gen-mipmaps
soreau: mipmaps for cube seems to be fine but not for expo
soreau: It totally rocks I can see a speed increase for transparent cube too
soreau: enemy territory is still a pretty slow mess though
soreau: these patches fix some things in neverball menu
soreau: and splash works now in OA
soreau: Color me impressed
soreau: Thanks for your hard work eosie!
eosie: you're welcome
soreau: Hopefully alpha blur will work soon, I've waited so long for it to work again
soreau: and thanks to MostAwesomeDude too :)
soreau: real terminal transparency is not working however *shrug*
soreau: eosie: Oh yea, and Focus Blur has interesting behavior too
soreau: It's supposed to slightly blur everything except the focused window
eosie: Focus Blur appears to work here
soreau: here it causes black windows and other bizarre behavior
soreau: But water works so much more smoothly than with classic mesa :)
soreau: disabling alpha blur causes terminal transparency to work again, wierd
soreau: weird even
soreau: eosie: Transparent decorations and well http://omploader.org/vMnZubA
soreau: If I use match 'any', the whole screen looks like that black except the focused window
eosie: interesting