nanonyme: Easter over, back to waiting for r6xx-r7xx initial Mesa. :)
Kollapse: Hi, I've got a crash while closing a HD movie with radeon driver on a x1400. Here's the log : http://kollaps117.ath.cx/pastebin/Xorg.0.log Any help would be appreciated
lirxis: Hi how do i get a bigger TV output than 800x600 on a Radeon X600 card? I am running Ubuntu 9 Jaunty
glisse: lirxis: tvoutput is not designed to driver bigger resolution
glisse: and 800x600 is already bigger than standard pal or ntsc resolution
glisse: if you are using a new lcd/plasma you want to use a proper connector like hdmi/dvi....
lirxis: glisse: i have an old widescreen 32" TV - used the ATI CAtalyst drivers before and had 1024x768 run flawless :/
lirxis: when i watch movies it becomes black on the TV - how do i fix that then?
glisse: lirxis: well on opensource driver i don't think we have modeline for anythings bigger than 800x600
lirxis: glisse: okay :/
glisse: still i don't think ntsc or pal can drive bigger res but i have never really looked deeply to this standard
lirxis: glisse: yes it worked :)
lirxis: glisse: could even have 1280x1024 but then it could only see 1024x768 a time
hifi: use 800x600, it'll even look better than 1024x768
hifi: with my old 32" TV set I used 800x600 for DVD playback, looked much sharper than 1024x768
lirxis: hifi: Okay =)
lirxis: hifi: But when i try to watch a movie in vlc it turns black on the TV - how do i fix this?
lirxis: Is it possible as in ATI Catalyst to have both TV and CRT as primary?
hifi: the output shuts down?
lirxis: No i cant see any video on the TV
lirxis: But i can see it on the CRT
hifi: so you see the window on both screens but only the one in CRT shows the actual video?
lirxis: yes
hifi: you could try to shut down the VGA output
hifi: xrandr --output VGA-0 --off
hifi: or VGA, depends, xrandr will show
adamk: lirxis, Does that only happen with vlc or does it happen with other video players?
lirxis: well then i wont see the hole screen because the TV can only show 800x600 :/
sroland: well in theory I think at least horizontally you could have pretty much any resolution you'd want. Not that it would actually separate all these pixels.
sroland: Dunno though how those drivers fit more pixels vertically while keeping same timing
lirxis: ok
sroland: are you using the overlay video adapter? If so you can try setting the XV_CRTC xvattr for choosing output
lirxis: the video shows when i am using X11 output =)
lirxis: but now i have another problem :P
lirxis: when i set fullscreen it gets fucked up on the TV - how do i make it do be fullscreen 800x600
lirxis: or how do i make second screen of the TV instead using it as a clone
sroland: well newer drivers have two different kind of xv adapters, textured video and overlay.
sroland: overlay can only be shown on one crtc at the same time (and driver chooses which one if you don't do it explicitly based on coverage), textured video shouldn't have any such problem.
agd5f: lirxis: tv-out always outputs native ntsc or pal timing. there's a scaler in the encoder that scales down from your desktop res
sroland: Though if you have a new card (r5xx or newer) then you only have textured anyway.
agd5f: only 800x600 is implemented at the moment
agd5f: lirxis: you can use the tv-out as a second head just like any other output
sroland: btw do 32" widescreen tvs not have at least vga input?
lirxis: Yes but this works perfect - i am fully happy with 800x600 now =)
lirxis: sroland - no not my :P its pretty old
lirxis: its 100 hz though
sroland: hmm ok that sucks
lirxis: :P
lirxis: agd5f: how do i do that?
agd5f: sroland: I started workon on your lated tex vid patch
agd5f: lirxis: http://wiki.debian.org/XStrikeForce/HowToRandR12
lirxis: Sorry :P
nanonyme: Nothing new on the 3D yet, I take? :)
agd5f: sroland: I got cleaned up and re-organized a bit and I got planar xv working on r1xx
sroland: agd5f: oh great. So that planar bit actually works?
agd5f: yeah
agd5f: it was a bit tricky since r1xx doesn't support normalized tex coords
agd5f: I should push my tree
sroland: I think the colorspace conversion these chips do for yuv textures is a bit different though the docs seem to indicate that
sroland: dunno though if that's really visible
agd5f: yeah, there's a bit to adjust the YUV temperture
sroland: cool or hot
agd5f: I was thinking of phasing out the built in csc conversion in favor of shader based csc on supported chips
sroland: err warm
agd5f: eventually
sroland: though cool should be reasonably close if I see that right. Of course no adjustments possible
agd5f: yup
sroland: (well close to bt.601 at least)
sroland: I can't make much sense out of why the colorspace conversions are different for HD though for no apparent reason...
lirxis: Thanks for all the help - now i got video running perfect =)
agd5f: lirxis: np
lirxis: hifi: Video was actually better on 800x600 =)
lirxis: I wish all of you to have a rellly nice day =)
agd5f: sroland: probably whatever engineers where writing the spec preferred that result better
sroland: agd5f: I doubt it really makes much of a difference since the parameters are still quite close
agd5f: I doubt most people would notice
sroland: of course the trouble is that xv doesn't allow to specify the colorspace.
sroland: since based on source material you'd probably know
agd5f: sroland: de-interlacing would be nice as well
sroland: hmm adaptive?
sroland: dunno what kind of algorithms are there?
agd5f: there's just no way to specify if content is interlaced or not as I understand it, so the video players have to deal with it IIRC
sroland: ah I misunderstood.
sroland: yes that's another problem.
sroland: for normal movie-like dvds it shouldn't be much of an issue since players will do the pulldown
sroland: so it's all progressive
sroland: I was thinking about doing some shader-based deinterlacing but it seemed ugly.
sroland: dunno what kind of algorithm you'd need plus you don't even know it's interlaced in the first place...
agd5f: exactly
sroland: though it's worth noting that for instance for tv content through DVB, you can't rely on any flags anyway. It will _always_ be flagged as interlaced even though it might really be progressive content you could extract with pulldown
sroland: I guess though that's the players problem
sroland: agd5f: btw why do normalized coords not work on r100? Does the NONPARAMETRIC bit not do what it should with npot textures?
agd5f: sroland: I don't recall. but all the xv/exa code uses non-normalized coords
agd5f: probably due to npot
sroland: agd5f: I know but I always wondered about the why :-)
agd5f: sroland: I should try it :)
sroland: I actually thought that it's because initially it was easier to use non-normalized coords. But on r200 at least I think you can only use non-normalized coords if textures are npot, for pot textures you have to use normalized.
sroland: and r300 dropped non-normalized IIRC
MostAwesomeDude: agd5f: I see lots of people desiring PowerPlay. Would it be useful for me to take your old branch and keep it rebased on my repo, or are there serious flaws with that codebase?
agd5f: MostAwesomeDude: I've already got new code written, just waiting for approval
MostAwesomeDude: agd5f: Rock.
MostAwesomeDude: I took a look at some of the planar video stuff (really really cool BTW) and I'm considering trying to consolidate the entire shader series for r3xx and r5xx, although I'm really not sure if I can do it easily. (TGSI sucks, but not as much as raw dwords.)
MostAwesomeDude: Also does anybody seriously want bicubic for r6xx?
agd5f: probably. should be pretty easy to implement, just copy the algorithm from r3xx/r5xx
MostAwesomeDude: Right.
MostAwesomeDude: At some point I need to finish r300-gallium. Not looking forward to it; most of what remains is shaders.
sroland: yeah the shader code there for textured video looks a bit ugly, got really long.
sroland: I'm proud of the r200 implementation though you can use all these nice tricks to increase precision just so slightly :-) r300 is no fun just standard boring MADs :-)
MostAwesomeDude: sroland: MAD can be fun sometimes. :3
MostAwesomeDude: I was going to just consolidate everything down into one big YUV/bicubic shader.
MostAwesomeDude: And then just use conditionals to switch parts of the shaders.
sroland: sounds good.
MostAwesomeDude: r3xx is a bit of a pain, but r5xx should be very easy.
MostAwesomeDude: r2xx can't do bicubic in one pass, so not even gonna touch it. The planar video was probably the last thing it'll see.
agd5f: MostAwesomeDude: I'll push my current tex vid branch
sroland: wait true conditionals? Not just some compile-time conditional?
MostAwesomeDude: agd5f: Alright. No rush; my current priority is finishing some work for my university on the OSWALD.
sroland: though ok on r500 that should be fine.
MostAwesomeDude: sroland: Well, probably setting r3xx CODE_END or r5xx LAST_INST on the correct instruction.
spstarr_work: good morning
MostAwesomeDude: r5xx doesn't have CODE_END so something else must be done.
sroland: Ah ok. Don't you need to adjust those output masks too? Ah I guess you can just freely overwrite previous results.
MostAwesomeDude: But yeah. Just write the pix fifo twice; once at the end of YUV and once at the end of bicubic.
MostAwesomeDude: The fifo might run faster if I mask off pixels.
MostAwesomeDude: Dunno.
sroland: I also left out gamma for r200 though it would be doable with texture lookups I guess :-)
glisse: agd5f: addr in PCIE_TX_GART_ERROR is shifted by 8 right ?
agd5f: glisse: it's bits 31:4, does say what alignment
agd5f: doesn't
agd5f: probably shifted 4
agd5f: or just 16 bit aligned
fpoibaf: MostAwesomeDude: what about renaming the r300 gallium driver to something like r300g and modify the radeon driver to add an Option "Gallium3D" to use the new driver?
fpoibaf: In this way distributions can ship both driver and let users decide which to use.
nanonyme: Kinky idea. :P
nanonyme: Which one should it default to?
MrCooper: fpoibaf: that's more complicated than necessary
nanonyme: (I'd guess Mesa)
fpoibaf: mesa is more stable now
spstarr_work: fpoibaf: its not even close to ready :p
MrCooper: fpoibaf: you can just set $LIBGL_DRIVERS_PATH to pick either for each app, without restarting X
sroland: except you wanted to use it for the xserver itself, i.e. indirect rendering.
fpoibaf: MrCooper: yes but you can't install both from the same source (e.g. distribution)
nanonyme: You can't? o.O
MrCooper: why not?
MrCooper: maybe not in a single make install run...
nanonyme: I thought you could do it in a single make install run.
nanonyme: Then again, never gotten Gallium yet to compile, might try it now.
nanonyme: Sheesh, the Mesa git is huge. :o
nanonyme: Just cloning it. :)
ajax: it's 11 years of history, so, yeah.
bobbens: just curious, is it possible to get the gpu temperature yet?
MrCooper: try cloning a Linux kernel tree...
bobbens: my GPU fan died and am running fanless, would like to monitor it a bit
nanonyme: MrCooper: The main tree? I think I'll pass. I did once do it on airlied's tree though. :)
MrCooper: shouldn't be any difference
nanonyme: I don't think it was that slow.
MrCooper: unless airlied's tree doesn't have the mainline history
Kollapse: Hi, I'm getting some strange moving stripes with the radeon driver while using compositing. Here's a video: http://kollaps117.ath.cx/player/play.php?video=1 Any help ?
MrCooper: sroland: my pipe dream is still a single XVideo adaptor which automagically switches between overlay and textured on demand :) not quite sure it's feasible though
ajax: i thought nouveau did that.
MostAwesomeDude: fpoi-- ah, he's gone.
MostAwesomeDude: Anyway, there's *no* reason to need to switch between DRI drivers. Once the Gallium pipe gets stable enough, distros can just pick which one they want to ship. Or they could ship both and use a special LIBGL_DRIVERS_PATH.
nanonyme: MostAwesomeDude: How's it going, btw?
MostAwesomeDude: nanonyme: Pretty well, actually. Since that rework I pushed last week, things on the SW TCL side have been working a bit better. No gears yet, but texturing and primitives are definitely working right.
MostAwesomeDude: I think something's still off on my indexbufs.
MostAwesomeDude: Anyway, the big thing now is to finish the HW TCL shader.
nanonyme: *yawn*
nanonyme: Hmm...
nanonyme: So the new r6xx-r7xx 3D code will get to radeon-rewrite branch...
nanonyme: I guess I'll start keeping an eye on it then.
nanonyme: Hmm, it's getting one week in two days since bridgman said the initial code will likely be out in a week. ;)
nanonyme: (Might be, whatever)
MostAwesomeDude: nanonyme: Why would the r6xx code be on radeon-rewrite?
MostAwesomeDude: I would wager that the AMD guys are not working on radeon-rewrite, so their work will probably have to start out in an r600-r700 branch or some such.
nanonyme: Ahrm. I read it a bit inaccurately.
nanonyme: "We hope to push the current 6xx/7xx code out into a mesa branch next week and then start merging chunks of code from *that* branch into *another* branch based on radeon-rewrite (since radeon-rewrite will become the standard mesa implementation for ATI/AMD graphics soon)."
nanonyme: MostAwesomeDude: Now that I read it again, sounds more like the code will get ported to be compliant with radeon-rewrite branch. :)
MostAwesomeDude: nanonyme: Yep.
nanonyme: MostAwesomeDude: Still, hoping the initial code will be out soon. :)
spstarr_work: MostAwesomeDude: will it be easy to take the r6xx-r7xx code from the DRI2 driver and put into a Gallium one?
MostAwesomeDude: spstarr_work: We'll see.
nanonyme: spstarr_work: I would be thrilled to even see the initial 3D in classic Mesa. ;)
lirxis: Hi again =) Have a question for u all. How do i reduce the noise when running TV OUT with xrandr
agd5f: lirxis: you mean noise in white parts of the screen? that's fixed in git. 6.12.2 should have the fix as well
agd5f: sroland, MostAwesomeDude: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=tex_vid2
agd5f: I also implemented Xv attributes for r6xx/r7xx
lirxis: agd5f: Well its flickering/noise most appeared in text - can i reduce this?
agd5f: lirxis: what version of hte driver are you using?
agd5f: if it's older than 6.12.2 try upgrading
lirxis: how do i check version?
agd5f: check your xorg log
agd5f: or your distro package manager
lirxis: 6.12.1
lirxis: where do i get a upgrade for ubuntu =)
lirxis: or do i have to compile
agd5f: lirxis: I think they have experimental packages
agd5f: lirxis: https://wiki.edubuntu.org/XorgOnTheEdge
lirxis: found an debian package :) will try it now
spstarr: hmmm
osiris__: glisse: I've seen some gpu reset patches in drm-next. what errors it can recover from?
spstarr: ugh
spstarr: did something break in X?
spstarr: EXA is doggedly slow doing yum update...
airlied: spstarr: latest rawhide? maybe agpmode defaults
spstarr: latest as of last night
spstarr: airlied: i force AGP to 4x in anycase
spstarr: oh my lots of packages
osiris__: agd5f: if OVM locations for SW TCL are: 0 position, 2-5 colors, 6-14 texcoods, 15 point size what can we put in vector 1? edge flag?
spstarr: Xorg 1.6.0 -20
spstarr: [ 42.156926] pci 0000:01:00.0: putting AGP V2 device into 4x mode
spstarr: still working in 4x just EXA is beh
spstarr: checks changelog of X
spstarr: - Obsolete a bunch of input drivers. (#493221)
spstarr: hmm
spstarr: nothing changed in X
spstarr: pulls new kernel in
spstarr: airlied: how goes the T42? or focusing on other stuff (RH stuff?)
airlied: spstarr: well it seems to work fine in agp mode 1 :(
airlied: spstarr: but I still see a small corruption
spstarr: ew
airlied: so I'm doing some test kernels to narrow it down
airlied: but it takes a while
spstarr: you have any hunch to what you think it might be?
airlied: AGP.
airlied: or at least copying back from the card to RAM
airlied: suspend/resume really shows it up a lot
glisse: osiris__: so far for me it always succeed to reset the gpu what ever the lockup is
glisse: but it's useless because rendering is trowed away
glisse: so userspace keep locking up the gpu and kernel keep reseting it
airlied: nice.
glisse: thought you can stop userspace and unload/reload kernel module just fine
airlied: glisse: any idea why userspace locks it up?
glisse: airlied: well my x1900 lockup isn't that nice, i reset the gpu every 500ms :)
airlied: or are you locking it up on purpose/
glisse: and the card is setup exactly like in rawhide
airlied: so it doesn't lockup on rawhide kernel?
glisse: oh i tried locking up on purpose just to exercise reset path
glisse: no doesn't on rawhide
glisse: my guess is that cs translation is wrong
glisse: or somethings to do with how things are queue on the ring
airlied: you got all the ring padding stuff?
glisse: btw talking about ib it seems that ptr i give in data field of debugfs are corrupted somewhere along the way ?
glisse: i think i have all the padding but i might have disabled that along way will add this to my check list :)
airlied: like bad data or oops?
glisse: well bad ptr
glisse: so i can't use it :)
osiris__: glisse: hmm, can't we just return some drm error to the app caused the lock?
glisse: osiris__: my plan is to add something to get_info ioctl and make ddx call that once in while
glisse: and if lockup is detected ddx will disable faulty accel path
airlied: apple/ms pretty much reboot cardunderneath sw rendering
airlied: and then turn hw rendering back on
glisse: airlied: well my reset do that :)
glisse: on rv515 it works
glisse: i tried locking up and then kernel reseted and rendering resumed
MostAwesomeDude: glisse++
glisse: need to be tested on r3xx/r4xx
glisse: and of course i could be very lucky with my gpu
glisse: and it might only works for me
glisse: i am now very skeptical any times somethings related to gpu resuming seems to work :)
dmb: pats glisse on the back
osiris__: glisse: hmm, I don't like the idea. I think it's not ddx resposibility to check if GPU is locked
spstarr: airlied: ugh AGP...
spstarr: glisse: oh thats what your GPU reset code is? it will kick the GPU so we dont get wedges?
glisse: osiris__: well thing is here ddx will keep sending rendering command which trigger lockup
spstarr: nice work glisse :)
glisse: osiris__: i can kill X but that's not nice, best option in my pov is to make ddx disable the code path which trigger lockup and fallback to sw
glisse: so user can investigate and still have a working desktop
glisse: sounds better to have a slow desktop than to have all apps killed
osiris__: glisse: I think we don't need new ioctl for that, just return an error and add a check in ddx and fallback then
glisse: osiris__: most of the time lockup will happen long time after kernel returned to userspace
osiris__: glisse: yes, but that's not a problem
osiris__: glisse: the userspace will try to send new commands then, so we check if it is the same process that send the commands that caused the lockup - if yes then return error
glisse: osiris__: we don't keep track of who is causing lockup
glisse: and it's not somethings we want to do
glisse: but we could do somethigns similar when ddx call wait_rendering
glisse: anyway what is the best option can be decided latter on
glisse: zzzZZZzzz
agd5f: osiris__: vector 1 is point size IIRC
MostAwesomeDude: agd5f, osiris__: In r300-gallium, surface_fill uses pos 1 for point size and it appears to work.
MostAwesomeDude: I can try pos 15, but I find it hard to believe that it didn't work before in the r300 clear code...
osiris__: MostAwesomeDude: hw tcl card?
MostAwesomeDude: osiris__: Yes, but it happens with RADEON_NO_TCL too. Why?
MostAwesomeDude: Oh, no, wait.
MostAwesomeDude: Nevermind, I'm being stupid.
MostAwesomeDude: surface
MostAwesomeDude: surface_fill uses pos 0 and pos 2, and uses GA to setup point size. Sorry.
MostAwesomeDude: So I could see pos 15 being correct.
osiris__: agd5f: it certainly isn't for non tcl hw
MostAwesomeDude: osiris__: How did you find pos 15? fglrx?
osiris__: MostAwesomeDude: nope, some luck and deduction
MostAwesomeDude: osiris__: Hm. And it works with pointblast, etc.?
osiris__: MostAwesomeDude: yes
MostAwesomeDude: osiris__: Then I'll try it out when I get home.
osiris__: glisse: to keep track of who caused a lockup it's enough to just remember the process id that sent the last command
airlied: osiris__: we queue commands
airlied: osiris__: so you can have lots of IBs in the ring queued
osiris__: airlied: if the command processing is finished we know that the gpu didn't lock up, right?
agd5f: well, we could get a clue from the last scratch timestamp
airlied: osiris__: we'd have to keep which file_priv sent each IB
airlied: and notice which one locked up.
MostAwesomeDude: Could use a pkt3 nop to stamp the ring with a serial.
airlied: well we alredy have timestampe
airlied: it just the file_priv we don't track
MostAwesomeDude: Alternatively, we could ask userspace to do the stamp, and then have kernel dump the stamp for us if it's bad.
osiris__: IMHO that solution would be universal. every app that caused the lockup would just get killed with drmCmdRadeonBuffer(-22) or something like that
airlied: osiris__: killing X isn't right :)
MostAwesomeDude: Well, it might feel right, but it's the wrong thing. :3
osiris__: airlied: yes, the ddx would check if command submission succeed. if failed fallback to sw
osiris__: could this solution work or am I missing something?
airlied: yup if you kept track it would probably work okay
b0le: airlied: with the latest commit to radeon-gem-cs3 ("cache mmaps" a322a475ed97d0ee212ea136b0387f49e1103026), X doesn't start - Xorg.0.log is here: http://pastebin.ca/1392392
airlied: b0le: can you try with the code I just pushed
airlied: b0le: though that patch may have had other issues :(
b0le: airlied: it is still failing with same errors
airlied: b0le: oops
airlied: b0le: try now
b0le: airlied: yep, that fixed it. X starts now (though starting compiz kills X, though this happened before those commits as well)
b0le: airlied: sorry about that, those commits fixed compiz as well
airlied: rotation works again.
b0le: airlied: glxgears and trivial/clear are not working correctly: http://picpaste.com/2009-04-15-105308_1440x900_scrot.png (and if I move it is will start rendering part of the terminals)
b0le: also, spamming unhandled buvfer attach event, attachment type 7
airlied: clear -db work any better?
b0le: minus typos
b0le: no
airlied: is that master X server?
b0le: yes
airlied: I'm not seeing that here.
b0le: it works with dri1 and no kms, but not with kms and dri2.
airlied: rebases maybe glisse commits