b0le: MrCooper: this: http://pastebin.org/21253 fixes the kernel panic (and everything works fine now)
MrCooper: b0le: that's close, but not quite correct - use __glX{enter,leave}Server(GL_FALSE)
b0le: ok, I figured I needed something else (but at least it is working for now :D)
b0le: MrCooper: will you fix it in master? or do I need to make a patch and put it on bugzilla, or ML?
MrCooper: b0le: I'll push the fix
b0le: MrCooper: thank you
MrCooper: np, thanks for tracking down the problem
MrCooper: can you remind me of the bug URL?
b0le: Couldn't do it without you telling me where it was :)
b0le: https://bugs.freedesktop.org/show_bug.cgi?id=14518
b0le: BTW, the bug with pixman has been fixed as well
MrCooper: cool
agd5f: airlied, dli: r3xx+ still has clipping issues and we can definitely improve performance. currently we idle in every call to putimage(), using host data blits should help alleviate that and improve performance
glisse: agd5f: got a question about dma
glisse: agd5f: actualy for ttm i am using blit cmd to move memory ain't it better to use the DMA stuff ?
MrCooper: glisse: you mean the DMA_{GUI,VID}_* stuff?
glisse: MrCooper: yup
glisse: MrCooper: i wasn't aware of this stuff previously :)
MrCooper: what would be the advantage?
glisse: MrCooper: well having one path where i don't need to have cp running to move memory this way i can simplify a bit this initialization of ttm things and just not care about having cp running
glisse: so i am wondering if there is anydrawback especialy when cp running and when touching this register
agd5f: glisse: probably about the same, although I've not tested
agd5f: glisse: the CP actually just programs registers
agd5f: it parse the packets and tehm programs the register backbone directly
agd5f: s/tehm/then/
MrCooper: I guess it might be possible to get some parallelism between DMA transfers and rendering operations, but synchronizing them might be tricky
glisse: MrCooper: wouldn't they share the bandwidth ?
MrCooper: sure, but at least on beefier cards the local memory bandwidth may allow squeezing in host transfers
MrCooper: what's one GB/s more or less when you have >100 overall ;)
glisse: :)
osiris_: airlied: ping
osiris_: looks like we don't initialize some reg(s) for textured video on rs690, because to make it work I need to run an 3d app first (and then it works even after X restart, and soft reboot). without it I get some green partially flickering window instead of the video
osiris_: agd5f: any ideas?
agd5f: osiris_: not sure. does my latest commit help?
osiris_: agd5f: just compiling
osiris_: agd5f: no luck
agd5f: osiris_: probably have dump some regs. take a look at what regs the 3D driver touches vs. what the Xv code touches.
osiris_: agd5f: radeondump hard locks machine
agd5f: osiris_: you might try the avivo branch of radeontool
agd5f: either way you'll have to modify the tools to dump the 3D regs
rx__: eh.. wouldn't 3d touch a lot of regs..
rx__: i guess that's not a concern since docs are available now :)
pzad: agd5f: will you fix clipping and pitch register setting in textured video too ?
agd5f: pzad: I'll take a look
pzad: I had send patch to xorg-driver-ati
agd5f: pzad: I don't remember seeing it, got a link?
pzad: http://lists.x.org/archives/xorg-driver-ati/2008-February/004348.html
pzad: two errors are fixed by your last commit
pzad: two more stays
agd5f: pzad: looks good
agd5f: pzad: my spam filter must have caught it
bgoglin: yeah, clipping fixed
GhePeU: agd5f, just upgraded to git. My problem with textured video (edge pixels with strange colors) is fixed.
GhePeU: There's still a moderate tearing in certain cases, but if I understand correctly that's not a textured video's, nor radeon driver's, problem
agd5f: GhePeU: correct
peterz: agd5f: quick question: can the r600 use less power with a better driver? - that is, its getting quite hot, even without using the 3d engine
agd5f: peterz: yeah
peterz: agd5f: great, I'll patiently wait for 'better' to appear
agd5f: peterz: :)
Magnade: peterz: what card do you have?
peterz: Club3D HD-2600-Pro Passive 512MB
Magnade: i thought all 2600s had fans
aneas: i have a mobility x1700 (M66) in my laptop and two displays, 1280x800 panel and 1680x1050 DVI (note the different resolutions). is there any chance i could setup -ati correctly to use them as a single screen with xinerama info? and is there anything i could test to help you?
aneas: jennifer lopez has fans too, but she's still hot
peterz: Magnade: http://www.hardware.info/en-US/productdb/bGRkZpiamJLK/viewproduct/Club_3D_Radeon_HD_2600_Pro_Passive_Cooling/
Magnade: nice
Magnade: seems to be a few out there now that im looking closer
Magnade: (been looking at the hd 3470)
peterz: Magnade: ah nice, those seem to have better power saving features
GhePeU: wtf. how much does that card weigh?
peterz: GhePeU: surprisingly little
GhePeU: can you use the next slot?
peterz: nope
Magnade: peterz: yeah thats why i was looking at it
Magnade: support wise atm tho i think ill end up with a x700
peterz: I couldn't find a passive x700 with dual dvi :-/
Magnade: well it might help that i wont be looking for dual dvi
peterz: yeah, that does help
peterz: but I was really bothered by the artifacts from the dsub driven monitor
Magnade: dsub is nasty anyways if you have a dvi monitor anyways
Magnade: what resolution?
peterz: 1920x1200 :-)
Magnade: to far for analog
Magnade: i think highest i saw usable was 1600xsomethin
peterz: I've done 2048x1536 on my 22" iiyama using a matrox g400
Magnade: card makes all the difference?
peterz: back then, hell yeah
peterz: some cards had real real bad ramdacs
GhePeU: a question about textured video: the xv overlay supports setting a different gamma from the one used by the x server (with xvattr)
GhePeU: will textured video support it as well?
airlied: GhePeU: in theory I think you can provide stuff as inputs to the fragment program..
airlied: GhePeU: but we haven't looked at it at all yet
GhePeU: well, that's not really important
GhePeU: I just noticed that textured video does use the x server gamma
GhePeU: my problem was mostly that xv used 1.0 unless you set explictly a different gamma value
GhePeU: but since I used to set the same value for both xv and server...
agd5f: GhePeU: since the textured video ends up in the framebuffer, the regular crtc LUTs will affect it
agd5f: GhePeU: for overlay it has separate gamma controls since it's mixed during scan out
agd5f: egore: when you commit someone else's patch you should use --author
egore: agd5f, ah. didn't know about that. which command to pass it to? git commit?
agd5f: egore: yup
agd5f: git commit --author "job coder
egore: agd5f, ah, ok. didn't know that. will definitely use that next time
agd5f: egore: no worries :)
egore: agd5f, at least I noted him in the comment :-)
dli: interesting xv now, video starts from [1/4, 3/4] shifts to [1/2,1], with [0,1/2] static
dli: a math error?
agd5f: dli: got a screenshot? also, what's the latest commit you are using?
dli: agd5f, minutes ago, happens when left edge blocked
dli: agd5f, do you have a test video for testing
dli: video is normal if the right edge blocked
agd5f: dli: ah, ok, I'm seeing it too
dli: agd5f, I suppose it's a single line fix
dli: srcPitch = (width + 3) & ~3;
dli: srcPitch2 = ((width >> 1) + 3) & ~3;
AndrewR: hi all. Latest commit for ati driver ( RADEON: Convert textured video to use pipelined uploads) broke textured video for rv280
plectrum: hi, I'm experimenting with a new kernel and I turned on radeonfb. Tunrs out when radeonfb is on I get graphics errors in X with radeon driver. Is this a known bug?
agd5f: plectrum: generally mixing radeonfb and radeon doesn't work
plectrum: good so it is known bad behaviour. Alright since I am on this line, where would kernel mode switching happen in radeonfb for in the drm driver?
agd5f: AndrewR: broke how?
AndrewR: agd5f, i see only moving colour lines in video window ... i think i can make screenshot now
agd5f: AndrewR: what format? packed or planar?
AndrewR: agd5f, http://rafb.net/p/krYbJK86.html (mplayer's output)
AndrewR: i must restart X with 'bad' driver (for screenshoot)
loswillios: plectrum: probably try uvesafb
AndrewR: http://img84.imageshack.us/my.php?image=rv280brokentextvideobe9.jpg
plectrum: loswillios: yep it works with vesafb without any artefacts
loswillios: uvesafb or vesafb?
plectrum: oh I figured uvesafb was a typo, I am using vesafb
loswillios: uvesafb is available since 2.6.24
PSYCHO___: loswillios: trully uvesafb is there much longer, it was in genpatches since .20 or 21 iirc
PSYCHO___: oh
PSYCHO___: since 23 only
plectrum: I see it now in the kernel code, but what is the benefit to having it uvesafb being in userspace? (desire to move to a micro-kernel world?)
loswillios: better debugging? :)
PSYCHO___: much better
AndrewR: agd5f, -vf scale=704:-2 fixed my bug ... strange ...
agd5f: AndrewR: what does that option do?
AndrewR: agd5f, scaling ...
AndrewR: agd5f, i'm testing different videos right now ...
AndrewR: agd5f, for example some small or odd sized videos have problems... (http://rafb.net/p/qVY8bh63.html - mplayer output from 240:180 sized video)
agd5f: AndrewR: do you have any small videos that exhibit that problem that you could send me?
Magnade: mplayer should be able to scale it down to any size
Magnade: or crop
AndrewR: agd5f, yes ...92K MOV00008.3gp How can send it to you?
agd5f: AndrewR: alexdeucher at gmail dot com
AndrewR: agd5f, should be in your inbox (subject - video (176x144))
agd5f: AndrewR: got it, thanks!
AndrewR: agd5f, small table about few different resolutions http://rafb.net/p/kxRRZK66.html
AndrewR: agd5f, should i test them all?
agd5f: AndrewR: what are these?
AndrewR: agd5f, i just run mplayer with different scaling VO line probably show actual size (as source for xv). For some sizes it works good. some others - display only colour lines
AndrewR: agd5f, as in bug http://bugs.freedesktop.org/show_bug.cgi?id=14673
agd5f: AndrewR: ok. that should be enough
agd5f: it's probably an alignment issue
agd5f: although scaling shouldn't affect the upload
agd5f: I'll have to pop in my r200 in a bit and test
Magnade: doesnt mplayer when scaling do it in software?
AndrewR: Magnade, mplayer can scale in software (-vf scale) and in hardware (-vo gl, gl2, xv, xvidix). At the same time ....
GhePeU: agd5f, if you're still working on the bug introduced with commit a2dca1d68d751def34ef3c6f836574173737bf76 (corruption similar to the screenshot in bug 14673), the problem is the horiziontal size
GhePeU: I tested ~100 videos, the broken one are the non-multiple of 32
agd5f: GhePeU: cool thanks
agd5f: still working on other stuff ATM
GhePeU: for example 624 (32*19.5), 592 (18.5*32), 688, 656, etc.
GhePeU: no problem. there's another thing: without a compositing manager the video "shift" to the right when the right edge is fully covered. I suppose that you noticed, however just in case...
GhePeU: sorry, the *left* edge
GhePeU: good night... (almost 4 am here)
agd5f: yeah, that's what I'm trying to sort out now
tillin9: Hey I keep getting errors with improperly matching dri versions.
tillin9: i.e. libGL error: __driCreateNewScreen_20070105 not defined
tillin9: Anybody here know which Xorg is new enough to use the new dri API?
tillin9: Also, when I'm using compiz I get some odd minor artifacts: see http://sknauert.web.wesleyan.edu/artifacts.png
tillin9: Hm... if I use a newer MESA module I get (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/r300_dri.so: undefined symbol: __driCreateNewScreen_20050727)
tillin9: (EE) AIGLX: reverting to software rendering
tillin9: My guess is that the AIGLX code needs to be moved to the new API.
tillin9: Using the newer module makes compiz not possible.
tillin9: Using the older MESA module means slightly slower 3D.
Magnade: maybe the lib that has aiglx needs to be recompiled against the newer mesa to work
tillin9: Any idea on where the AIGLX lib lives?
Magnade: none
Magnade: hopefully someone that does know is awake :)
tillin9: I know its somewhere in X.org, but I want to avoid recompiling the whole tree is I can avoid it. :)