airlied: plays hunt the r500 texture coords.
eboettcher: erm....
eboettcher: ioctl request 0x6444 does what on /dev/dri/card0? O.O
eboettcher: I can't seem to find it anywhere.
airlied: eboettcher: resets the CP I think.
airlied: if on radeon
airlied: waits for CP to idle actually.
eboettcher: oh I see :)
eboettcher: subtract 0x40 from that last byte
airlied: eboettcher: yup for driver ioctls.
eboettcher: _XSERVTransSocketRead (Xtranssock.c:2151) <-- I keep getting a crash here only while trying to debug.
eboettcher: I'm not sure what's leading up to that :/
eboettcher: it's 5am, I'll look into it later. I should sleep :P
prahal: hi is there a repository for the work on kernel modesetting ? I made my own hack at porting the X code to radeonfb though at that time I heard there was already code being worked on ... though I have not seen anything in the kernel changelogs yet (so I am wondering if it is maintained in branch ... which I could give a try to (my code works 90% of the time still it is not 100%
arrenlex: Hey, all. I found a bug in the radeon driver, as well as the commit that caused it. Where should I report it?
glisse: arrenlex: fill a bug
arrenlex: glisse: Yeah. Where is the right place?
glisse: bugs.freedesktop.org
arrenlex: thx
arrenlex: lol, firefox is freaking out about the certificate..
arrenlex: glisse: Is DRI the correct section for it?
prahal: arrenlex, I would say Driver/Radeon but I don't know the problem at stakes
arrenlex: prahal: Are we looking at the same list? http://pastebin.ca/1021987
prahal: oups yes choose product "xorg" , "Driver/Radeon" is a component of it that you can choose afterwards
prahal: as in https://bugs.freedesktop.org/show_bug.cgi?id=14980
arrenlex: prahal: Ah, I see. Thank you.
glisse: prahal: regarding your previous question modesetting is in drm git at fdo branch modesetting-101
glisse: new radeon stuff might popup at git://people.freedesktop.org/~glisse/drm branch drm-gem-ms
Zajec: glisse: some first part of work about GEM done?
prahal: thanks got them . beyond my understanding at this point sadly . Though afaict there is no bios post code yet , is there ? I wonder if this will handle my need for suspend to ram to restore properly as my hack currently does (though unreliably but I got a workaround for when it fails) ... maybe I ll have to wait till I grasp the new driver internals or the code get support for the quircks the old driver had ... or it is (forcing bios
prahal: post if model requires it) be managed internally by drm ?
glisse: prahal: no we need the ddx code
glisse: Zajec: yes few ground work for gem
Zajec: nice :) can I ask about progress in % of work that has to be done? or do you preffer to don't evalue this yet?
MostAwesomeDude: glisse: A question. Do you also have problems with VT after starting X, and will kernel modesetting fix that?
glisse: MostAwesomeDude: on my code pc i don't have X
glisse: and with kernel modesetting X is just another video mode consumer
glisse: so no more complexe or fragile vt switch
MostAwesomeDude: glisse: Sweet. Is radeon_ms testable, or is it still going to eat my children?
glisse: MostAwesomeDude: well likely only work on my cards
mattmatteh: glisse, what is kernel modesetting ?
MostAwesomeDude: glisse: Which cards are those? How hard would it be for me to add new cards?
glisse: MostAwesomeDude: r3xx agp
MostAwesomeDude: So it wouldn't really be feasible for me to add my card yet.
crow: Hi, why the radeon driver isnt recognizing ATI RS690 (x1250) for intel, i got always no device found, on x start
eboettcher: what version?
crow: eboettcher dont know, its the one that come with sidux (debian sid), and after install and working with radeonhd(default) i trayed radeon, but after install i got in X.org.log no device found
eboettcher: can you post the log?
prahal: something like http://prahal.homelinux.net/~prahal/patches/ati/radeonfb_bios_hacks.diff does the trick with radeonfb (well 90% of the time but this is a hack I made without understanding the way the card works ... it could well be a dumb mistake ... and well 10% of failure is bearable for my use case when 0% was not).
glisse: prahal: do you desactivate X when you try your code ?
glisse: or does X use fbdev ?
crow: eboettcher sorry cant post whole X.org.log but here is something ( LoadModule: ´atí ; compiled for 1.4.0.90, module version=6.8.0)
glisse: prahal: also the bios might do stuff with the card, desactivating bios might help, there is code in ddx (things that touch bios scratch register
prahal: glisse, the bios code in ddx is disabled though there is the int10 code
prahal: I run X/compiz though s2ram switch to console before suspending
glisse: prahal: i am talking about bios code executed before kernel is in charge
crow: eboettcher anything else is usifull for you... :(
glisse: prahal: well i think you better try without X
glisse: and with drm
prahal: sure ... it is less than perfect . Bad luck is I have a phoenix bios on a toshiba satellite so near to nothing I can control from there (except the date and the boot device)
glisse: prahal: any pattern when it fails ?
glisse: like X & compiz running
prahal: no :-( I am still monitoring as hard as I can but no patterns (though in spite of when I don't have this bios post code I still have control of the box, ie I can ctrl+alt+f1 then login and run s2disk and on resume everything is back to normal ... only I have to do this with a blank screen).
glisse: prahal: but does X & compiz are running when it fails (even if there is a vt switch)
prahal: and my use case does not vary much (music, vim mostly). They are running.
glisse: prahal: then if compiz is running this might be the gpu not being fully idle on vt switch
glisse: zzz time bbl
prahal: bye thanks for all
agd5f: crow: you need git master for rs600 support
bgoglin_: agd5f: about the bug report where LeftOf gives a wrong screen size (and shows strange parts of the screen on the left monitor) while RightOf works fine, is it a server or driver bug?
bgoglin_: (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481275)
agd5f: bgoglin_: I dunno. I've sen similar reports before, but I've never been able to reproduce them
bgoglin_: ok
bgoglin_: I only remember of 2 bugs like this in Debian, both are against the radeon driver
airlied: guesses some IGP crap again ;-)
airlied: hmm 100 -ati bugs in Fedora, where to start the flamethrower.
spstarr: winks
airlied: spstarr: oh have that one still to find..
spstarr: :-)
airlied: spstarr: nearly forgot.. but might be tomorrow..
airlied: no r300 hardware here.
airlied: is at home ..
spstarr: ive just avoided composite for now
bgoglin_: agd5f: I think I just reproduced it on my thinkpad t43 (mobility x300). just put VGA-0 on LeftOf LVDS. it didn't even complain that 1280x1024 + 1400x1050 was bigger than my Virtual 2048x1152
airlied: I wonder does the leftof code work properly in the server./
airlied: like from a driver pov we don't know the difference.
bgoglin_: I vote "no" :)
rzr: hi
rzr: how can i help for https://bugs.freedesktop.org/show_bug.cgi?id=12007 ?
airlied: bgoglin_: I wonder is it fixed in master...
airlied: bgoglin_: fa19e84714aa84a2f2e817e363d6440349d0b619
airlied: maybe..
bgoglin_: too lazy to try that now (2am here), maybe tomorrow :)
airlied: bgoglin_: no worries :)
bgoglin_: do you really mean master? or is 1.5-rc1 ok?
airlied: bgoglin_: hmm I'd try 1.5-rc1 first.
rzr: agd5f: around ?
bgoglin_: airlied: looks like 1.5-rc1 is ok
bgoglin_: I couldn't make it exceed my xorg.conf Virtual dimensions, and it doesn't mess the monitor dimensions when computing the offset of the Right one
bgoglin_: agd5f: did you ever try to reproduce with xserver 1.4?
airlied: bgoglin_: sounds like that comit above.
bgoglin_: right
MostAwesomeDude: Back.
airlied: MostAwesomeDude: I failed at fixing textures last night..
airlied: MostAwesomeDude: hopefully can find some time this week :-(
MostAwesomeDude: airlied: Yeah, I haven't figured it out either.
MostAwesomeDude: On the plus side, we're only a handful of ops away from arb_f_p basic support.
MostAwesomeDude: We probably can't do nv_f_p due to no hardware calc, though.
airlied: MostAwesomeDude: nice then we fix texturing and we are probably at where r300 is.
MostAwesomeDude: And glsl is way in the future, I think.
airlied: then need to think about GLSL :)
MostAwesomeDude: Well, does Mesa do GLSL?
airlied: well Intel 965 does GLSL
airlied: so we should be able to bring it up to that level
airlied: it would be nice to use the loops/branches etc.
MostAwesomeDude: Yeah. FC shouldn't be very hard.
MostAwesomeDude: I'm trying to figure out if we can do SLT/SGE without FC.
airlied: texturing can't be that broken as tri-tex works and the DDX works fine.
MostAwesomeDude: Yeah.
MostAwesomeDude: And I had unbroken texs earlier last week.
airlied: so it'll be one of those doing something stupid..
airlied: MostAwesomeDude: I think bits from the DDX leaked voer.
MostAwesomeDude: I've tried reverting various changes to emit_tex, etc. but nothing.
MostAwesomeDude: Ah.
airlied: MostAwesomeDude: I'm running without renderaccel now.
airlied: just to make sure the 3D driver is doing things correctly :)
MostAwesomeDude: Right now I'm trying to consolidate ALU stuffs.
airlied: hehe.. I'm staring at 100 bugs against Fedora ATI driver :)
MostAwesomeDude: Oh God.
MostAwesomeDude: Well, lemme know if there's any in r5xx that I can test.
airlied: hehe.. I'm going to write a random bug of the hour pickers or something I think.
airlied: something that picks a bug at random from the list, as I've no other way to figure it out
agd5f: hopefully, my ssh/gpg key stuff will be sorted out soon
MostAwesomeDude: agd5f: Bad GPG key?
agd5f: MostAwesomeDude: no idea
MostAwesomeDude: agd5f: What's your fingerprint?
agd5f: MostAwesomeDude: http://bugs.freedesktop.org/show_bug.cgi?id=15969
agd5f: airlied: BTW, the rotation corruption seems to have cropped up again on r5xx
agd5f: also, rotation now seems to be slower than SW, I haven't had a change to look into why yet
airlied: agd5f: ouch..
MostAwesomeDude: Whoo. EXA rotate locked my comp.
bridgman: are you at the point with texturing where there is a specific problem we could
bridgman: ask about, or is it just "not working, but worked once last week" ?
airlied: bridgman: its at the no idea whats going on stage ;-)
bridgman: It's hard to ask our devs "how to write a driver" but asking about very specific
bridgman: problems usually works OK
airlied: bridgman: if I had any idea where it was screwing up I'd ask ;-)
MostAwesomeDude: bridgman: It's like this: We had texs working-ish, under very specific conditions, but now they don't work.
MostAwesomeDude: And we're not sure exactly what causes them to not work.
bridgman: got it. so maybe sample code ;)
airlied: bridgman: what was happening is wew had some tex stuff working but relied on the DDX to set it up :)
MostAwesomeDude: The best thing I can say is that tri-tex does work somehow.
airlied: bridgman: so it was acceidental.
airlied: rather than by desgin..
airlied: now when I try to do it by design something is missing.
airlied: but we have textures working on the DDX..
airlied: for EXA.
bridgman: ok so it's clear that your goals need to change, try to make it *not* work
airlied: so really it can't be that hard..
airlied: bridgman: yeah my next trick was to break it on purpose.
airlied: I'm guessing rasteriser..
MostAwesomeDude: It's not FP, that's for sure.
airlied: but it could also be a register program ordering issue
bridgman: ok, but if it works on exa but not in mesa that might be enough
MostAwesomeDude: Right.
MostAwesomeDude: The tex video code is a work of art. Works perfectly.
airlied: bridgman: it may matter which way VP/RS/FP are emitted to the hardware
bridgman: so how exactly does it "not work" ?
MostAwesomeDude: bridgman: One sec, getting screenshot.
airlied: bridgman: it looks like we get giant texels..
airlied: bridgman: so we are using the wrong coords.
airlied: bridgman: we have a demo that puts the texcoords in via the color regs and uses an FP to fix it up.
airlied: and that works.
MostAwesomeDude: airlied: Really? I want to see a screenshot of that. I have something different.
airlied: the normal texture path through the rasteriser seems like failure
MostAwesomeDude: airlied: Or wait. What prog are you using that gives you that?
airlied: MostAwesomeDude: yuvsquare or yuvrect mostly.
airlied: MostAwesomeDude: but its different some times..
airlied: I actually think the problem is with texcoord scaling or some such..
airlied: but quite why r300 is working I'm not sure..
airlied: tri-tex working proves the texture upload code is all good
bridgman: makes me think something is adjustable on 500 and fixed on 300; sounds like a clue
airlied: bridgman: yeah, the UNSCALED bit in the FP was one thing I looked at.
bridgman: ok, I think that's specific enough that we can get some help
bridgman: don't suppose you have any kind of debug trace of what is being stuffed into ring/IB ?
airlied: bridgman: well I'm going to give it another look tomorrow.
airlied: bridgman: I could get one :)
bridgman: we have lots of people who know the chip but none know mesa
airlied: bridgman: my next step was fglrx comapre..
MostAwesomeDude: bridgman: One sec, I have some useful images.
MostAwesomeDude: Well, I think they're useful, at least.
bridgman: airlied: understood, it just seemed like you guys were so close...
bridgman: are so close...
airlied: bridgman: yeah I'm just torn between finishing it and !ignoring Fedora ;)
bridgman: it's a tough call, isn't it; fedora already seems to work pretty well ;)
MostAwesomeDude: yuvsquare: http://home.aweenet.net/~simpson/snapshot51.png
airlied: bridgman: tell my boss that ;-)
MostAwesomeDude: mednafen: http://home.aweenet.net/~simpson/snapshot52.png
MostAwesomeDude: airlied: At least you have a boss.
bridgman: airled: ok, might be talking to him tuesday ;)
bridgman: oh crap, I think I was supposed to do slides
bridgman: last week
airlied: hehe...
MostAwesomeDude: airlied: Does #51 match-ish your yuvsquare?
airlied: MostAwesomeDude: yup looks the same
airlied: its most likely going to be a one liner like the rs480 stuff :)
MostAwesomeDude: Probably.
MostAwesomeDude: Wait, you have RENDER and EXA disabled, right?
MostAwesomeDude: Because I have both enabled.
airlied: MostAwesomeDude: yeah it might work sometimes for you maybe.
MostAwesomeDude: Well, that's a pretty reliable result, right there. I haven't used XV at all this session.
airlied: the wierd one I had was with quad-tex-2d and debugging it sometimes got the right answer.
airlied: but that seems to have stopped now since we fixed thigns.
MostAwesomeDude: Wait a sec. On #52, the texcoords are correct, but the blending is wrong. Lemme look at that FP.
MostAwesomeDude: I think texcoords are right, primary color is wrong.
airlied: MostAwesomeDude: I think the red strip and top corner are wierd..
MostAwesomeDude: 0: TXP TEMP[0], INPUT[4], texture[0], 2D;
MostAwesomeDude: 1: MUL OUTPUT[0], TEMP[0], INPUT[1];
MostAwesomeDude: That first inst is right-on. The right coords are being sent, because the image isn't scrambled.
MostAwesomeDude: But the second one is mixing in the red-green, which should be what, materials, right? Shouldn't that be {1, 1, 1, 1}?
airlied: MostAwesomeDude: I do wonder about that garbage in the top left..
MostAwesomeDude: Well, in the original tex, that corner is completely white.
MostAwesomeDude: So it's garbage from INPUT[1], which should be primary color?
airlied: MostAwesomeDude: weirdly tri-tex uses primary color and it works :)
airlied: MostAwesomeDude: also seccolor demo is busted.. I do wonder is maybe it is missing something.
MostAwesomeDude: Oh! It's not primary! It's secondary!
MostAwesomeDude: texel * secondary color == pixel
MostAwesomeDude: First row of seccolor should be primary + secondary, but secondary == {0} so we don't see anything.
MostAwesomeDude: The black pixels in the second row are from where INPUT[1] == {0} and we have a MUL.
MostAwesomeDude: But I have no idea how to rectify this.
airlied: MostAwesomeDude: can you see the problem?
MostAwesomeDude: airlied: I believe the problem is that INPUT[1], whatever it usually contains (secondary color, I think) is not being properly set/filled.
airlied: MostAwesomeDude: damn I blame the RS :)
MostAwesomeDude: As do I.
MostAwesomeDude: :3
airlied: MostAwesomeDude: wierd..
airlied: MostAwesomeDude: run texrect and resize it small.
airlied: MostAwesomeDude: I can see a texture getting crapped on by something
MostAwesomeDude: Whoa.
airlied: MostAwesomeDude: I blame the FP ;-)
airlied: ducks and runs
MostAwesomeDude: ADD_SAT is SAT_ZERO_ONE, not SAT_PLUS_MINUS_ONE, right?
MostAwesomeDude: The hardware can't do [-1, 1], so it doesn't get saturated.
airlied: between 0 and 1.
MostAwesomeDude: Right.
MostAwesomeDude: So it's not the saturation.
MostAwesomeDude: I need to rewrite the OUT inst handling.
MostAwesomeDude: Or finish rewriting, rather.
airlied: I do wonder is some of the mask handling suspect.
MostAwesomeDude: Back in ~20.
MostAwesomeDude: I'm not worried about mask handling or swizzle munging, I already checked that.
airlied: okay cool..
MostAwesomeDude: But I need to handle OUT insts vs ALU insts better, since the masks are in different places.
airlied: MostAwesomeDude: I sorta fixed that
airlied: MostAwesomeDude: with pixel_mask and output_mask
MostAwesomeDude: airlied: Right, for single-inst ops.
airlied: but it might be done better.
airlied: oh yeah.. multi-ops ..
MostAwesomeDude: Stuff like SCS is currently hacked together. Something like emit_alu is needed.
MostAwesomeDude: But all of the insts in texrect are single-inst.
airlied: I see a buggy..
MostAwesomeDude: airlied: Should squash it. :3
airlied: the PROGRAM_OUTPUT check is wrong for tex :)
MostAwesomeDude: Ah, man!
MostAwesomeDude: Do you want me to get it?
MostAwesomeDude: Yeah, I see it. I'm fixin' it.
airlied: cool..
MostAwesomeDude: Oh, man, this one's going to be big.