ssieb: airlied: the resume crashes I have are a kernel bug. I wonder how many of the other ones filed are as well.
vehemens: anyone know which r6xx/7xx cards the stability problem is with?
hifi: Sarvatt: didn't help rebuilding with the latest commit
hifi: oh, little googling helped
hifi: removed .drirc, works
Sarvatt: ahh i was going to suggest messing with those settings
Sarvatt: theres a metric crapton of settings in there on radeon compared to intel
hifi: hm, openarena runs but quake 2 spits out XF86DGANoDirectVideoMode
Sarvatt: theres no DGA under KMS
hifi: uhh, that... sucks
hifi: how do you catch the mouse without DGA extension?
vehemens: noticed that ~agd5f/drm appears to be missing a couple of updates such as the VB_AGE_TEST_WITH_RETURN macro doesn't have the r600 check
EruditeHermit: airlied: are you working on performance now?
nha: hifi: you can still catch the mouse, using some more modern extensions (sorry, input is not my area of knowledge), but consider that you should only catch the mouse if absolutely necessary
nha: God kills a kitten every time you catch the mouse
nha: or something like that
hifi: nha: fps games don't like when the mouse gets out of focus :)
nha: I guess. But note that e.g. SDL has had a modern-compliant way of doing this for, I don't know, the last half decade at least
nha: at least that's what I was told...
nanonyme: I thought XInput2 was marketed to be the magic bullet for games.
hifi: didn't sdl use DGA extension as well
nanonyme: Probably.
nanonyme: hifi: Which game are you talking about?
hifi: my problem is quake 2 which uses DGA for mouse capture
nanonyme: Right...
hifi: it refuses to initialize video with the error XF86DGANoDirectVideoMode
nanonyme: I know at least Wine will get ported for using XInput2 for that.
hifi: shouldn't there be some backwards compatibility layer for DGA games
hifi: well yes, I can and will try to patch quake 2 to use XInput2 later
nanonyme: With legacy closed source games you probably just have to cry.
hifi: but for now wouldn't SDL be broken with KMS if it uses DGA for capture_
hifi: and on another note openarena works fine so it might use some black magic for that
nanonyme: Afaik not all fps need the same mouse hacks. Ran into that on Wine too.
hifi: wine doesn't do capturing, most games suffer from that
hifi: but it's of course less noticable if you run them fullscreen
hifi: for me it doesn't help with my dual head setup, mouse always gets loose if I pull hard enough :)
nanonyme: Well, they've tried doing it first with DGA, then reading the mouse node directly.
hifi: though it's kind of "handy" to focus IRC while on fullscreen game
nanonyme: They're fully aware though that they've wanted XInput2 all along.
hifi: but I really need to fix quake 2, kind of hard to play it if it doesn't start :p
nanonyme: Erm, directly, not readily. Cell phone typos suck.
hifi: will look at SDL for a solution
hifi: OA uses SDL for rendering and it works fine, so my solution lies in SDL
nanonyme: Right.
nanonyme: What if you find a hack that should be dropped in favour of XInput2? ;)
hifi: I can play until XInput2!
hifi: pretty hard to play if the game fails to start
hifi: hmm, built without DGA extension and the mouse is still captured just fine
hifi: problem solved \o/
hifi: 50% performance drop when going from non-KMS to KMS in quake 2 o/
nha: :/
nha: this may be related to texture and framebuffer tiling (which is being worked on), but it might also be something else, can't tell you for sure
hifi: and drawing net graph still does another ~50% loss :)
osiris_: nha: great! many thanks for this
nha: osiris_: you're welcome :)
hifi: but hey, at least kms is working and I think I have no more screen corruption
nha: net graph drawing is actually an interesting use case
hifi: and the xorg edgers package messed up my dpi
nha: quite untypical for games, but perhaps typical of what apps like blender are doing, and therefore worth accelerating
nanonyme: nha: And also a typical GPGPU application?
hifi: it just draws simple already accelerated gl stuff but it hits hard regarding performance
nha: nanonyme: not sure about that
hifi: I got no definitive answer here before why it would slow it down so much
nha: hifi: I mean that the way it is drawing this stuff (e.g. vertex emit patterns and so on) would be rather untypical
hifi: wait, I have the small quake 2 gl snippet
nanonyme: Ah.
nha: e.g. it might not use vertex arrays, it might use strange vertex attribute formats, there are all sorts of ways in which you can deviate from the "fast path"
osiris_: nha: see http://radeon.pastebin.com/mb647208 my additions are after ++
osiris_: I've pushed the patches to my private repo
nha: the idea is that we should make sure that the "fast path" is as big a target as possible, but of course that requires manpower, and that manpower is often tied down in making sure things are working correctly at all ;)
hifi: nha: http://paste.ubuntu.com/216172/ everywhere where Draw_Fill is used hits the rendering hard, netgraph there is one example of it
nanonyme: Hmm, paste.ubuntu.com seems to be down.
hifi: wat, I just pasted there
nanonyme: Maybe it's related to me not being able to connect to packages.ubuntu.com either yesterday then.
nanonyme: Might be routing issues.
osiris_: nha: I've also pushed my WIP branch of VBO support
hifi: it's hilarious how hard it's to draw net graph, if I uncap my fps it gets way up to around 400 and when I enable netgraph it drops to 80
evocallaghan: Anyone around for a tiny patch to commit :) http://junk.auroraux.org/radeon.patch
nha: evocallaghan: interesting; does that break compilation? if so, why doesn't it always break compilation?
nha: is confused
nanonyme: nha: Should be a trivial formatting issue.
nha: hifi: ouch! I suspect the fact that this code constantly disables and reenables texturing stops us from emitting all those quads in a single big vertex array, so instead we emit thousands of seperate vertex arrays, and that is obviously very slow
hifi: so thats called like 800 times a frame when I run my game 800x600
nanonyme: evocallaghan: Did the original code emit a warning?
osiris_: nha: I got a question about vertex shaders. I haven't completed the transition yet, I'm wondering whether should I also rewrite MOV,MUL and ADD into MAD like I did for e.g. XPD and should it be part of translateInsts function or seperate step so that local transformations can use MOV,ADD and MUL
evocallaghan: Yes
osiris_: what do you think?
nanonyme: Sure, fine then.
evocallaghan: nha: Just a warning clean up. that is all.
hifi: nha: how does nvidia and fglrx do the magic?
hifi: even the most lowest end geforce runs the same net graph just fine
hifi: has done since the 90's :)
nha: evocallaghan: ah, I didn't realize that would give a warning
nha: hifi: sure; we could certainly do much better in this case
hifi: moar fps \o/
airlied: EruditeHermit: not really just do some idle hacking
evocallaghan: nha:Commit it please, I and I can remotely feel happy today, nothing else is working here :/
airlied: btw for kms vs non-kms the latest patch on master might help
airlied: we have to figure out the whole viewport stuff
airlied: too many flushes on viewport causes bad things.
airlied: round trips to X server ftl
nha: evocallaghan: k, I will commit it
hifi: nha: how hard would it be to optimize that stuff? I would imagine thats something many games do to draw 2D?
airlied: failing piglit stencil clear tests now
evocallaghan: nha: Thanks, see PM.
evocallaghan: feels remotely good now :/
hifi: nha: actually, I tried just for fun to comment the texture disable and enable lines, no performance hit anymore
hifi: though the result is a little unexpected :)
nha: hifi: you mean, the visual result or the performance hit result?
hifi: visual result, it actually draws the netgraph but in random colors ;)
nha: hifi: the performance hit result is perfectly predictable once you think a bit about how the driver works :)
hifi: I get *no* performance hit at all
nha: well yeah...
nha: it'll draw the netgraph with some random texture :)
hifi: now go and optimize that ;)
hifi: but from the program side I could optimize that by doing disable and enable after I draw the whole netgraph?
nha: hifi: yup
nha: hifi: unfortunately, right now things like bugfixing are higher on my list than optimizing inefficient state changes :}
nha: osiris_: the thing is that the fragment program hardware does not have dedicated MOV or ADD instructions; vertex program hardware, on the other hand, does have dedicated MOV and ADD instructions
nha: osiris_: for that reason I would vote not to replace them by MAD prematurely
hifi: waits in the corner
nha: hifi: the thing is, stuff like osiris_' work on VBOs will have a much higher performance benefit across the board and in modern games
osiris_: nha: aah, you're right. I keep on confusing vertex and fragment shaders capabilities
hifi: hehe, the optimization in the engine worked :)
nha: osiris_: I'm running your shaders-cleanup branch + my fix to the fogcoord regression through some tests right now
hifi: nha: and we old schoolers need to wait for things like quake to work properly in favor of newer games? :)
nha: hifi: I know, it sucks. To be honest, I'm a bit amazed that Carmack ever got away with that, though
nha: maybe the performance characteristics were different back in the day
hifi: got away with stuff like Draw_Fill?
nha: yeah
osiris_: nha: me too. besides piglit, wine d3d9 tests proved to be very helpful too
valgaav: Hi I just tried mesa 7.6 today build with my rs690 and GLEST finaly started to work (before it was not possible to select units) .. However this time selection works but as soon as it is done the game fallbacks to software rendering with one thing is very slow and causes things to not display correctly
valgaav: the message in console logs is WARNING! Falling back to software for render mode != GL_RENDER
valgaav: So the thing I would like to ask should I report a bug about it or perhaps it's a game problem ?
nha: osiris_: glean/texEnv fails :/ http://people.freedesktop.org/~nh/piglit/results/R500/RV530200907121332/test_glean__texEnv.html
nha: glest uses feedback mode? omg
nha: valgaav: first of all, one such fallback message needn't mean much. It's entirely possible to perform one operation using software fallbacks and then return to hardware acceleration
nha: but if the performance seems to be stuck at very slow levels even after you deselect units and so on, you should probably file a bug about it
hifi: nha: but don't get me wrong, I'm really thankful for all the work you guys have done and will happily wait for another year
valgaav: yeah it stays slow and some things that displayed correctly like tree textures are all messed up ..
nha: osiris_: bisecting the texEnv problem now
nha: hmm, I should write a script that does such bisecting fully automatically :)
valgaav: nha: I'm off to bugreport then :) thanks for help
nha: valgaav: you're welcome
nanonyme: nha: Sounds good if the bug's presence can be detected via automatic means. :)
nha: nanonyme: that's the whole point of piglit :)
nanonyme: Oh, right.
nha: so piglit + automatic bisect = win
nha: so piglit + automatic bisect = win
nanonyme: Yeah. ;)
nha: whoops
nanonyme: Double win!
nanonyme: really has to find out properly some day what piglit is about
nha: it's not 100% user-friendly, but it's a good way of keeping mesa developers honest
nanonyme: Right.
nha: basically, if you just run a piglit test on your own machine every couple of days with a fresh git master build, and check that there were no regressions, you have a higher chance that *other* applications will also not start to fail on your hardware
hifi: where should piglit testing target currently
nanonyme: Hmm.
hifi: which branch of everything and non-kms or kms
nanonyme: nha: How about writing trying to get that combo setup of yours user-friendly enough that you could turn average Joe into a useful tester? ;)
nanonyme: s/writing //
nha: hifi: basically, your best bet is master of everything, and *both* non-kms *and* kms (or whichever one you personally care most about)
hifi: isn't kms going to replace non-kms in the future?
nanonyme: Not in near future, me thinks.
nanonyme: At least for everyone.
muep___: I tried the drivers from http://vwbusguy.wordpress.com/2009/07/11/free-open-source-drivers-for-newer-radeon-hd-cards/ for my HD3650. Things seems as usual, but glxinfo says direct rendering: Yes. However, it also says OpenGL renderer string: Software Rasterizer
hifi: nanonyme: but if it will, I see no reason to keep testing non-kms
nanonyme: muep___: Direct rendering is to be expected with modern software rendering.
nanonyme: Just ignore the variable.
muep___: ok
muep___: maybe it just doesn't yet work for me
nanonyme: muep___: Check your xorg log.
nanonyme: Should be trying to load r600_dri.so.
nanonyme: And there should be a failure.
muep___: here, if anyone's interested: http://fpaste.org/paste/18409
muep___: AIGLX tries to load r300_dri.so
muep___: r600_dri.so isn't mentioned in the log at all
nha: osiris_: the texEnv bug is the following: Now that trackUsedComponents is precise, there is a problem with vertex program caching: If the VP was originally compiled with an FP that reads only one component of an attribute, then the VP will only be compiled to generate that component; however, if one now uses the VP with a very similar FP that reads the same attributes, but uses *all* components of that attribute, then this is not reflected in
nha: the wanted_key in r300SelectVertexShader and therefore the VP does not get recompiled
nha: osiris_: obviously, there are two possible solutions
nha: Option 1. Don't do the whole trackUsedComponents shenanigans
nha: Option 2. Compute used components in the fragment program compiler, and store the used components in the fragment program itself, which can then be added to the wanted_key
MostAwesomeDude: votes for (1)
nha: tbh, I'm not sure which one is better; I have a feeling that component-level tracking does not give us many benefits
nha: so I would side with MostAwesomeDude
osiris_: nha: in option 1 we would assume that all components are used?
nha: yup
nha: just get rid of trackUsedComponents, and set Sourced to 0xf
osiris_: then I vote for 1 too
nha: (in nqssadceInit, I mean)
nha: the if (fp_reads & ...) test is obviously still good
MostAwesomeDude: TBH GL has some requirements for unused component values, so you really shouldn't end up with undefined components in most cases.
MostAwesomeDude: Not sure exactly what you guys have been doing with that though.
nha: MostAwesomeDude: our definition of "unused" comes from program analysis: we're looking at which components are actually read by the fragment program
nha: MostAwesomeDude: think of it as "whole program analysis", where the "whole program" consists of *both* the vertex program and the fragment program
nha: so our definition of "unused" is in fact correct (except for this bug with vertex program caching)
MostAwesomeDude: nha: Ugh. Yeah, shader linking is unfun.
evocallaghan: nha: What should I do about http://junk.auroraux.org/drm.patch to get that committed ?
MostAwesomeDude: If you guys are really tracking all that state through linking, then (2) would be the better long-term solution...
MostAwesomeDude: ...but it depends on whether or not you actually get any serious optimizations from it.
nha: tbh, I would go with (1), though: increasing the size of the wanted_key by much is not a good idea, and on the other hand there probably isn't much to be gained in this particular instance
nha: it's just the simpler thing for now
nha: evocallaghan: is drm/shared-core even used anymore?
nha: evocallaghan: all the cutting-edge development is now actually happening in linux kernel trees; if you want to support Solaris as it seems you do, you should talk to people who are facing the same issues on the BSD side
osiris_: I agree with nha, also I don't know if we are going to optimize non gallium r300 shader compiler any more so I don't think that going with 2 would give us noticeable performance boost
nha: was rnoland a bsd guy? I don't remember
nha: osiris_ / MostAwesomeDude: my hope is that, especially after osiris_' cleanup, we can extract the compiler into something shared between gallium and old-school; but that's a bigger task, and I'm not sure if I'll find the time to pull it off
nha: after all, it would be a waste to loose all the lessons from old-school shader compilers as we move forward to gallium; there are so many little details that are easily forgotten in a rewrite
nha: evocallaghan: if in doubt, ask on the dri-devel mailing list
evocallaghan: nha: I see. OK
osiris_: nha: are you going to remove the trackUsedComponents or should I do this?
nha: osiris_: I'll let you do it; please also remember to add my fog fixes; beyond that, it seems at least to me that your work is ready to be merged to master
osiris_: nha: any comments on the newest patches in shaders_cleanup?
nha: osiris_: they all look fine
osiris_: nha: ok. thanks again for the review, testing and bug squashing
mikkoc: is it normal that performance sux with kms enabled? I mean general slowness scrolling, glxgears has half FPS, and on top of it amarok playback stops everytime something "graphical" happen, like window resizing
mikkoc: not only resizing, pretty much every action makes amarok playback jerky
mikkoc: xorg log http://zlin.dk/p/?MTFiNTg3
nha: mikala: that doesn't sound normal
nha: erm
nha: I meant mikkoc, sorry
mikkoc: yea it really sucks :(
mikkoc: mesa libdrm and xf86-video-ati master
mikkoc: kernel 2.6.31-rc2+git4
mikkoc: err, this is the log: http://zlin.dk/p/?NDA3NmUy
mikkoc: tremulous is absolutely unplayable
mikkoc: output is flooded with:
mikkoc: Mesa: User error: GL_INVALID_VALUE in glLockArraysEXT(count)
mikkoc: Mesa: User error: GL_INVALID_OPERATION in glUnlockArraysEXT(reexit)
evocallaghan: nha: Well this drm patch fixes xf86-video-ati master so that it may compiler on master fine.
Sarvatt_: have ya screwed with settings in driconf yet mikkoc?
mikkoc: i have vblank_mode=0 in drirc
mikkoc: dunno if its related
osiris_: nha: there's a problem with nqssadce
osiris_: we should probably disable it when program uses relative addressing
nha: ouch, yes
nha: address registers aren't supported of course :/
vwbusguy: muep_, interesting
vwbusguy: muep_, I have heard a good success report with an HD 4800
nha: osiris_: in the short term, you're probably right to disable nqssadce when relative addressing is used; in the long term it should be fixed to support it
nha: osiris_: as for your VBO branch, I can't say much yet, but keep me updated on progress!
osiris_: nha: ok, any ideas how the nqssadce could deal with relative addressing?
nha: I'll have to meditate on that
nha: it shouldn't be too bad, though
nha: relative addressing only works on program parameters, right? not on temporary registers
nha: so basically we need to add tracking of address registers in addition to temporary registers, and we need to make sure that constant registers are treated correctly
rnoland: nha: evocallaghan yes... i'm the bsd guy.....
evocallaghan: Hi
evocallaghan: :)
rnoland: frankly, it's a mess...
rnoland: radeon is the easiest to keep track of right now...
rnoland: I just try to stay on top of alex and make sure i don't miss stuff..
rnoland: the ati folks are fairly good about not going out of their way to make things harder for me...
evocallaghan: Umm, I ran into needing to apply this http://junk.auroraux.org/drm.patch
evocallaghan: Yes, these folks here are much nicer then the intel folks ;(
evocallaghan: I much rather work with people here and on the hw too.
rnoland: yeah, what sucks is that anholt used to be the bsd guy....
rnoland: but he has been drinking the kool-aid too long...
rnoland: I do all of my work in our svn repo now...
evocallaghan: kool-aid rots your teeth
rnoland: but at least for radeon, the code that is in linux and what I ship are very close...
rnoland: so many patches will apply directly so long as I munge the patches...
evocallaghan: Cool, we there is a team of three of us that are porting to AuroraUX/OpenSolaris.
evocallaghan: s/we/well/
rnoland: evocallaghan: wow... 3... I am pretty much alone...
evocallaghan: :D
evocallaghan: We all just come together recently. All got our heads in the AMD docs at the moment as you would image :p
rnoland: for the most part, i try to track airlied' drm-linus branch right now..
rnoland: i've got some stuff from alex' private tree for r6/7xx 3d
rnoland: ttm and kms are going to be more of a challenge for me to deal with...
evocallaghan: Yea, I was just thinking about it myself
evocallaghan: I wonder how we can work together better rnoland ?
vwbusguy: muep_, I also saw the supported cards list from your log shows all the r6xx and r7xx ones
rnoland: evocallaghan: not sure... it was tricky for even the 3 flavors of bsd to try and coordinate...
vwbusguy: looks like it's a pretty comprehensice HD 3000 / HD 4000 list
evocallaghan: rnoland: I'm not currently in a position to say anything more.
evocallaghan: rnoland: Where do I look for all your changes and what where the main drama's you faced between the BSD's ?
rnoland: evocallaghan: our main svn repo....
rnoland: <-FreeBSD
rnoland: dragonfly is tracking my work.
evocallaghan: Ah ok, I thought you may of had a branch on xorg, they have a mazz of branches
rnoland: open and net work in their respective cvs repo's
rnoland: not anymore...
biotube: cvs? people still use that? o.0
evocallaghan: I mean xorg, not freebsd.
rnoland: i used to use drm git and just import that into our kernel periodically...
rnoland: biotube: we still use it for ports... we use svn for base
rnoland: no compelling reason to switch for ports.
evocallaghan: we use mtn.
evocallaghan: as long as it does the job its fine.
rnoland: yep, git isn't suited to our needs exactly, though I wish that svn had some of the features of git and vice versa...
evocallaghan: has been happy with monotone over git.
rnoland: lucky me... i get to work with cvs, svn and git all regularly... and perforce on occasion...
evocallaghan: However, will avoid a VCS war
rnoland: evocallaghan: i'm not that religious about vcs...
evocallaghan: Same.
evocallaghan: is not religious !
biotube: i had just thought svn had completely subplanted cvs
evocallaghan: :)
biotube: you learn something new every day
rnoland: our svn repo is huge compared to cvs... but....
rnoland: git didn't/doesn't suport sub-project checkouts which was a big issue for us...
rnoland: git also doesn't seem to like really large projects...
biotube: no subproject support would explain why the drm-2.6 tree contains an entire kernel
evocallaghan: Yep, many have this problem !
erjc: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg216682.html , terminate:ctrl_alt_bksp, rv350, pcbsd-7.1.1 (7.2)
erjc: sorry to butt in here
rnoland: erjc: ??
rnoland: is that your post?
erjc: terminate just doesn't happen for me
erjc: tried all these solutions
erjc: talked to kris
erjc: referred back to you
rnoland: zapping is in general evil....
biotube: no reason to disable it
erjc: not if it saves an fscking lockup
rnoland: i don't do it... but it should work if zapping is enabled in the config and the key sequence is getting mapped.
erjc: I got to try out of freedeskop/hal...forgot that part, sorry
evocallaghan: is getting annoyed and this bloody python software ! ;(
rnoland: since xkeyboard-config 1.5 I think it was, it is a seperate key map...
biotube: evocallaghan: winking and frowning at the same time has to be awkward
bridgman: discovers that nqssedce is actually an acronym, which had not seemed high on the list of possibilities
nanonyme: o.O
nanonyme: bridgman: The fact that Google returns nothing at all with that sounds confusing. ^^
bridgman: yeah, it doesn't actually jump out at you
nha: bridgman: congratulations :)
bridgman: I may have mis-spelled it, hold on ;)
bridgman: looks in radeon_state.c again
nha: I had a really hard time coming up with a descriptive name of what the code does; in hindsight, using a completely weird combination of letters might not have been the smartest move ;)
bridgman: nha; it keeps out the riff-raff
nha: hehe
bridgman: it kept me out ;)
evocallaghan: rnoland: Catch you later buddy.
rnoland: evocallaghan: ok, cya...
rnoland: i'm mostly always here....
bridgman: nanonyme; try nqssadce - *a* not *e*
evocallaghan: rnoland: Coolies :D
nha: not quite static single assignment & dead code elimination
bridgman: I was thinking Saskatchewan Snowmobile Association, thanks ;)
bridgman: in all seriousness, I was thinking SSE (Streaming SIMD Extensions) and had a big heap of questions related to paired instructions and the potential of extending the design to 5-way superscalar on 6xx and higher
bridgman: but I guess I won't bother now ;)
nha: unfortunately, no
bridgman: MostAwesomeDude was lamenting the loss of some paired instruction code a week or so ago but I can't find it in the logs, any idea ?
nha: SSA is about not having variables but only values that are assigned to only once; unfortunately, that's problematic to do with shaders because of the multiple components per variable: each instruction might only assign a subset of components
nha: doesn't ring a bell right now
bridgman: wouldn't SSA use more registers then, or is the idea that you can make heavy use of the last result from the shader and not have to go into a register ?
nha: the analysis is used to eliminate dead code; afterwards there is another register assignment pass to reduce use of temporaries
bridgman: doesn't that kind of turn registers into variables again ?
biotube: I think the idea of SSA is to create a format that's easy to check for dead code
biotube: after that, it wouldn't matter much
biotube: or did I just stick my foot in my mouth again?
nha: biotube: you got it pretty much right
biotube: that's a relief
nha: an SSA form is also useful for reordering code and so on, which we also use in the pairing phase, particularly in order to group TEX instructions together (which is very important for the r300, less important for the r500)
bridgman: oh good, it all makes sense again ;)
bridgman: thanks
bridgman: I should know this, but why is it less important to group tex instructions on 3xx than 5xx ?
mjr: I have _no_ idea, but I'll guess to parallelize better on 5xx. Do I win?
nha: in r3xx you can only have 4 texture indirections, total
nha: I don't remember what the characteristics are for r5xx, but you're much less constrained
bridgman: ahh, I hadn't realized we had relaxed that
agd5f: tsamolotoff: radeon supports 3 scaling modes: center, full, and aspect. it's an xrandr output attribrute
bridgman: ok, last dumb question for a while
bridgman: I have heard mention of a "mesa IL" used to pass down things like vertex programs for fixed function tcl, but when I look in the device driver interface I only seem to see API calls for what seem to be arb_vp/fp and GLSL programs
bridgman: is the "mesa IL" the same as arb_fp/vp, or is there something else and if so where is it described ?
Zambezi: I'm using fglrx-driver again and I can't say I like them. I prefer opensource, but dualdesktop won't work with them. At least not big desktop.
adamk_: Zambezi, Using xrandr should let you have one large desktop across multiple monitors if they are both plugged into the same video card.
bridgman: slang.ir.c appears to map "something" to arb_vp opcodes, so maybe IR_CROSS is mesa IR while OPCODE_XPD is the corresponding arb_vp ?
Zambezi: adamk_: They are, but didn't work out with radeon or radeonhd last time we tried.
adamk_: Zambezi, Did you file a bug report?
Zambezi: adamk_: Xorg going insane with 15-20% playing video on one monitor and IRC and top on the other.
Zambezi: adamk_: No I didn't.
adamk_: Well, if it's been a while, you should try again with a newer version. If the problem still exists, you better open a bug report if you expect it to get fixed.
Zambezi: adamk_: It's version 1.2.1-2 of xserver-xorg-video-radeonhd. Might be fixed in newer versions.
Zambezi: adamk_: I have same card, but with AGP-slot instead of PCI-slot, but I asked earlier here and one reply it would only make it worse.
bridgman: looking at slang_emit.c (without fully understanding where it fits) it seems that IR is used internally but converted to arb_fp/vp opcodes
Zambezi: adamk_: Can you check line 14? That seems a bit odd. mplayer showing the same resolution. http://pastebin.com/df9447fd
adamk_: It seems to suggest that VGA_1 is running at 2048x1152. I take it that's not the correct resolution?
bridgman: ffvertex_prog.c sure seems to be spitting out arb_fp opcodes as well
Zambezi: adamk_: 2048x1152 on both are correct.
Zambezi: adamk_: It's 23" 16:9 monitors.
adamk_: OK.
adamk_: I'm not sure I understand the problem then..
bridgman: s/arb_fp/arb_vp/
bridgman: gets the feeling he is talking to himself ;)
adamk_: I just figured you were continuing a conversation from before I joined the channel
adamk_: Because I'm quite certain you aren't talking to me.
bridgman: I was, sort of, but the people I was talking to before seem to have gone quiet
adamk_: Heh... It's a conspiracy to make everyone else think you've gone crazy.
bridgman: it's working
bridgman: could just be a conspiracy to keep the deep dark secrets of mesa out of the wrong hands ;)
ferret_: hey, anyone have an xpress 200m card successfully working? Where working == not crashing the whole system immediately when anything tries to do 3d
Netzpython: is it r300 oder r600?
bridgman: xpress200m is a cut-down r300 core
bridgman: rv370-ish
ferret_: Yes.
mjg59: It's shit
Netzpython: so it should work quite well
ferret_: Yes.
mjg59: Netzpython: No
Netzpython: no?
mjg59: It's got a different memory controller
bridgman: ferret; I know a number of people who are playing 3d games etc.. on xpress200m, so the support is there
ferret_: I don't expect it to work well.
Netzpython: have a M22
mjg59: The main distinction is that it's IGP
ferret_: bridgman: Yep, I want to contact one of those people and ask them every facet of their configuration (versions, xorg.conf, etc.)
ferret_: Q)
Netzpython: workt great, but not that performant though ;>)
mjg59: But it's never worked properly under Linux
bridgman: ferret; try Phoronix, open source drivers forum
bridgman: mjg59; not actually disagreeing with you but people *do* have 3d working on it ;)
bridgman: although I agree it's not the Developers' Best Friend ;0
mjg59: I suspect it's very sensitive to KMS issues as well
mjg59: So, if you've got KMS on it, try turning it off
ferret_: checking...
ferret_: I already have that disabled
ferret_: Well, I think, it's kinda hard to tell
ferret_: I'll just reboot and forcibly disable it, since I can't really tell
ferret_: Well, no magic bullet there unfortunately
MostAwesomeDude: bridgman: The texture lookups are no longer statically synced on r500; instead there's a semaphore that instructions use to sync.
ferret_: I'll ask a few more times here later just in case someone has the same kind of card, otherwise I'll go register on phoronix and request all the details
MostAwesomeDude: And yes, the same prog_instruction* stuff is used for arb_vp/arb_fp and GLSL shaders.
bridgman: MostAwesomeDude; thanks
bridgman: how about emulation of fixed function tcl ? looks like that is arb_vp as well
MostAwesomeDude: The radeon_pair stuff is part of nha's code, after the nqssa-dce, used to actually assemble and emit the shaders.
nbz: ferret_: bugmenot is your friend.
nbz: ferret_: http://www.bugmenot.com/view/phoronix.com
ferret_: :P
MostAwesomeDude: I was hoping that it'd be possible to move that over. I'm really not terribly sold on that code, still, but it *does* work, and maybe I won't have to maintain it?
ferret_: FWIW, the crashes are really horrible too.
ferret_: The screen goes black, the keyboard is totally unresponsive -- even magic sysrq doesn't work(!)
bridgman: it sure seems to have all the important parts in it
MostAwesomeDude: Yeah, FF TCL is written into a vertprog; maybe ffvertex_prog.c or something around there?
ferret_: I can ssh in and kill the 3d app (which will be using 99% cpu), but then X will start using 99% cpu, and becomes unkillable, even with kill -9
bridgman: anything that explicitly recognizes >1 instruction hardware seems to be worth trying to re-use
ferret_: o.O
MostAwesomeDude: ferret_: Chill out a bit. It's just getting stuck in kernel-land. Versions of xf86-video-ati, Mesa, kernel? Are you using any driver options in xorg.conf?
sgcb: hey, i was just listening to kill dash nine! :-)
nanonyme: <3
ferret_: MostAwesomeDude: I have all these details on http://www.explodingferret.com/tmp/xorg/PROBLEMS.html
spstarr: hullo
ferret_: hmm, typo in kernel version though
bridgman: yep, definitely ffvertex_program.c, just not sufficiently familiar with all the opcodes to be sure which is which
bridgman: it sure *looks* like it's emitting arb_vp opcodes though ;)
MostAwesomeDude: It definitely is, yeah.
MostAwesomeDude: ferret_: What's up with GARTSize and FBTexPercent? Do you need them?
ferret_: I left those in after trying them because they sped things up with the only 3d apps I could get to work... but rest assured I have tried without them
ferret_: (and also with just one or the other, fwiw)
MostAwesomeDude: Hmm.
MostAwesomeDude: Offhand, not seeing anything pop out at me. :C
ferret_: So that is why my current strategy is to find someone it works for and copy pretty much everything they have set up as far as versions of things and X/kernel config is concerned
ferret_: If that works for me I can slowly work back to my existing configuration and pinpoint the exact issue
MostAwesomeDude: Eh. There's little tweaks that are required here and there probably.
MostAwesomeDude: What you *could* do, though...
ferret_: I suppose I could just read man radeon and change literally every setting away from default :D
MostAwesomeDude: Download a Mesa snapshot, build the progs/ directory. Go through progs/trivial and progs/redbook and progs/tests and progs/demos and see if anything in there causes a lockup.
ferret_: Yeah! I'll do that
MostAwesomeDude: Or do a piglit run. Or a glean run.
MostAwesomeDude: We need to find simple test cases that cause lockups.
ferret_: I agree that that would be helpful. I'll get right on it.
ferret_: It will take a while because each time it locks up I have to go to the other room and ssh in and reboot :)
mikkoc: there's a regression in xf86-video-ati: here's how a full screen video looks like (xv): http://imagebin.ca/view/yw14iex.html
mikkoc: and not full screen: http://imagebin.ca/view/1pDGhgw.html
mikkoc: ac4bd24a66c1bdda0293f770a3f891e2b88cc8ee was still working
mikkoc: d78d50591851d14543f0935d051a59ef29751bbc is broken.... i cant test further because i have compile errors
mikkoc: choosing x11 in smplayer works in full screen too... so it's only xv
nanonyme: *sigh*
mikkoc: btw, not using kms
biotube: wonders if X can be restarted without closing everything else
nanonyme: *sigh*
nanonyme: Oops, wrong window for the up arrow.
nanonyme: ->
nha: ferret_: a suggestion (in case you're not doing that already anyway) would be to start your testruns from within an ssh session as well; that way, you don't run the risk of losing too much data on lockups (and yes, I realize that's not extremely practical if the other computer is in a different room)
ferret_: :)
ferret_: Well, I've run all the demos directory, no crashes on any of them
nha: MostAwesomeDude: I had originally planned to start investigating a way to share shader compiler code between mesa and gallium this weekend. Then osiris_' changes came in between and I looked at those issues first.
ferret_: I'm about to try them again with my system mesa installation rather than the one I just compiled
nha: Mind you, that wasn't lost time, since I think osiris_' cleanups will make it easier to share code.
nha: I'm not exactly sure yet how the sharing is done best, but I'm sure there's a reasonable way to do it.
ferret_: That's interesting. the bounce demo looks totally broken with my system mesa
ferret_: Woah. I'm having all kinds of issues with these...
ferret_: Well, no crashes, but a good number of the demos didn't render correctly, and many of them had problems on window resize or move...
ferret_: Woah! The mesa from git can start some things without crashing
ferret_: :D
nha: :)
ferret_: Well, I can definitely figure things out from there, thanks nha, MostAwesomeDude and everyone else
ferret_: Yay, progress! It crashes the whole system when I exit games instead of when I start them
mcgreg: ferret_: what games?
erjc: I'm such an idiot, turns out I had the options spit over 2 sections...
erjc: Section "ServerFlags"
erjc: Option "AutoAddDevices" "False"
erjc: Option "AllowEmptyInput" "Off"
erjc: Option "XkbOptions" "terminate:ctrl_alt_bksp"
erjc: Option "DontZap" "off"
erjc: EndSection
ferret_: Hmm, good question
ferret_: Some of this stuff is 32-bit
ferret_: OK, I'm an idiot
ferret_: wine *also* loads 32-bit drivers rather than 64-bit. So all along I've been using the oldass /usr/lib32/dri/ stuff that has TCL enabled and is known to crash horribly with my card
ferret_: The only reason I wasn't getting crashes for a while was because I was setting LIBGL_DRIVERS_PATH to my compiled mesa that was 64-bit, so it was ending up in indirect rendering mode
ferret_: So in summary, I'm an idiot
aberres: when i connect my external monitor to my notebook, xrandr alsways shows me DVI-0 and HDMI-0 as output devices (i connect via hdmi and there is no dvi port without a docking station). if i do not deactivate the DVI-0 adapter explicitly the external display is not really usable. xrandr output can be found here: http://paste.debian.net/41710/
aberres: does anyone have an idea where the additional adapter comes from? and if there is a way to get rid of it?
nanonyme: ferret_: So, did you get it to work better?
dmb: Sarvatt, ok, where can I find the livecd with kms?
dmb: so i can test EXA
ferret_: nanonyme: Well, I'm currently crosscompiling git mesa :)
nanonyme: Cross-compiling? o.O
nanonyme: Why's that?
ferret_: I'm on amd64, and I need the 32-bit libraries
nanonyme: Do tell me you're using the multilib gcc instead of making a cross-compiler environment, though. ;)
ferret_: yes
nanonyme: (since both do work, making a cross-compiler is just gazillion times more hassle than installing multilib gcc on an amd64 system)
ferret_: Yeah, I'm not really aware of the difference, but I know this is a multilib one
ferret_: Since all I'm doing to make this work is making CFLAGS with -m32 in it
nanonyme: Well, mostly there are tools for making compilers for compiling code for other CPU arch's than what you're running on.
ferret_: D'oh, forgot to enable demos
nanonyme: only uses it for compiling Mipsel binaries on x86
ferret_: heh
dmb: or maybe fcami might know :P
fcami: hmmm ? :)
dmb: ah, i just answered my own question
dmb: http://sarvatt.com/downloads/xorg-edgers-0.16-i386.iso
dmb: fcami, never mind
fcami: goes back to his PIII
dmb: fcami, fast enough?
fcami: 1.4GHz with 512KB L2. yeah.
dmb: i believe the core duos were based on the p3 arch
fcami: very loosely, if any
biotube: they were, through the Pentium M
fcami: yeah, with a p4 bus, and associated tidbits
biotube: I wonder how the netburst team felt when they heard the design had been canned
fcami: biotube: their hands were so much burnt by then that they could not feel anything anymore :)
ferret_: nanonyme: 100% success :)
ferret_: No crashes, no corruption, decent performance
nanonyme: Nice nice.
dmb: Sarvatt, your livecd does not work with my card
dmb: for some reason, there is no /dev/fb0
dmb: but modesetting is turned on, because the resolution was changed
dmb: ati radeon x1400
dmb: mobility
dmb: and it detects the card fine, i can see it with dmesg
Veerappan: MostAwesomeDude: Are you aware of any compile errors in mesa/src/gallium/winsys/drm/radeon/core/radeon_r300.c:66
Veerappan: I'm getting:
Veerappan: radeon_r300.c: In function ‘radeon_r300_validate’:
Veerappan: radeon_r300.c:66: error: too many arguments to function ‘radeon_cs_space_check’
Veerappan: figured I'd check if it was a known problem, if I have something weird going on in my system, or if it's a new issue.
agd5f: aberres: file a bug https://bugs.freedesktop.org and include your xorg.conf
agd5f: and xorg log
airlied: Veerappan: yes it needs porting to a new interface
Veerappan: yeah, I figured one of the recent CS changes broke it, but didn't know if it was a known issue at the moment.
Veerappan: I figured that the non-gallium mesa driver was working well enough for me that I'd change it up and try out the gallium driver again
Veerappan: but until that's fixed, I'll just go back to figuring out what specifically is hard-locking my machine in some of my mesa tests using the non-gallium code.... gives me something to do
spstarr: hello agd5f, airlied
EruditeHermit: airlied: nice speed bump from that intel code
airlied: EruditeHermit: good, just trying to make sure it doesn't regress anything :)
airlied: I think glisse added a flush there for a reason but I can't reproduce it
EruditeHermit: airlied: there is a regression with non kms but not related to that stuff
EruditeHermit: I don't know what caused it but something in the last week or two has caused the screen to go black on non kms when running any GL app
EruditeHermit: you have to mouse click somewhere on the screen and it becomes visible again
airlied: wierd what card?
EruditeHermit: rv350 radeon mobility 9600 M10
EruditeHermit: would a screen cast be helpful?
EruditeHermit: I can try to get one
airlied: I shuold be able to reproduce it
EruditeHermit: ok
airlied: my r100 isn't doing it at the moment thouh
EruditeHermit: do you have an rv350 board?
airlied: somewhere
airlied: hopefully I can make it happen on my r300 pcie card
EruditeHermit: this is AGP btw
EruditeHermit: it doesn't happen when in kms
EruditeHermit: but with kms I have problems resuming from suspend
EruditeHermit: i.e. it never turns the backlight back on
EruditeHermit: is radeon supposed to do that or is that the distro specific scripts?
airlied: I'm not sure, its hw specific usually
airlied: but the kenrel should do it all now
EruditeHermit: hrm
EruditeHermit: well its not
EruditeHermit: brb
EruditeHermit: ok
EruditeHermit: so it goes black until you bring another window into focus
airlied: hmm sounds like a missing flush somewhere
airlied: no compositing enableD?
EruditeHermit: no compositing
DanaG: http://www.phoronix.com/scan.php?page=news_item&px=NzM3Ng
DanaG: yay.
terracon: nice amd releases register info for the SoundBlaster, w0000t
terracon: spstarr: you here?
terracon: spstarr: http://www.thestar.com/news/gta/article/659309
spstarr: looks
spstarr: not worth it
spstarr: I don't want Microsoft to succeed in any way in any market
DanaG: SouthBridge.
DanaG: s/B/b/
DanaG:
terracon: DanaG: I know I was just making a funneee
DanaG: Aren't ATI northbridges just the thingy that does PCIe, anyway?
DanaG: "the thingy" =þ
DanaG: http://www.phoronix.com/forums/showpost.php?p=81374&postcount=20
DanaG: nice.
soreau: DanaG: That is very informative and nice indeed :)
DanaG: I'm wondering if the open drivers will use shaders instead of dedicated UVD / UVD2 hardware... and if it does, will that use more power than the closed ones would use, for the same task?
DanaG: Xorg split from XFree86... does XF86 even still exist?
airlied: DanaG: all two of them
airlied: DanaG: depends on what AMD can release re UVD
airlied: and what someone writes
EruditeHermit: well the older hardware has to use shaders
EruditeHermit: since there is no UVD
DanaG: I'm speaking of R600 -- RV635, specifically.
EruditeHermit: yeah
EruditeHermit: that'll have it
EruditeHermit: UVD that is
EruditeHermit: my old hardware doesn't have it =p
DanaG: UVD1, or UVD2, in my case?
EruditeHermit: 1 i think?
DanaG: fglrx(0): UVD2 feature is available
EruditeHermit: oh
EruditeHermit: is RV635 an integrated board?
EruditeHermit: UVD2 is specifically a 4000+ feature in this
EruditeHermit: http://en.wikipedia.org/wiki/UVD#UVD.2FUVD.2B
vehemens: EruditeHermit: http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units
EruditeHermit: yeah it says UVD1
DanaG: RV635 is (Mobility) HD3650.
DanaG: ah.
vehemens: has anybody ever had a RS690 work without flicker. i have two systems (asus m2a-vm) that flicker and it drives gnome and kde nuts.
EruditeHermit: i've never seen an M98
EruditeHermit: who offers a laptop with an HD 4870 mobility
airlied: vehemens: what do you mean flicker? like output turning on/off?
DanaG: I think Asus has one, perhaps... but Asus's battery life sucks even for what their hardware should give, at least last time I checked.'
vehemens: airlied: yep. just bumped my bios up to the latest so it at least works with twm now.
airlied: vehemens: my attempt to bump my rs690 pretty much bricked it
spstarr: smiles
spstarr: another core KDE person has switched to Fedora
DanaG: Closest I've seen is 4650 in some laptops.
terracon: that's right. I'm using Fedora. ..ohhh someome core .. ahhhhhh
ssieb: vehemens: mine doesn't flicker in any way that I can tell
vehemens: i thought i had bricked one of them, but clearing cmos memory fixed it.
DanaG: HP DV6 / DV7 now have those ATI as options. 4650 -- with 1GB VRAM.
DanaG: .. well, 1GB in the latter.
vehemens: thought it might of been because of a freebsd, but fedora has the same problem.