airlied: man I wish
taiu: so how does one invalidate hdp?
taiu: I want to try if it might fix my rv740 downloadfromscreen
agd5f: taiu: see R600PrepareAccess/R600FinishAccess in r600_exa.c in the ddx
taiu: yes! that seems better
taiu: no more checkerboard
agd5f: taiu: cool
taiu: also kde displays normally now
agd5f: taiu: excellent. what was it?
taiu: I stuck it in Downloadfromscreen before memcopy from scratch
taiu: in DRI1 mode - that has always displayed checkerboard for me - e.g xmag or screenshot or kde - every other 8x8 square was garbage
taiu: I begun to think that some pipe programming was wrong for my chip
taiu: or sometimes some other pattern 16x8 or so
taiu: Now i'm thinking it something like this might fix my other problem - when I use much vram - for example set textures to 'high' in nexuiz
taiu: it will garble the screen and other X pixmaps in somewhat similar pattern
taiu: looks like draws garbage in vertical stripes
agd5f: taiu: the drm should probably flush the hdp cache after rendering
agd5f: MostAwesomeDude: host data path
MostAwesomeDude: DMA object?
MostAwesomeDude: has not yet internalized r600 docs
agd5f: MostAwesomeDude: all radeons
taiu: I'll try to put it in drm blit path also, but probably tomorrow...
agd5f: MostAwesomeDude: cpu access to the gpu aperture goes through the hdp
MostAwesomeDude: agd5f: Oh, so it's DRM-land.
agd5f: MostAwesomeDude: not really
MostAwesomeDude: agd5f: Well, I mean, it's not something I mess with in r300g. I kind of assumed that that would be managed by the TTM stuff.
agd5f: MostAwesomeDude: yeah. should be handled in the drm
agd5f: or ddx for ums
taiu: tries to enable small transfers for rv740 also now
MrCooper: HDP shouldn't affect CPU reads from GART memory though, should it?
agd5f: MrCooper: doesn't seem like it should
taiu: seems to work also :)
agd5f: MrCooper: unless it triggers some internal dst cache flushes
taiu: well, maybe some other method then - maybe should read a byte from framebuffer
agd5f: taiu: didn't seem to work last time I tried
MostAwesomeDude: Ah, the nha fix.
airlied: agd5f: what taiu reported is sounds like one of my r7xx that dies on resume
airlied: checkboard with some parts render correct and some garbage
agd5f: sounds pipe related
agd5f: does it s/r without accel?
airlied: its dri2/kms so I didn't try
airlied: it could be a pipe reprogram on resume alright
Zugschlus: how do I find out whether firmware is installed?
glisse: airlied: shouldn't we cose the t60 bugs ? also did you have a chance to push my lastest patches to f12 kernel ?
glisse: Zugschlus: ls /lib/firmware
Zugschlus: glisse: e100, bnx2, tigon, ipw2200
Zugschlus: glisse: will X complain if firmware is not found, or will it just silently crash?
Zugschlus: (ATI Technologies Inc RV350 [Mobility Radeon 9600 M10])
Zugschlus: I have enabled KDE 4 desktop effects, and since then I cannot log in any more since the X server crashes before the desktop is ready and throws me back to the login manager
Zugschlus: log is inconclusive
Zugschlus: and after this crash, the display is somehow depolarized, I cannot switch back to the text console then
glisse: Zugschlus: kms ?
Zugschlus: glisse: not that I am aware of. How do I find out whether KMS is used?
MrCooper: Zugschlus: http://bugs.freedesktop.org/show_bug.cgi?id=24131 maybe? Check the X server stderr output
soreau: Zugschlus: Here on gentoo, it's in /lib/firmware/radeon/ and kernel configured with FIRMWARE_IN_KERNEL
Zugschlus: MrCooper: kdm.log doesn't show the "legacy_is_pending" message
glisse: and it's unlikely to lead to crash
Zugschlus: the bug description seems to fit though
MrCooper: are you looking at the log from the crashed session?
Zugschlus: MrCooper: I think so
Zugschlus: MrCooper: kdm.log doesn't roll over with new sessions, and the log doesn't have the word "legacy" at all. The Xorg.log files don't even indicate that there was a crash, they just stop
MrCooper: the latter is indeed what happens on an assertion failure
MrCooper: as the X server doesn't catch SIGABRT
Zugschlus: As the freedesktop #24131 indicates that enabling KMS might help, how do I find out whether KMS is actually used?
MrCooper: Zugschlus: maybe there's another assertion failure or unresolved symbol or so
Zugschlus: MrCooper: I would see that in kdm.log, right?
Zugschlus: nothing like that in kdm.log
Zugschlus: do I need to set modeset=1 or radeon.modeset=1 on the kernel command line?
soreau: Zugschlus: If the kernel was configured with kms off by default then you would need radeon.modeset=1
Zugschlus: and how do I find out wiether kms is active?
soreau: X log should tell you
Zugschlus: $ grep -i kms /var/log/Xorg.0.log | wc -l
soreau: Seems it isn't enabled
Zugschlus: does the kernel already support radeon kms? the only KMS option I find in the kernel config is CONFIG_DRM_I915_KMS
twnqx: Zugschlus? the one from ircnet?
Zugschlus: twnqx: the only one i know
soreau: Zugschlus: Latest kernels should have kms
Zugschlus: Linux swivel 188.8.131.52-zgws1 #1 SMP PREEMPT Thu Oct 29 19:34:03 CET 2009 i686 GNU/Linux
soreau: twnqx: From ircnet?
twnqx: no worries :P
Zugschlus: not late enough?
twnqx: 2.6.32rc +
soreau: Zugschlus: To be sure, use drm-next
twnqx: 2.6.31.y needs drm-next :P
Zugschlus: soreau: how do I do that
twnqx: there's a link inthe topic :P
soreau: Zugschlus: wiki link in the /topic here
Zugschlus: so that would mean to build my on X?
twnqx: at least mesa, ddx (driver) and kernel
twnqx: you'll need xorg 1.7 though, iirc
soreau: If you have X 1.6.x, it should be fine
twnqx: yes? ok
soreau: Just need libdrm, mesa and ddx configured with kms support
Zugschlus: I see
Zugschlus: so this is where it ends for me
soreau: Zugschlus: This is only the beginning ;)
Zugschlus: drops Option "Composite" "Disable" into xorg.conf
soreau: drops Zugschlus on the head
twnqx: hey, it only took 3 or 4 days of compiling and putting pieces together until it worked for me :P
Zugschlus: I don't have time to build half of my system manually
soreau: Zugschlus: I meant this is only the beginning in the sense that by time next distro release cycle comes around, distros should have preliminary support at least
soreau: ubuntu 9.10 already has kms support offered for <=r5xx chips
Zugschlus: i don't care about releases, I'm on unstable anyway ;KI)
Zugschlus: at least on my desktops
soreau: (un)stable means nothing
Zugschlus: soreau: on debian it means that you always have the latest packaged version
Zugschlus: so there are no updates in "release cycles"
Zugschlus: but the Debian X team is kind of understaffed
soreau: I can't stand debian with it's concept of stable/unstable
soreau: They really mislead a lot of people
soreau: debian == old.
Zugschlus: is not going to engage in advocacy
Zugschlus: .oO( must. resist. )
soreau: I always tell debian users to wait at least 2-3 years for what is working now
soreau: because they want to hold some 'stable' title
Zugschlus: ok, now I cannot resist any more. Kindly stop giving misadvice to newbies.
soreau: debian sucks, what can I say?
twnqx: debian doesn't even offer live build :X
twnqx: and that's what you want!
twnqx: too bad i know him from another place :P
soreau: I don't want to be intentionally mean, but i am so sick of debian users concept of stable/unstable
twnqx: but what can you do, the code is so hot... it works on my laptop since the release about a week ago
soreau: They think that title means everything
twnqx: well, "release"
twnqx: snapshot maybe :P
soreau: Radeon code works awesomely so far
twnqx: is on rv635
soreau: and as I see it, will only get better
soreau: uses a lowly rv350
twnqx: yeah, that's working for somewhat longer
airlied: glisse: F12 kernel I built today has whats in drm-radeon-testing
airlied: glisse: generally we close em when we push to stable
Kaapa: airlied: is drm-next in the latest rc already?
Kaapa: (I'm having that bug that crashes X after a few seconds of use when kms is enabled)
twnqx: partially, but it's ongoing develeopment
airlied: Kaapa: linus merged a lot of it, but I've queued up more
Kaapa: I assume it's safer to wait for a final .32 then?
airlied: it should be safe now, its mostly specific fixes for F12 bugs at this point
Kaapa: I'm pretty happy with how it's working; apart from suspension everything works
airlied: glisse: did I miss any patches in that?
airlied: Kaapa: suspend to ram or disk?
twnqx: why would F12 have different bugs from the rest of the world?
Kaapa: airlied: hibernate works, suspension (to ram) doesn't resume nicely
airlied: twnqx: I meant specific to certain gpus or laptops
Kaapa: airlied: with kms enabled everything works
airlied: Kaapa: what gpu?
twnqx: ah. well, it works here, as long as compiled as module - didn't resume last i tried with static linking
Kaapa: airlied: M76 [Radeon Mobility HD 2600 Series]
airlied: Kaapa: AGP?
Kaapa: airlied: hum, it's a laptop, I don't think so
Kaapa: hardware has never been my strong point
airlied: yeah unlikely in a laptop
airlied: Kaapa: what does it do on resume?
airlied: resume from console okay?
Kaapa: no, not even from console
Kaapa: just stays blank, as if it didn't power up
soreau: Would it be a good idea to update the wiki to give instructions for drm-radeon-testing yet? It already stands to be updated to pull drm-next on top of linus-tree..
Kaapa: I see disk activity but can't connect to the laptop
airlied: Kaapa: non-kms resume okay?
Kaapa: airlied: hum?
airlied: soreau: yeah I should update that, I'm just lazy, and the tree to test changes
airlied: Kaapa: resume with nomodeset?
Kaapa: airlied: no, with kms everything works!
Kaapa: with nomodeset, no resume for me
glisse: airlied: i don't see agd5f lvds patches, or my rs480 disable tv detect patch, or my vga ddc probe patches
soreau: airlied: idk if I am able to update it, but if I had instructions to use drm-radeon-testing, I could..
airlied: glisse: wherea re you looking?
glisse: ok wrong branch, it's only missing the vga ddcprobe patches
twnqx: airlied: are you maintaining all of drm-next? i have a conflict with 2.6.31.y and the i915 drm module..
airlied: twnqx: thats normal just how git works
airlied: its nothing to do with me
twnqx: just wondering
soreau: twnqx: You need to use linus-tree
twnqx: apparently my last attempt at resolving the conflict broke the source .P
twnqx: i'm just using what's iin the wiki from the topic :P
soreau: was able to resolve it with the help of rnoland ihrc
airlied: glisse: I'll add vga ddc tomorrow
airlied: ask for testers on the bugs to use koji kernel I suppose
twnqx: also, will we have support for switching video chips any time soon? i have one of those laptops with intel + radeon
airlied: or maybe I can add it to updates-testing
glisse: btw i will redo ttm patch to move kfree outof spinlock even thought i think it's safe
glisse: the other ttm cleanup patch should be fine
glisse: it's deleting dead code
airlied: twnqx: not likely, unless someone writes it
airlied: glisse: kfree is fine
glisse: ok then patch is good :)
glisse: i have other ttm patch under way and they apply on top of the previous one
airlied: glisse: you shold write ttm defrag while you are there ;-P
glisse: airlied: actualy i spend the whole friday afternoon thinking to that
glisse: and there is no good algorithm for vram, we need a driver call back to be able to move pinned buffer and do defrag as some kind of callback
airlied: glisse: yeah in the extreme case
glisse: well we could improve the situation by using some kind of bo scoring
glisse: and move bo to vram only when they hit a threshold
airlied: glisse: we could allocate from end of vram
airlied: and put pinned at start
airlied: but I think resize still messes it up
glisse: yeahed thinked to that but it leads to other issue
glisse: there is just no elegant simple solution
glisse: i think best is having bo move to vram only when they really stay alive for long time
airlied: well fragmenting unpinned space isn't that hard to resolve
airlied: it just gets hard when a cursor ends up in the middle of vram
glisse: yeah defrag unpinned is easy
glisse: but we need to defrag pinned
airlied: that will cause glitchse
glisse: i tested the case where you allocate new fb and you quickly screw
glisse: not if we clever about it
glisse: allocate new pinned position copy, swap on next vblank
glisse: well crtc update should do it for us
glisse: so there shouldn't be any glitches
airlied: glisse: that works if you have enough space ;-)
airlied: you also have to stop rendering for a frame
glisse: no, it works fine
glisse: kernel decide to move buffer: schedule into the ring: waitfor idle on src bo, blit, wait for idle blit, crtc reprogram
glisse: so it's all atomic from the userspace point of view
airlied: but if we want to move something at 200 bytes long pinned at 100 to 0
glisse: that case isn't handled
airlied: thats the most likely though
glisse: defrag i am thinking about is to move all pinned buffer next to each other
airlied: small fb at startup -> resize to big fb after small fb
glisse: from what i see when you allocate new fb and then free old fb most of the time the gap is the old fb
airlied: yup and that is smaller than the enw one
airlied: so you have split vram space
airlied: some before pinned some after
glisse: yeah well that case could happen too
airlied: its the likely case when you plug in a projector
glisse: it could work if there is enough vram
glisse: would need 2 blits
glisse: allocate after the pinned, blit their, use that as a scratch space and blit to the new place from their
airlied: it would be nice if we had shatter, so we could allocate a second farmebufer for second head ;-)
glisse: also virtual address space would be a killer feature here
glisse: there is someclever algo for kernel to defrag memory when you have virtual addressing
glisse: that would solve our problem nicely
airlied: you just end up with fragmented virtual address space ;-P
glisse: well it's defreg algo to defrag physique address space so you can have lot of free physical space contiguous
glisse: usefull for thing like scanout buffer
glisse: but anyway virtual address space seems to impact perf a bit too much
airlied: should ask TH if he has any ideas or has done anything in private driver ;-)
airlied: but I think we just haeve to bite the bullet and try and not make it suck
airlied: btw the vram sizing reported to userspace is garbage
airlied: I started fixing it but I forgot what machine I did it on
airlied: must be on crappy laptop in office
airlied: currently it just takes VRAM size - 4MB
glisse: i was thinking that we should also report the biggest chunk size
glisse: as it could be informative
glisse: for vram
airlied: yeah I thought about that but it could still fail badly
glisse: also what happen to the fb framebuffer nowadays ?
airlied: glisse: still pinned
airlied: on 32MB card I'm going to make it 8bpp by deafult
glisse: yeah, i hate fb
glisse: but we don't have good replacement
airlied: unpinning it is a nightmare anyways when we panic
airlied: I was thinking maybe we could do full sw fbcon
airlied: and just do some sort of update on vblank
airlied: then we could update it on top fo X
airlied: for panics
glisse: i was thinking of allocating fb in ram and register accel to blit to vram only when pinned
glisse: guess we got the same idea :)
airlied: glisse: hehe.
glisse: i am also working on the delorean because what ever the Doc says there is things we need to change ;)
airlied: yeah we need hire the Doc.
airlied: glisse: for resize we might be able to try and do a fastpath in-kernel
airlied: so we know fb is from 0->100, new fb is going to be 200 size, so we allocate new fb above 200, copy it, then copy it again back to 0
airlied: doing that frmo userspace driver is a bit crappy
airlied: but we could do a radeon specific resize ioctl and do it all in-kernel
airlied: I think my F10 or F11 driver did a dirty resize hack
albertW: I have a problem with touhou 11/12. It is slow to a crawl and most of the time is spend in X. Reading from similar bugreports it seems to be related to the drivers: http://bugs.winehq.org/show_bug.cgi?id=18232 Anyone knows what could be wrong or how to isolate the problem?
glisse: airlied: well i am wondering if a tearing for one frame is not after all that much an issue
glisse: if we do defrag each time after we pin a buffer, it more than likely that the buffer is black
airlied: well we pin everytime we vt switch or unblank the cursor I think
glisse: for cursor i don't think it will be that much an issue cursor are small
glisse: what we can do is align allocation on buffer size for pinned buffer
glisse: and then only defrag can pin a buffer unaligned to it's size
glisse: that way we know we have enough room to move the buffer
glisse: like the solution you just described
glisse: could be an issue on small vram gpu
airlied: I'm mainly thinking of my 16 + 32MB cards ;-)
glisse: well it will be an issue for 2048x2048 framebuffer :)
glisse: well we could do in kernel pin(alignsize), if fail pin
airlied: zzzz time
glisse: and then we could use defrag and have some tearing bad frame on thus gpu
glisse: good night
MrCooper: airlied: I posted a patch for better VRAM size information a while ago...
MrCooper: what's the current plan for the 'cursor needs to be within 128M of scanout' problem?
glisse: MrCooper: i am working on ttm patch to allow allocation within a certain range
glisse: got distracted with bug
albertW: just ignore my question, filling out a bugreport for mesa now.
bragon: i try My HD4770 with the radeon drivers insted of radeonhd
bragon: in fact, it's better :)
rxt0: agd5f: still no luck with tv out
Ronis_BR: hi all
Ronis_BR: can anyone tell me where I can find good options for the driver?
simplexe: Ronis_BR: man radeon
Ronis_BR: thanks :)
Ronis_BR: simplexe: do you know if 3D works really better without kms?
simplexe: hmmm.... not sure, but in glxgears it shows more fps
simplexe: for r6xx
adamk_: 3D is still mostly faster without KMS.
rxt0: yep, for r500 everything is faster with KMS
rxt0: lol, typo
Ronis_BR: adamk_: to disable it I have to pass modeset=0 right?
Ronis_BR: at grub
Ronis_BR: or radeon.modset=0
simplexe: Ronis_BR: nomodset
Ronis_BR: just it?
Ronis_BR: I'll try
Ronis_BR: simplexe: well, much faster :D
Ronis_BR: simplexe: can I still use uvesafb?
taiu: brown bag please
taiu: agd5f: please ignore my earlier success with DownloadFromScreen
Ronis_BR: I think I'll enable uvesafb by now
Ronis_BR: until KMS becomes better
taiu: I was running in dri2 mode - that one has worked ok
Ronis_BR: taiu: dri2?
Ronis_BR: how can I switch dri1 dri2?
Ronis_BR: or it can be switched?
taiu: reload module with modeset=0/1 or reboot
simplexe: Ronis_BR: yeah
Ronis_BR: taiu: modeset=0 is dri1 right
Ronis_BR: well, with dri1 3D becomes much faster :D
Ronis_BR: glxgears was 500fps with dri2 and 1000fps with dri1 (composite enable)
Ronis_BR: with fglrx it achives 400fps :D
taiu: well sometimes dri2 is faster for me in some games , with VBO's and some r600 texture uploads
Ronis_BR: ah, I now some artifacts was removed
rxt0: does anybody got tv-out working on R500?
Ronis_BR: much better now :)
Ronis_BR: too bad I can't use KMS :(
Ronis_BR: I hope it becomes faster in the future :)
Ronis_BR: everything is fine now :)
Ronis_BR: the KMS problem is because my hardware?
Ronis_BR: I mean, do I need a faster video card to have better performance with KMS?
biotube: KMS isn't optimized
biotube: the bottleneck's CPU-side
Ronis_BR: biotube: so probablly it will be better in the future
Ronis_BR: biotube: does it help removing ttys?
Ronis_BR: I have 6
Ronis_BR: will it be faster with 3?
biotube: I don't know, but performance had better increase since it's slated to replace UMS
biotube: s/increase/increase in the future/
biotube: the current system
biotube: where X handles modesetting
Ronis_BR: good :)
Ronis_BR: I'm wondering if the artifacts that I had with xorg 1.7.1 could be caused by dri2...
biotube: it's possible - you're dealing with lots of freshly minted code
Ronis_BR: biotube: do update worth so?
Ronis_BR: I mean, do xorg 1.7.1 faster ?
Ronis_BR: or i'm good with 1.6.5
biotube: I just use whatever Debian ships with testing
Ronis_BR: that is?
Ronis_BR: 1.2? :D
biotube: according to apt-cache, 1:7.4+4
Ronis_BR: i don't know the name :(
biotube: debian calls the package xserver-xorg
Ronis_BR: here xorg-server is named 1.6.5, 1.7.1
Ronis_BR: anyway, if there is any radeon developer here, congratulations!
Ronis_BR: you really did a great job
chithead: xserver-xorg-core is the actual server version
biotube: then it'd be 2:1.6.5-1 over here
Ronis_BR: ok so :)
Nille02: I have an little questeion how it looks like Evergreen support?
Nille02: is http://wiki.x.org/wiki/RadeonFeature up to date?
chithead: it was last updated 2009-11-17
chithead: I don't see r800 related commits in git
Nille02: thank you
agd5f: glisse: maybe special case cursors and just always make them the first or last few bytes of a scanout bo. that would also avoid fragmentation
glisse: agd5f: it's painfull to achieve with the cursor api
glisse: well maybe not, i need to read it again
glisse: but adding extra space for the cursor was one of the idea at one point
agd5f: glisse: just always pad the bo and then hardcode the crtc base or cursor base to scanout_bo + 4096 or whatever the cursor size is
glisse: issue is not that
logari81: I have 100% cpu usage by Xorg, is there any suggestion how I could debug such a problem?
glisse: issue was how to deal with constantly changing cursor
glisse: well not constantly but often
agd5f: oh, right
MrCooper: copy updates to the scanout BO
glisse: MrCooper: what i didn't check is do we expect that cursor bo change we are unaware reflect on the screen
glisse: for instance if cursor bo is mapped
MrCooper: then we could even apply the gamma in the process :)
MrCooper: we could zap the mapping after copying
MrCooper: and handle it in the page fault
glisse: it's doable but it painfull :)
MrCooper: alternatively we could require userspace to set a new BO for updates
yupi: hello. OT question: how to get mesa 7.6 branch from git? ;)
yupi: (trying to get dri for r700 on debian)
agd5f: yupi: see topic
da1l6: what is the recommended mesa branch for r600 3D? master?
adamk_: da1l6, That's where all the active development is happening.
da1l6: thats what i am using now.
da1l6: there are some glitches with KDE4 plasma. Is this known?
da1l6: supposed to be transparent plasmoid backgrounds on the panel are light blue instead.
da1l6: triggering a redaw fixes it, for some time.
biotube: do you have kwin's effects active?
da1l6: In XRender mode currently.
da1l6: OpenGL mode has similar problems, but worse.
biotube: well, kwin is known to be buggy
biotube: at least with respect to radeon
da1l6: Before upgrading Mesa and DRM, it worked fine (XRender mode, opengl was not supported)
kdekorte: I just upgrade mesa from git, and I have rebuilt mesa twice (clean and distclean) and I'm getting this
kdekorte: libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so
kdekorte: libGL error: dlopen /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: radeon_ptr_2byte_8x2)
kdekorte: ../../../../../src/mesa/drivers/dri/common/spantmp2.h:398: warning: implicit declaration of function 'radeon_ptr_2byte_8x2'
legume: kdekorte: I get the same error on 32 bit.
kdekorte: yeah, recent patches broke it, e015a4c29bf61077a50780cc99381510671b20ec worked this morning
PyroPeter: If it says "[drm] loading foo bar microcode" in dmesg, it is a sign for a correctly installed firmware?
hbbs: Fedora 12 + KMS (AGP x1600 pro) + compiz = very slow response
biotube: PyroPeter: if it doesn't spit out an error
MrCooper: kdekorte, legume: my bad, I just pushed a followup which hopefully fixes that
hbbs: airlied, Fedora 12 + KMS (AGP x1600 pro) + compiz = very slow response. Is that a known bug?
soreau: hbbs: It might help if you elaborate on what you mean by 'very slow response' specifically
kdekorte: MrCooper, compiling now
kdekorte: MrCooper, still broken.. libGL error: dlopen /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: radeon_ptr_4byte)
hbbs: soreau, Using Fedora 12 (just tested) and Lucid Lynx with the latest lucid kernel , KSM enabled + compiz I have a very slow response time when I try to use gnome-menu, open a terminal, I mean, everything. It is really slow, a delay of a 5 seconds
soreau: hbbs: That is a better description at least :)
spreeuw: hbbs: try gtkperf
spreeuw: gtkperf -a
hbbs: Right now I'm using Lucid Lynx with a earlier kernel version that did not show this issue.
hbbs: spreeuw, do you want me to boot using the newest kernel to debug?
spreeuw: run gtkperf -a once
aHungBus: People still use Fedora? I thought everyone's on Ubuntu these days
spreeuw: it's ~5s here
hbbs: spreeuw, I do not have this package installed, where I can get it?
aHungBus: gtkperf -a = Total time: 19.68
spreeuw: oh nevermind it's just a compiz problem I guess
spreeuw: my machine does it in ~5s
aHungBus: oooh dangerous
aHungBus: what are you packing?
hbbs: I own a X1600pro AGP
spreeuw: Athlon X2 5600
MrCooper: kdekorte: ugh, fixing...
aHungBus: what clock is the 5600?
kdekorte: aHungBus, for r6xx support Fedora 12 is the the place to be, and I've been a Fedora user for years since F1
spreeuw: aHungBus: 2900
hbbs: It could be a radeon driver/mesa issue I can only tell that is present on Lucid Lynx and Fedora 12.
spreeuw: this is the newest revision of this cpu
spreeuw: it had an earlier release too
aHungBus: kdekorte, I've used Redhat since 5.1, I used Fedora till 3, I've switched to Ubuntu since, and I can't believe how blind I've been for so many years
kdekorte: hbbs, does adding "nomodeset" to the kernel line in grub alter anything
spreeuw: the varieties in speed are probably setting related
aHungBus: spreeuw, thats pretty quick. I'm using a 2.6Ghz X3, and HD4870, ~20s
aHungBus: i guess the 2D on the R300 must be a lot more mature right now
spreeuw: at what res does it run for you?
aHungBus: the default?
spreeuw: I use half a screen on 1920x1200
spreeuw: dunno about defaults
hbbs: kdekorte, If I disabled kernel modesetting everything just looks normal.
spreeuw: this is a tiling wm
kdekorte: gtkperf is usually cpu bound... but it is a good test...
spreeuw: on dri1
spreeuw: without compiz
spreeuw: or composite
aHungBus: ok, i'm using compiz
kdekorte: hbbs, open a bug then, KMS is supposed to give the same results as non-kms
kdekorte: hbbs, what kernel are you using in Fedora 12?
PyroPeter: x works, but glxinfo tells me it is using the software rasterizer. my chipset is rv710, xorg.log: http://pastebin.com/d2e623d5c
aHungBus: aHungBus, and I might add, I'm an RHCE as well. Really Ubuntu kicks fedora's ass. You have to give it a go
aHungBus: oh that was for kdekorte
spreeuw: fullscreen its ~5.2s
cxo: at 1920?
cxo: how do you make it fullscreen?
kdekorte: aHungBus, to each his own... I can't stand Ubuntu, but if you like.. yea for you..
spreeuw: cxo: I start it from a maximized terminal
MrCooper: kdekorte: try again
hbbs: kdekorte, right now I'm on Lucid Lynx but i have just tested on the F12 Live CD (boots with KMS on) and the moment I enable compiz everything becomes slow, really slow.
adamk_: PyroPeter, Anything interesting show up in 'dmesg | grep drm' ?
spreeuw: and then the wm stretches it automaticlaly
spreeuw: tiling wms are always fullscreen
spreeuw: untill you subdivide the areas
cxo: kdekorte, I couldn't initially as well, the whole deb/apt learning curve was such a PITA, but once you get used to it. Ubuntu is so much better
kdekorte: MrCooper: libGL error: dlopen /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: bswap_16) do I need to make clean?
hbbs: kdekorte, On Lucid Lynx I'm using an earlier version of a Lucid Kernel compiled against 2.6.32rc6
PyroPeter: adamk_: no, just resets and loding of microcode
kdekorte: cxo, it was not that apt/yum thing.. it was the fact that I would get it working, do an update and it would die horribly.. happend a couple of times on boxes I needed so it didn't make it for me
cxo: kdekorte, your toolchain is out of whack, you need to rebuild mesa, i'd do drm as well
adamk_: PyroPeter, The only things that jump out at me in your log file are the 'VGA arbiter' warning and the 'Could not set DRM device bus ID', but I have no idea what those actually mean.
kdekorte: cxo, worked just fine eariler today
spreeuw: gtkperf -a -c 1000 : 66s
hbbs: kdekorte, right now I have KMS/DRI2 + compiz on without the "general slowness" issue
MrCooper: kdekorte: nope, are you on BSD?
kdekorte: Fedora 12
hbbs: I was under the impression that would be more people having this issue, well maybe they will found out that later when they upgrade to Fedora 12
kdekorte: MrCooper, rebuilding agian... only did a make after that last patch
adamk_: kdekorte, MrCooper: FYI, I had the same error earlier today after updating my local tree.
kdekorte: MrCooper, did a make distclean, and rebuild still getting undefined symbol bswap_16
legume: MrCooper: Getting the same here - also now building after distclean
hbbs: I'm gonna boot using the latest kernel on Lucid Lynx
kdekorte: In file included from radeon_span.c:415:
kdekorte: ../../../../../src/mesa/drivers/dri/common/spantmp2.h: In function 'radeonReadRGBASpan_RGB565_REV':
kdekorte: ../../../../../src/mesa/drivers/dri/common/spantmp2.h:600: warning: implicit declaration of function 'bswap_16'
kdekorte: MrCooper, ^^ still your bug
MrCooper: yep, as I said...
cxo: 16 bits swap function?
PyroPeter: well, I updated to kernel 184.108.40.206 and after this my X did not work until I updated radeon. I use the git-head-versions of moste of the x-stuff
cxo: kdekorte, maybe just start by rebuilding drm, then mesa, then xf86-video-ati, (remember the --experimental params)
kdekorte: cxo, that is not the problem
kdekorte: the fact that I can revert back to e015a4c29bf61077a50780cc99381510671b20ec and it works shows that is it recent breakage
cxo: Well that was meant to be a solution :)
cxo: do a git diff and see if you can find something messing with bswap_16
kdekorte: wait a sec...
hbbs: I had to disabled compiz
hbbs: see this log: http://yourpaste.net/3855/
hbbs: I have radeon.modeset=1 radeon.agpmode=8
cxo: Dont you need to enable composite in xorg.conf?
kdekorte: where is bswap_16 defined?
hbbs: DRI2: (II) RADEON(0): [DRI2] Setup complete
hbbs: KMS: (II) [KMS] Kernel modesetting enabled.
kdekorte: did a grep on the mesa and libdrm git tree and only find a usage of it in spantmp2.h
hbbs: AGP: [ 2.702987] radeon 0000:01:00.0: putting AGP V3 device into 8x mode
kdekorte: MrCooper, any pointers on where bswap_16 is defined?
legume: PyroPeter, adamk: The WW for vga abiter isn't a problem but the EE is - I notice for me - DRM interface version 1.3 you = 1.0 maybe libdrm needs updating?
MrCooper: kdekorte: it doesn't matter, it's glibc specific and can't be used there directly in general
cxo: kdekorte, bswap_16 is a macro in the kernel
cxo: it should be in your headers, check, /usr/include/byteswap.h
PyroPeter: legume: libdrm is todays git-head
kdekorte: MrCooper, adding "#include "byteswap.h" to spantmp2.h fixed the problem for me
MrCooper: kdekorte: sure but it won't help on non-glibc platforms
kdekorte: yeah, but on glibc platforms it is broken
cxo: well hes on fedora, which is glibc isnt it
legume: PyroPeter: Oh, OK maybe that refers to kernel - I don't know. If you built from git if you didn't autogen --prefix=/usr then there is a chance the old one is still being used.
kdekorte: can't just magically call kernel macros from userspace
cxo: but you dont call macros
cxo: macro is just used at compile time
kdekorte: yeah, but you can't compile either unless you include that code in
MrCooper: guys, I'm working on a fix...
cxo: MrCooper S!
cxo: the fastest Cooper around
MrCooper: I like to clean up after myself
soreau: Sooper Cooper
kdekorte: soreau, now that ABBA song is in my head
dileX_: soreau: sound like a ABBA song
hbbs: soreau, gtkperf -a 17,17
kdekorte: hbbs, 18.36 here, but your CPU affects that test
kdekorte: I usually use gtkperf -c 500 -a
PyroPeter: legume: there are only libdrm's in /usr/lib
dileX_: MrCooper: "I like to clean up after myself" nominates you for the prize of "swabian kehrwoche"
hbbs: kdekorte, I'll try that,. My CPU is a Pentium D 2,8 (not that fast)
hbbs: but is really slow here
hbbs: difficult even to type
kdekorte: hbbs, if you turn off compiz does it get bettter?
kdekorte: I run metacity and most things are quite quick
hbbs: kdekorte, yes, it does get better
hbbs: gtkpref -c 500 -a = 99,41
kdekorte: hbbs, might try agpmode=-1 on the kernel line or setting "EXANoDownloadFromScreen" "False" in your xorg.conf file .. see "man exa"
kdekorte: hbbs, agp sometimes is a little quirky
jcristau: nice euphemism
[Enrico]: can i ask a curiosity? why now a firmware is needed for radeon?? if i uderstood well it is not a propetary firmware, it is FOSS isn't it?
biotube: [Enrico]: the command processor needs it and the card doesn't possess permanent memory
jcristau: [Enrico]: it's always been needed
jcristau: and no, it's not foss
[Enrico]: oh i see
papillon81: great work on KMS and radeon r700 :-)
[Enrico]: thanks :D
papillon81: it's my first successful try
hbbs: kdekorte, with the previous kernel version on lucid i can use KMS/DRI2/AGP 8x. The problem lies on the newer lucid kernel and Fedora 12 kernel.
jcristau: [Enrico]: the only difference now is it's not built into the kernel module, it's in a separate file
papillon81: have you tested KMS with r300 on PPC?
papillon81: last time I did it crashed
[Enrico]: jcristau: i see
[Enrico]: jcristau: license issue i guess
jcristau: well partly
MrCooper: kdekorte: try again
MrCooper: papillon81: I pushed Mesa fixes for KMS on big endian platforms today
papillon81: MrCooper: ok. good
papillon81: will maybe give it a try in the next days
hbbs: I'll reboot to the previous (usable) kernel
cxo: dont they put ATis in macs?
kdekorte: MrCooper, yea!!! thanks for putting up with me
MrCooper: np, so it's working again?
osiris_: could someone with r100 and r200 cards regression test my radeon-texrewrite-clean branch, please?
kdekorte: MrCooper, yup back to hardware mode
papillon81: here is a problem with 3d stuff: http://pastebin.com/d39fd21
biotube: the irq support code isn't in
biotube: the rejection's reason lives in dmesg
papillon81: [drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 45.
papillon81: [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014
papillon81: [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
MrCooper: papillon81: you need to update Mesa from Git
papillon81: MrCooper: allright. will do as soon as I can solve a linking problem
osiris_: airlied: could you please test my mipmap patches on r100 and r200? I'd like to push them before the mesa 7.7 branch will be created
dileX_: hmm "docs: list the new VMware SVGA Gallium driver in release notes" sounds interesting
legume: MrCooper: working here also.
Zajec: glisse: do you have any other idea about my engine reclocking work?
legume: PyroPeter: You are using 2.6.31 - I am not sure whether that kernel has 3D support for your chip - maybe it depends on what the distro did.
Zajec: glisse: why actually end of timer's thread while engiine is still settling should cause lock up?
legume: PyroPeter: If you know it has, then I don't know what the problem is, but if it hasn't then you would need to build modules from agd5fs' libdrm tree.
PyroPeter: well, I use arch, but i installed that modules
legume: PyroPeter: So you built modules from r6xx-r7xx-3d branch of agd5f libdrm?
airlied: MrCooper: oh I missed that patch, I'll go dig it up again
kdekorte: From what I understand the r6xx-r7xx-3d branch should not be used anymore
legume: PyroPeter: OK, that's me out of ideas then.
glisse: Zajec: haven't played with that yet
PyroPeter: legume: thanks anyway, that could have helped a lot ;-)
legume: PyroPeter: np, maybe kdekorte is right - the last kernel I did like that was 2.6.29, I've been using drm-next + kms since then, so never tried 2.6.31.
kdekorte: PyroPeter, follow the BuildHowto in the subject
fredl: hi guys. Yesterday (give or take a day) some people on here helped me to get my HD4350 to work together with my Tatung 42" HDTV
fredl: the only thing I still didn't get to work was with my Sony AV piece between the TV and the PC
fredl: I'm a bit concerned... the Sony (I think) requires HDCP.
fredl: is HDCP something that would be done in the hardware of the gfx card?
twnqx: today, yes
twnqx: earlier it were external encryption chips
fredl: In the Sony AV's manual it says 'When the connected component is not compatible with copyright protection technology (HDCP), the image and/or the sound from the HDMI TV OUT jack may be distorted or may not output'
fredl: do most gfx cards have HDCP built in?
PyroPeter: where do I get ddx master? is ddx included in something more well-known?
twnqx: all of today i'd say
Zajec: glisse: ok, thanks, i'll post on LKML finally
twnqx: fredl: the question is rather if it activates automatically, ot if the driver has to
airlied: Zajec: I think its not something lkml can help with
airlied: it sounds like you just need to figure it out
fredl: twnqx - would that show somewhere in the log?
twnqx: doubt it
airlied: there should be plenty of examples of timer usage
kdekorte: PyroPeter, usually the ddx is known as xf86-video-ati
fredl: twnqx, I can't find it in the log. So is there a way to find out if / how the driver activates HDCP?
twnqx: ask someone who knows the card better than i do :P
PyroPeter: so there is a different ddx in the radeonhd-driver?
Zajec: airlied: but this lock up happens *only* when function is called from timer... when I call exactly the same from "our code", it's fine
Zajec: airlied: probably not really bug in timer
Zajec: airlied: but hopefully someome have some idea
airlied: it just sounds like a race you haven't thought about
fredl: adamk knows a lot :P
fredl: adamk are you there?
Zajec: airlied: if that is race... can that happen I don't hit it when calling function from kms part 200 times in row?
EruditeHermit: airlied, f12 released!
airlied: Zajec: yes since those calls are inline
airlied: the timer callbacks happens in aonther context
Zajec: airlied: i call it from debugfs, which probably is not.. ?
Zajec: hm, ok...
Zajec: airlied: what you say sound reasonably
Zajec: airlied: maybe debugfs reading is not really async
airlied: I'm not sure what context the time callbacks happen in but I'm guessing the code makes some assumptions that are wrong
Zajec: airlied: any idea what race may happen that causes lock up?
Zajec: airlied: i guess i'll have to add some mutex? do you have idea for which operation it may be?
airlied: it might be something to do with the context the call is happening from
Zajec: airlied: by contex, do you mean thread?
airlied: but it could be racing against irqs I suppose
airlied: Zajec: yes
Zajec: airlied: it's r6xx, so should not have anything to do with irqs
Zajec: (i guess...)
Zajec: airlied: what may be wrong with timer context?
Zajec: airlied: AFAIK i don't have to worry about any privelages, do I?
Zajec: like accessing memory?
fredl: hmm, a wiki page search on hdcp does not give any results...
Zajec: rdev & friends should be free accessible for timer's function, right?
kdekorte: fredl, I think that hdcp is only used if the source requests it...
kdekorte: fredl, the problem may be that edid information may not be being read correctly when you are plugging into your receiver so you may need to hardcode a modeline
kdekorte: fredl, Xorg.0.log will show you the edid info
airlied: Zajec: yeah in theory it shuold all be the same its mostly userspace access that messes up
olaf: hello , is there new tips , reducing tearing when playing video through XV:textured video (M96 [Mobility Radeon HD 4650]) , lasts gits ?
Zajec: airlied: i do all from console, so not even much rendering is happening
Zajec: airlied: not sure where i should start to look for
legume: PyroPeter: radeonhd is a different, but similar driver it should work, but I would use radeon which is xf86-video-ati.
Zajec: airlied: but thanks anyway :)
Zajec: airlied: you gave me some view on that :)
airlied: Zajec: I guess by actually debugging it, down to where it crashes
Zajec: airlied: not even idea if that crash
Zajec: airlied: i can understand that some illegal operation on GPU can cause it to lock up
Zajec: airlied: but why actially GPU lock up imapcts system (cpu?)?
Zajec: i lose SSH connection on that GPU lock up
papillon81: maybe you can look into this. it is a gentoo portage error report when installing mesa git: http://pastebin.com/d3cc18ed6
airlied: Zajec: but something we do or write triggers the gpu/bus lockup
olaf: papillon81, it's fixed since 1 hour
airlied: narrowing down what that thing is, will help figure it out
olaf: papillon81, delete /usr/portage/disfiles/git-src and emerge mesa again
papillon81: olaf: roger that :-)
Zajec: airlied: hm, ok...
Zajec: too bad i don't have serial console :|
Zajec: to redirect dmesg
olaf: papillon81, dont know why i'v to delete the git-src so
Zajec: airlied: will google for that
papillon81: olaf: strange thing, yes
papillon81: ok, at least glxgears works now. I have to say that everything is really fast, compared to fglrx
olaf: i'm happy too papillon81
olaf: except for tearing playing video :(
papillon81: except for flightgear not working
Zajec: i know AtomBIOS commands are some coded assembler instructions
Zajec: but when we call AtomBIOS command, where is it executed?
Zajec: is this CPU driver for GPU that downloads instructions from GPU, decodes them and executes them?
Zajec: (so finally all read/writes are performed by driver from CPU position)?
airlied: Zajec: its all cpu side
airlied: its not coded assembler more of a bytecode
agd5f: Zajec: it's more like a script with read/write reg commands. the parser executes the script and read/writes the regs as indicated by the script
kdekorte: When AtomBIOS code is run, is anything done to keep commands coming in from somewhere else?
Zajec: airlied: so if I get netconsole and hack parser to print all operations before performing then i can get operation that causes lock up hopefully?
agd5f: the driver registers call backs for read/write regs, delays, alloc temp storage, etc.
agd5f: with the parser
Zajec: so not easy to debug :|
agd5f: Zajec: easy to debug. add printfs to the atom parser for each command
agd5f: see what gets printed
Zajec: but... actually got new idea... maybe i'll just make mutex for calling atombios commands
Zajec: agd5f: ok, i'll just have to check parser architecture
Zajec: agd5f: what you said (all that callbacks) sounded really complicated
Zajec: well, maybe not complicated... but longer to understand :)
airlied: osiris__: I'll see if I can get a chance, might be easier to merge it then make me fix it ;-)
osiris__: airlied: ok, will merge it tomorrow anyway because the mesa 7.7 branch is to be created on 11.19
AstralStorm: the -vo gl bug is resolved.
gimzo1: osiris__: does that mean that master will get bunch of new stuff ?
spreeuw: haha nexuiz has brutal action
spreeuw: CS already in a section(r700_render.c,r700SyncSurf,141)
spreeuw: CS can't start section(r700_render.c,r700Start3D,106)
kdekorte: spreeuw, are you using update components cause I don't see those messages
spreeuw: what does that mean?
spreeuw: this happened before a crash
kdekorte: what versions of kernel, libdrm, mesa and xv86-video-ati are you using?
spreeuw: normally I only update mesa
spreeuw: will checkout the kernel stuff again
spreeuw: nexuiz looks great on Normal setting
spreeuw: low totally ruins the weapon effects
Zajec: Mesa 7.7? I expected r600 to stabilize before
spreeuw: its pretty good already
osiris__: gimzo1: not really that much.
spreeuw: kdekorte: what versions are recommended atm
osiris__: gimzo1: first part will be fixes for texture handling
spreeuw: been using 31.5 with drmnext merge
spreeuw: but it had conflicts in one unused driver
osiris__: gimzo1: second part (I'm not sure whether it will hit 7.7) is the hw accelerated blit support
kdekorte: mesa from git, libdrm 2.4.15, xf86_video-ati git...
kdekorte: kernel, I'm not sure, but I think current kernel + drm-next
kdekorte: yeah there is a problem with the intel driver, don't know when that will be fixed
osiris__: gimzo1: and with these two + libtxc_dxtn and more games are becoming playable
spreeuw: kdekorte: is there some brute way to get around it
spreeuw: so I can do a drm pull
kdekorte: I'm using the fedora 12 kernel so I'm not pulling kernels anymore
gimzo1: is hw blit for r300 or r600 only ?
kdekorte: I just pull mesa and the ddx occasionally
spreeuw: me too
osiris__: gimzo1: r500 actually (but r300 shouldn't be too far)
kdekorte: osiris__, looking forward to trying that patch, see if it improves 'fosfor' on my r500 machine
osiris__: gimzo1: all test reports are welcome
gimzo1: so I guess that'l give some boost to apps that are already working ok (but slow) on r500
kdekorte: osiris__, done any testing with clutter? That always seems to be slow
gimzo1: osiris__: I'm running phoronix-test-suite on master every few days (actually just started sunday), if that counts ?
osiris__: kdekorte: it uses glReadPixels, and it's like the slowest path they could have choosed
osiris__: kdekorte: they'd better use FBOs
osiris__: or at least glCopyTex[Sub]Image
kdekorte: osiris__, glReadPixels is problematic on r600 anyway at the moment...
kdekorte: alot of the clutter people are intel people and I think clutter runs ok on intel chips
osiris__: gimzo1: the hw accelerated blit should help much in some apps
kdekorte: need some mesa/ati people to give them some tips
gimzo1: osiris__: what else could be useful (to test) ?
osiris__: gimzo1: the apps/games that used to crash before
gimzo1: I find these on the wiki ?
osiris__: gimzo1: the texture patches certainly fixes some bugs (e.g. prey and doom3 don't crash anymore)
osiris__: gimzo1: yeah, you could try some apps from RadeonProgram page
Zajec: spreeuw: hm, i still have got problems with it
spreeuw: Zajec: yeah me too
spreeuw: but mesa never waited to include broken drivers
spreeuw: once more people use it the bad spots can be spotted easier too
Zajec: spreeuw: :P
Zajec: i need much longer days :|
spreeuw: kdekorte: it happens with the blue ray gun alternate fire
spreeuw: it shoots blue glowing blobs
kdekorte: I'll have to try it out
spreeuw: CS section size missmatch start at (r700_render.c,r700SyncSurf,141) 7 vs 9
spreeuw: cs->section_ndw = 7, cs->cdw = 496, cs->section_cdw = 9
spreeuw: CS section end at (r700_render.c,r700Start3D,109)
spreeuw: bo(0x15a0ce68) has size 0.
spreeuw: invalid bo(0x15a0ce68) [0xF0412000, 0xF0413000]
spreeuw: on normal detail
spreeuw: kdekorte: what build binary do you use?
Zajec: couldn't we use standard header (.h) files for all KMS files?
spreeuw: glx or sdl?
Zajec: now all function declarations are in radeon.h and I have no idea where to find functions' body
jcristau: ctags helps.
Zajec: jcristau: hm, thanks
Zajec: sounds interesting
kdekorte: spreeuw, nexuiz-2.5.1-3.fc12.x86_64 and it makes me sick to play.. ugh
spreeuw: yeah I cant handle them to well as I used to either
kdekorte: spreeuw, -glx
spreeuw: especially on these slow monitors of today
spreeuw: and low fps
kdekorte: I have two displays so it shows up on both of them.. so that doesn't help
Zajec: do i need sth special to see printk(KERN_DEBUG ?
kdekorte: but I get 40fps on one setting below normal at 1280x1024x32
spreeuw: [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16385
spreeuw: [drm:r600_cs_legacy] *ERROR* Failed to initialize parser !
spreeuw: this one again
spreeuw: but i didnt reboot after the old crashes
spreeuw: after the previous card crashes I mean
spreeuw: will do a checkout of kernel drm tomorrow
agd5f: spreeuw: that one should be fixed by osiris__ patch here: http://cgit.freedesktop.org/~osiris/mesa/commit/?h=radeon-texrewrite-clean&id=49876ab6a7f2b06177d7ac9651bd7a07956cbb25
kdekorte: agd5f, is that is mesa master?
agd5f: kdekorte: not yet
agd5f: kdekorte: I think osiris__ is merging that branch tomorrow
osiris__: agd5f: it doesn't fix all the bo space accounting errors actually. there's one more case where the state emit isn't triggered by rendering operation - in rcommonBeginBatch
osiris__: osiris__: but I'm not sure the radeonEmitState call can be safely removed from there
osiris__: darn, I'm speaking to myself again
Luzipher: osiris__: that r500 blit support isn't going to work on r600+, is it ?
osiris__: Luzipher: nope
Luzipher: osiris__: and the texture patches ?
fredl: is there a way to tell the radeon driver to turn on HDCP on an EAH4350 card?
fredl: or a way to verify that it's on.
fredl: (or not)
osiris__: Luzipher: r100-r500 only
Luzipher: osiris__: ok, thanks for the clarification :)
osiris__: Luzipher: actually looks like r600 driver also uses this code
osiris__: Luzipher: I'll have to align the r600 driver too
Luzipher: osiris__: the texture stuff ? ok, that's interesting ... :)
agd5f: well, the changes in the common texture code will affect all chips
Zajec: airlied, glisse: i've made atom_execute_table atomic adding new mutex for it
Zajec: airlied, glisse: still locks up on downclocking from timer, so other issue we hit
Zajec: will try netconsole and enabling atombios debugging tomorrow
Zajec: agd5f: that quirks start to seem ugly
Zajec: agd5f: shouldn't we implement kind of flags for matching devices?
agd5f: Zajec: how so?
Zajec: agd5f: checking ids inside functions
DanaG: fredl: HDCP? On open-source drivers? Why?
agd5f: Zajec: only happens once at startup
agd5f: just fixes problems with the connector tables
twnqx: DanaG: because there are devices that don't like to be driven *without* hdcp, like home cinema amps
gimzo: DanaG: because his av receiver supposedly doesn't want to work with unprotected signal
DanaG: Wow, that's a stupid device. =P
Zajec: yes, i know, but wouldn't it be better to store all quirks in one place? and in init detect if device is in quirks table and set some flags for this if so?
fredl: DanaG, I have a Sony AV piece between my HDTV and my PC.
Zajec: agd5f: that's what radeonhd does, and radeon also i think
DanaG: Somebody at the manufacturer should be smacked for that one.
gimzo: so much of "hdcp is only for protected content"
agd5f: Zajec: they are all in one place. the quirk handling funcion
Zajec: agd5f: hm, mayve i just need to see whole function not just patches
DanaG: whips the manufacturer with an hdmi-to-dvi adapter cable. =P
Zajec: "radeon_atom_apply_quirks" ahh, sorry
fredl: DanaG - circuitry for HDCP is in the gfx card, I do not see why the driver wouldn't support it.
gimzo: there is no such thing as dumb hdmi switch, like there are vga, scart/composite/svideo and the like ?
mjr: argh, devices requiring HDCP on the _receiving end_ for arbitrary material?
gimzo: mjr: it's a passthrough device
fredl: mjr - I can't be 100% certain but I looked through the specs of the Sony AV and it says it literally and the tests confirm that's what it does.
kdekorte: fredl, are you sure that hdcp is required? did you check the Xorg.0.log for edid data differences between when directly connected and thru the receiver
Zajec: going sleep, hopefully will debug locking tomorrow
Zajec: good night :)
gimzo: kdekorte: I think he tried with a bunch of modelines and ignoreEDID and the like
fredl: I used IgnoreEDID yes, but there's no reason why I couldn't revert that to verify.
fredl: kdekorte - the TV underreports the max resolution through EDID
fredl: kdekorte, could you point out what I need to look for?
kdekorte: usually pretty clear in the Xorg.0.log file just search for EDID, but if you are using IgnoreEDID then that is not the problem
fredl: kdekorte, http://pdf.crse.com/manuals/3291730211.pdf page 12, Notes of HDMI connections.
kdekorte: I have an onkyo 606 receiver and I've hooked my Windows machine up via hdmi, but never tried it under linux
gimzo: well, it just hit me, everybody was talking that hdcp would only be enabled when protected content is being played. That means that players shouldn't have it enabled when playing family pictures and the like..
gimzo: So then devices like this stop you from using your tv to watch your own content ?
kdekorte: yeah, that is my impression as well HDCP should only be used when requested.. but then again this is Sony
fredl: yeah always Sony :(
fredl: and they say in their manual 'In this case, check the specifications of the connected component'
kdekorte: In fact I think that is one reason I didn't get the sony, the concern over HDMI as my TV is older and I don;t think it has it
ajax: hdmi sinks are required to accept non-hdcp streams. it's a requirement for the hdmi logo.
fredl: well I bought the RHT-G900 because of space concerns.
gimzo: well, check the hdmi specs, and then RMA your device as not working properly :D
fredl: thats going to be difficult to explain to Sony :P
gimzo: they were there when HDMI was made, they should know better than us
fredl: exactly what I'm affraid of.
fredl: 'you just read that spec wrong'
fredl: 'we MADE the spec!'
kdekorte: does your video card have a DVI port on it?
kdekorte: if so you might try a DVI to HDMI adapter althought the manual said not to use that either
fredl: wel that's certainly possible, in fact in the past I've simply connected the DVI out to the DVI in of the TV
kdekorte: Could be the receiver was only tested with Sony products as well
gimzo: I just can't understand the idea of encrypting signal in the cable when they should know the disc protection will be broken in a matter of weeks
fredl: for all I know it works better since the EDID on the DVI input is reliable.
fredl: however, I'd also like to send the audio through the HDMI port
kdekorte: Get a Harmony remote and just have it switch inputs for you when needed.. I ahve to do that with my Wii, cause the 606 doesn't convert the component input from the wii to hdmi right all the time
fredl: maybe I'm just looking for a purely HDMI solution where I shouldn't/don't have to :)
DanaG: heh, look at the diagram on Page 13... since when is video output of a satellite receiver bidirectional?
ajax: fredl: what's the EDID from HDMI look like on this display? i'd be surprised if it were actually underreporting the screen size
DanaG: hmm, what video card? Does yours do multichannel PCM? If not, Optical would likely work.
fredl: ajax - well, it *could* be that the HDMI circuitry just isn't up to par with 1080p. However, I'm certain the display is.
gimzo: well, if ps3 works, that's a bit stretched
ajax: i didn't ask that.
fredl: ajax - and I *get* full 1080p when I use a Modeline and ingoreEDID
kdekorte: fredl, maybe you need some of those $150 monster cables... (j/k)...
fredl: DanaG - like I already said, it's certainly possible with DVI/optical audio.
gimzo: speaking of multichannel pcm, is it possible to get that without all the hdmi/hdcp/video stuff? I'm interested in audio only ?
fredl: ajax - I saved some xorg logfiles, what would you like me to look at?
fredl: ajax: is this enough http://pastebin.ca/1675544
fredl: or do you want the hex data too?
kdekorte: fredl, seems to be missing something, just post the whole log
fredl: I hope... yeah this is the one with HDMI
fredl: oh there's the 1280x720 res as well
fredl: one other thought I was having is that maybe the Sony somehow blocks the signal if it sees it's over the specs of the connected output device.
fredl: seems a bit odd since the PS3 does not suffer that problem.
fredl: here's the log with the Sony in between BTW
kdekorte: could be the receiver caps the video size without hdcp
gimzo: fredl: I suppose you don't have another device with a hdcp enable/disable switch ?
fredl: yeah coz I imagine the PS3 does do HDCP
fredl: gimzo - I suppose not :)
gimzo: the easiest thing to do always includes inaccessible stuff :)
kdekorte: so with the sony in, and ignoreedid false do you get any picture on the TV?
fredl: kdekorte - with the sony in and ignoreedid false I get a picture yeah but in the 1280 resolution.
gimzo: osiris__: is weapon and opponents that dissappear every other frame in warsow a known problem ?
fredl: there it basically does what you'd expect it to do.
fredl: except I would like 1080p which I know it can do :)
fredl: just thinking about something, I do have a much smaller 1080p display
fredl: it doesn't have a magical HDCP switch :)
fredl: but I certainly could give that one a try hoping it'll report 1080 in EDID
fredl: 1080p that is
osiris__: gimzo: I don't thinks so
fredl: what could be a manufacturers reason for underreporting the max resolution on the HDMI input?
chithead: nobody cared enough
fredl: could it simply be because it would overdrive the HDMI circuitry?
fredl: what surprised me to be honest was that the display didn't go in error mode or something.
gimzo: digital circuits either work on a given signal or not work, I haven't heard of invalid signal killing the device
fredl: well I've seen chips melting, not a pretty sight :)
gimzo: where ?
fredl: well not in my tv thank god :)
gimzo: osiris__: what should I do about it ?
fredl: *knock on wood*
fredl: ajax - are you seeing anything in those logs you hoped to see?
fredl: I also saved the DVI log just so I knew I wasn't hallucinating: http://pastebin.ca/1675581
fredl: and that 1920x1080 Modeline in there should look familiar, I simply used that one on the HDMI port
agd5f: fredl: might be more stuff in the extended edid sections for hdmi
agd5f: not sure xserver parses them properly yet
agd5f: in 1.6.x
fredl: agd5f, well I also had the PS3 auto probe the AV/Display combination, also comes back with the 1280 resolution.
agd5f: fredl: I blame sony
fredl: me too.
fredl: they don't like 1080p
fredl: I tried to find a technical contact within Tatung but all they had was webmaster@tatung.... and doesn't reply :P
fredl: damned huge Chinese electronics co.'s
fredl: pretty good end user support though.
fredl: ajax - why did you ask me for those logs? :)
gimzo: fredl: if the tv works ok without sony, then I doubt tatung can do anything
fredl: gimzo - but it doesn't! the TV itself underreports it's resolution.
gimzo: fredl: but the manual says 1080 is supported ?
gimzo: does the manual say you have to force 1080 ?
fredl: on the DVI port it does say that it supports it. On the HDMI port I've found out by setting the PS3 to 1080p manually
fredl: so yeah, driving the HDMI port with 1080p would probably be 'unsupported' :)
fredl: and tatung would market their latest model to me :)
fredl: it's a really nice TV though, had it for 2 years already, relatively inexpensive and good quality.
fredl: anyway, time to go to bed for me. Thanks for thinking with me guys. Tomorrow I'll hook up the other TV to the sony and see what that says.
eosie: zhasha: hi, what's the state of your radeon CS tool?
zhasha: eosie: not currently working on anything because I'm lazy
eosie: zhasha: ok, does it make a dumped CS readable?
eosie: zhasha: did you see my previous message?
zhasha: yes, and yes
zhasha: but it doesn't yet show bitfields
zhasha: eosie: you can clone it, it's on fdo git
zhasha: the code is fairly horrible though. it looks for the register file in a fixed path
glycoknob: hi folks
zhasha: hi glycoknob
glycoknob: is there GLSL support in the linux radeon driver yet? I have a RV350 based card
glycoknob: glxinfo | grep shader only works with the mesa-software driver - so I its useless effort atm trying to get it running?
soreau: glycoknob: What card and distro are you using?
soreau: There is preliminary glsl support in the gallium driver but it's not ready yet though it should already work with hw rendering as the 'normal' driver does currently
glycoknob: soreau: Radeon 9600 PRO // ubuntu karmic with xorg-edgers packages (1:6.12.99+git20091109.0ee7763f-0ubuntu0sarvatt)
soreau: glycoknob: Yea, with the radeon driver as it is now, glsl stuff will fall back to sw routines. The gallium driver is what will have GL2.1 support
glycoknob: soreau: ah thanks for the information
glycoknob: have a nice day
cxo: soreau, glsl works with the classic mesa driver ?
soreau: The work is taking place in the gallium driver
soreau: Unless you want to call falling back to sw routines working
chithead: didn't developers at least consider bringing glsl to classic mesa
hagabaka: I get flickering lines in X and framebuffer, in X I can fix the flickering by changing the refresh rate from the default 60 to 75, but on restart it's changed back again, and adding a modeline (from xvidtune -show after I changed the refresh rate) to xorg.conf doesn't have effect
soreau: Using kms?
hagabaka: and fbset displays framebuffer mode is 800x600-0, although I set 1024x768@60 for the kernel options
soreau: IIRC, you are not supposed to use fbset
hagabaka: i'm only using it to display the current mode though
soreau: You can set a video=1024x768@60 kernel param if you have drm-next
hagabaka: I'm using 2.6.32-020632rc6-generic
soreau: Actually, it would be like video=VGA-1:1024x768@60
soreau: I dont know if that kernel has support for this feature or not as it is quite new
hagabaka: since xrandr says "VGA-0 connected", I should use VGA-0 right?
soreau: I think you should use VGA-1 for the kernel parameter.. test it
soreau: I think if you specify video=1024x76video=1024x768 without the