Nightwulf|work: hi all
NTU: r600g seg faults possibly due to olv's patch
NTU: nvm i fixed it
NTU: good night all!
mathbr: Hi. I am regularly getting these with my RV730 (linux 2.6.35-rc5, radeon 6.13.1): http://pastebin.com/6UDRFyj9
mathbr: As soon as this happens window switching and resizing becomes really laggy.
mathbr: I found old reports about this but they where claimed to be fixed.
mathbr: Already tried booting with pci=noacpi
soreau: Have you tried latest mesa?
soreau: probably would only be relevant if you're using a compositing manager
mathbr: Not the very latest, no. Currently running 7.8.2. Is there a way to use it directly from source directory?
soreau: see the topic?
soreau: Is there something specific that usually triggers this and/or are you running a compositing manager like compiz?
mathbr: Yes, compositing via Xfwm4, thus Xrender. And the description in the topic invokes "make install" which I am surely not doing to bypass my package management.
mathbr: Are there no environment variables which can be exported before starting X to make it use local builds?
soreau: If you read the topic.. it tells you how to set module paths
mathbr: soreau: Yikes, you’re absolutely right. Didn’t read thoroughly enough, my bad.
mathbr: OK, I’ll try that.
mathbr: I cannot get libGL.so loaded from my local build directory. I tried both adding LIBGL_DRIVERS_PATH to /e/environment as well as building with --enable-glx-tls, ldconfig still shows /usr/lib/libGL.so being used. Any idea?
mathbr: (And yes, mesa was built with --with-dri-driverdir)
mathbr: Uh, seems running just "ldconfig" is required. I think that should be mentioned in the Wiki.
mathbr: OK, got it fixed. It was simply that /usr/lib was in /etc/ld.so.conf before inclusion of the /etc/ld.so.conf.d/*.conf files.
mathbr: I’ll drop by again if the issue re-occurs. Thanks for now.
okias: Hello, I hit probably small bug in r300g (rs690) in combination with lightspark flash player. Lightspark and mesa is compiled with debug: http://pastebin.ca/1910977
okias: MostAwesomeDude: ping
Luzipher: As I just saw pm is now "done" for r700 cards - does it also work with dual cards ? (I remember to have read it didn't yet work with two cards in the system some time ago)
agd5f: Luzipher: it will work with all cards assuming you have kms enabled
Luzipher: agd5f: yes I do have kms enabled. Thanks for the clarification :-)
[Enrico]: agd5f: so now there is no need to specify radeon.dynpm=1
[Enrico]: ?
[Enrico]: oh wait i confused myself i think eheheh
[Enrico]: or not?.... dunno i had missed the lastest radeon progress to study for an exam eheheh ^^'
agd5f: [Enrico]: http://lists.freedesktop.org/archives/dri-devel/2010-May/000492.html
[Enrico]: agd5f: thank you very much :)
[Enrico]: oh cool, it is set via sysfs now
olesalscheider: okias: I tried it with the following result: http://pastebin.com/CLcrRsVR
olesalscheider: okias: there seems to be one dpyPriv in the list that cannot be dereferenced
[Enrico]: agd5f: come on you work from amd, take a peek to the fglrx code and look at how it does clock switching, reimplement it in radeon. Nobody will know :)
[Enrico]: s/from/for/
agd5f: [Enrico]: the fglrx code pm code is larger than the entire open source project code base
[Enrico]: rofl
olesalscheider: oh, he left...
[Enrico]: agd5f: guessed so :)=
agd5f: you can't really just look it up. it depends on a huge, entirely different infrastructure
[Enrico]: agd5f: eheheh i thought so, i was just kidding :)
agd5f: [Enrico]: no worries :)
[Enrico]: it's just i would really see radeon in a good state (not perfect just good, like opengl 2.1 with a fair complete GLSL, a good PM, HDMI and such things working easly)
[Enrico]: fglrx is not bad, but it has some really nasty defects
[Enrico]: the r300g driver is fair near to what i mean for example
[Enrico]: but for r600 is a bit different. r600g is not usable for now. r600 classic is not bad but....
agd5f: [Enrico]: start coding :)
[Enrico]: agd5f: well i know C and linux base system and network programming. never done some kernel work (but it should be fairly easy to learn i think). the problem is i have one exam left and then the degree eheh. we will talk about this after that :)
[Enrico]: but well video driver programming is quite hard i think
agd5f: [Enrico]: no harder than any other project.
[Enrico]: agd5f: i hope so eheheh
ajax: it's like anything else really
ajax: the worst that can happen is it doesn't work.
Zajec: it's harder than many projects ;)
[Enrico]: ahahah i knew it!
Zajec: however I noticed there exists some Gallium doc yesterday...
Zajec: http://people.freedesktop.org/~csimpson/gallium-docs/
Zajec: have to check it out
Zajec: agd5f: why fglrx's PM is so huge?
agd5f: Zajec: pm is really hard to make work reliably and glitch free
[Enrico]: well i worked to some hard project such low latency IPC system in linux (something like mpi) but i think this is even harder
Zajec: agd5f: hm, I hoped we have it done, except for memory reclock sync
agd5f: plus it touches everything, so there's lots of synchronization involved
Zajec: [Enrico]: personally I miss some doc like "how does 3D part of GPU work"
[Enrico]: Zajec: eheheh i think i miss everything about video driver topic :)
Zajec: agd5f: do we still miss "touching" something? ok, there is some sub-PPLing for LVDS... but except for that?
agd5f: Zajec: I think we've got most of it at this point
agd5f: the hard part is doing ti glitch free on the fly
agd5f: and stuff like meeting performance requirements
DanaG: My ideal configurability (through sysfs) would be to have a min_profile and a max_profile setting... auto would switch based on AC state, and dynpm would switch dynamically.
Zajec: agd5f: any idea why we get glitches at memory reclocking? do we have too much latency between IRQ and reclocking?
DanaG: Right now it's hardcoded to use mid and high.
Zajec: yeah, performance may be had
Zajec: *hard
Zajec: DanaG: interesting... did you read Alex's link/
agd5f: Zajec: we should probably split sclk and mclk to separate vblanks
Zajec: DanaG: not sure if I understand
Zajec: u
Zajec: agd5f: I think I tried that at some point but it was still glitchy
olesalscheider: hm, /src/glx/glxext.c, line 247 following: this tries to delete dpy form the glx_displays list, doesn't it?
Zajec: agd5f: will try anyway
olesalscheider: shouldn't it update glx_displays if dpy is the first in the list, too?
agd5f: Zajec: also, plls lock quicker with smaller steps, so it probably makes sense to step down to the desired clock
DanaG: Right now, if you set "power method" to "profile" and "power profile" to "auto", it switches high/mid based on power state. And dynpm switches high/mid based on load.
DanaG: What I want to do, is to be able to change it to use low and mid, or low and high, or such.
Luzipher: ah, I just noticed I have to rephrase my question from earlier: does "dynpm" work if multiple heads on a single card are active ?
agd5f: Luzipher: no
agd5f: Luzipher: chances are the vblank periods will not line up
Luzipher: agd5f: thanks ... will that work sometime in the future ?
Zajec: DanaG: ah, now I get it
agd5f: so you'll always get glitches on one head
Zajec: DanaG: yeah, could be considered
Luzipher: doesn't mind glitches :-)
agd5f: Luzipher: you can enable it in the code
DanaG: Ah, how do the firepro cards align vblanks on the same card?
Zajec: plus we can consider just adjusting engine for mulit-head... for many cards reclocking engine doesn't cause glitches
agd5f: Zajec: this is why the closed source pm code is so large ;)
Zajec: :D
Zajec: good point :)
Luzipher: agd5f: so this feature isn't going to be adressed soon ? Or not at all ?
DanaG: Ah, I wonder if you could release a state diagram, or pseudocode, for the applicable parts.
Zajec: Luzipher: generally it doesn't need more docs, so any can step in and try to fix that
DanaG: Rather than full actual code.
Luzipher: Zajec: well, I'd like to, but at the moment I neither have the time nor the knowledge unfortunately (doing my diploma thesis ... and the summer is too good over here :) )
DanaG: I'm guessing the binary drivers do use low/mid on battery, when set to 'max battery'.
agd5f: Luzipher: have to get one head working reliably before we tackle multiple heads, even then, not sure how much you can do
DanaG: And oddly enough, Compiz takes less power than uncomposited Metacity. =/ With fglrx, that is.
DanaG: It's about 1 watt difference.
Luzipher: agd5f: One head doesn't work right in all cases at the moment ?
agd5f: Luzipher: not with dynpm
Luzipher: agd5f: ah ok. I should make Zaphod work again and test it on my tv :-)
agd5f: Zajec: there's a pretty good diagram of the 3D pipeline flow in the r6xx/r7xx 3D programming guide
DanaG: Heh, I tried radeon + nouveau (with display :0.0 and :0.1 -- is that "zaphod"?) -- it was confusing. =þ
Zajec: agd5f: thanks, i'll check this
jcristau: DanaG: no zaphod is 2 screens one one card
Luzipher: jcristau: are you sure ? I thought it was one x server on two cards ?
agd5f: Luzipher: that's multi-card
Luzipher: agd5f: oh ok ... zaphod was such a nice word ... :-)
DanaG: Zaphod Beeblebrox.
Zajec: agd5f: uhhh, I believe it's still hard to understand that 3D guide... after reading 10th shortname like DB or CB I don't remember any more it's name :P
Zajec: but OK, will try :)
Zajec: (depth/color buffer in this case)
agd5f: Zajec: the basic flow is vertex fetch -> vertex shader -> pixel shader -> (Depth ->) color
agd5f: Zajec: CP fetches and parses command buffers, the command buffers program the regs that define the state of the pipeline
agd5f: vgt send index data to the spi which loads the vertex shader. vertex shader does the vertex fetch and whatever else the vertex program specifies
agd5f: vertex shader exports position and any other attributes (color, tex coords, etc.)
agd5f: position is fed to PA for viewport transform and clipping, and other params are send to SC which then loads the requested params (color, texcoords, etc.) into the pixel shader
agd5f: pixel shader does what ever is requested in the pixel program and sends the output to the render back end which is the DB and CB
agd5f: DB does culling and such if enabled, and CB does blending (if enabled) and writes the results to memory
Zajec: agd5f: OK, let me consult your expl. with docs :) at least for resolving short-names and understanding it's role :)
agd5f: Zajec: draw commands are triggers that say "start the pipeline as it's currently configured"
agd5f: so you command buffers are usually state setup, followed by draw commands
agd5f: sc sends parms to the spi which loads the parms into the pixel shader
edwin: agd5f: is it possible to detect if a texture is used uninitialized? like if there is a bug and you are supposed to render to a certain texture, then later read that texture, but instead you rendered somewhere else and when you read the texture its all random?
glisse: that would be valgrind for gpu
glisse: which would be lovely
agd5f: edwin: the cs checker in the attempts to avoid the case of bas command buffers
agd5f: *in the drm
agd5f: bad command buffers
edwin: well maybe not something as fancy as valgrind, perhaps just some debug output
edwin: like: I'm supposed to render in this buffer: 0xfoo
edwin: I'm supposed to read from this buffer: 0xb00
edwin: and you can notice manually or via some scripts that there is something missing
edwin: agd5f: but as long as all the parameters are valid you can still read texture memory that was never rendered to, right?
agd5f: edwin: the hw doesn't know your intent. only what you tell it to do
edwin: agreed
glisse: if hw could read my mind there wouldn't be bugs anymore
edwin: ah I get random stuff in 2D too
edwin: when logging in to KDE
edwin: sometimes it resembles my desktop prior to reboot, but smaller and with random noise
edwin: (or maybe its 3D if KDE is using compiz)
edwin: well I disabled desktop effects, any way to tell if its using opengl to render my desktop? (so I know if I should file a DDX bug, or a mesa bug)
glisse: guess is texture allocated without being cleared thought kernel should do that
edwin: 2.6.35-rc6
edwin: rv730
glisse: edwin: it happens only on application start right ?
edwin: glisse: only on login yes
edwin: on warm boot
edwin: let me try if logout/login reproduces it too
Zajec: edwin: i guess it's not clearing VRAM
Zajec: too late ;)
edwin: glisse: happens on logout/login too
Zajec: edwin: i guess it's not clearing VRAM
edwin: glisse: in fact I get the screen with random stuff when I just restart gdm
Zajec: edwin: CRTC is enabled before we render something "current" to VRAM
edwin: and I get it once again after pressing login, just as it switches to the KDE login animation
Zajec: and you get view of old VRAM content for a moment
edwin: Zajec: so kernel bug?
Zajec: edwin: not sure if it's drm architecture or radeon bug
Zajec: edwin: generally, GPU driver bug
Zajec: not mesa or hardware bug
edwin: ok
edwin: so I file a DDX bug, and what info do you need besides my Xorg.0.log?
edwin: I could provide you with a camera shot, but I doubt thats of any use
Zajec: edwin: there's already bug agains KMS for this
Zajec: jf you care about UMS, fill bug and link to KMS one
edwin: its KMS here as well
Zajec: can't find on KMS on at the moment...
edwin: no UMS
Zajec: then i believe it's reported already
edwin: ok
glisse: framebuffer isn't cleared, small glitches
Zajec: agd5f: hm, after reading it a little, it doesn't sound so scary :)
mathbr: Hi. Just wanted to drop by and let you know, that the IRQ disabling also happens with the very latest Radeon+Mesa code.
mathbr: dmesg paste again for reference: http://pastebin.com/43SXYHH5
mathbr: Not sure if it is related but right under that error a similar block appears telling me that it also disabled the IRQ of my sound card.
Zajec: what are primitives in 3D world?
glisse: triangle
glisse: quad
Zajec: ah, sure
mathbr: Any other ideas what I could try?
AndrewR: agd5f, ping
AndrewR: .. i was looking into mesa-demos/demos/ray bug with rv280 and compositing: it aborts with ray: radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion `boi->space_accounted' failed but only if i have compositing (built-in e16 version) ON. If i disable compositing - ray survives a bit longer, but anyway aborts after playing with window's size ... not EOF
AndrewR: On my way into mesa's r200 driver i looked into lindr/radeon, found assert, but not sure what i should add into mesa/ddx and where .. but i found one place in r200_state_init.c, it loks not right, changeng it fixes nothing, and adds warning, but i wonder about correct way for writing such functions ... this is my change: http://pastebin.ca/1911133
agd5f: Zajec: also rects and points
AndrewR: like r300_cmdbuf.c (various cb/zb setup was split/mooved for r300, but not for r200 ...i was again confused by _cs vs _mm functions, in r200 driver, right now i think they mean same thing [used in MKS/dri2 case], but i can be wrong here )
agd5f: AndrewR: probably a miscount of dwords somewhere
AndrewR: agd5f, http://pastebin.ca/1911148 (bt full , not my best bt, but reason why i looked into r200_state_init.c)
AndrewR: and libdrm seems to have typo "sime" vs "time" in comments, not sure if such small thing counts ....
AndrewR: http://cgit.freedesktop.org/mesa/drm/tree/radeon/radeon_cs_gem.c - line 186
AndrewR: google + assert message lead to [Bug 29066] - may be its too reproductable only with [xrender-based] compositing ?
agd5f: AndrewR: probably a miscount of dwords leading to a command buffer that's too big
AndrewR: agd5f, ok i'll look at src more, just not right now ..
AndrewR: bug 29066 moved into gallium land, but no gallium for my rv280 - so i have more things to check ...[for example i not tried NoComposite , NoDFS and such options .... may be thue have some impact].demos/renormal also looks wrong, so i have enough things for playing with for nights ...away for now, nice hacking to everyone
AndrewR: *demos/reflect, not renormal (sorry)
gps23: i am experiencing bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=141116, anyone know any workaround?
glisse: gps23: trying newer xf86-video-ati might help
gps23: glisse: thanks, i am going to try it
gps23: glisse: seems like xf86-video-ati is not there in the default xorg package
gps23: f86-video-ati package is installed but xorg is unable to find it. is the name of the driver something else?
glisse: driver name is radeon
gps23: glisse: radeon i am already using which is causing hangs
gps23: glisse: same with driver - ati
glisse: you are using an old one
glisse: try something like 6.13.0
glisse: we don't have resource to backport fixes so before we even bother looking at bug we pretty much request testing of the lastest software
gps23: glisse: i got it, i think i will have to get it externally as it wont be in the repos
gps23: glisse: i am using 6.13.0 only
glisse: ?
gps23: i mean the radeon driver is from package xf86-video-ati v6.13.0
gps23: no surprise, i am using pretty recent freebsd release
glisse: II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.1, module version = 6.12.4
glisse: II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.1, module version = 6.12.4
glisse: compiled for 1.6.1, module version = 6.12.4
glisse: compiled for 1.6.1, module version = 6.12.4
glisse: sorry
glisse: this is what is in your log
glisse: in the bug
gps23: glisse: no, sorry for not making it clear, poster of the bug is someone else. i have found it when i was search for my problem, i am also using radeon and hence facing same bug
gps23: s/search/searching
gps23: glisse: cited bug instead of explaining myself because i though it would make someone understand my problem better
glisse: same hw ?
gps23: glisse: same driver, same os and same problem
glisse: same hw ?
glisse: if no, then different bug
glisse: as first guess
gps23: glisse: no everything is same, poster as written it as i would write myself
gps23: glisse: no everything is same, poster has* written it as i would write myself
glisse: same symptom & different hw likely mean different bug
gps23: glisse: except i have toshiba a70 laptop, and Radeon9100 IGP card
glisse: even if it's same software
gps23: glisse: you are right, i don't know if its good news or bad news for me
gps23: glisse: the only progress i have made is finding that i can run X after disabling accel,dri and dri2
gps23: windows start moving jerky after that
gps23: and that i can run X using vesa driver but with resolution 1024x768(?)
noelferreira: hi. any solution for this problem? https://bugs.launchpad.net/ubuntu/+bug/539851?comments=all
glisse: noelferreira: we can nothing in front of broken hw
glisse: you can use xrandr to add proper video mode and activate hdmi
noelferreira: glisse, my hardware is not working because it is working wiht my hdmi nvidia card
noelferreira: i mean its not broken
glisse: closed driver >
glisse: ?
noelferreira: can you help me with xrand for my lcd tv?
glisse: from log open source driver see broken edid -> broken hw and nvidia likely use something like windows broken parsing or have a work around
glisse: google is full of tutorial
noelferreira: so you are saying there's no solution for me with the open source driver?
noelferreira: the problem is that o also tried proprietary driver wihout success
glisse: i am saying xrandr can help you dealing with broken hw
noelferreira: glisse, can you help me find a xrand mode ?
noelferreira: i never used xrand and i need help
glisse: http://www.thinkwiki.org/wiki/Xorg_RandR_1.2
noelferreira: glisse, i read it before
noelferreira: i am using ubuntu 10.04 and that mentions 7.10
glisse: doesn't change a thing
uid76063: Hi
uid76063: I'm using an ATI AIW radeon with 9.04....
uid76063: any idea to update my driver llinux
edwin: http://www.osnews.com/story/23619/KDE_SC_4_7_May_Use_OpenGL_3_For_Compositing
MostAwesomeDude: win 32
MostAwesomeDude: Argfl.
agd5f: noelferreira: did you ever try a different cable?
agd5f: also, newer kernels have a fix for bad hdmi edid checksums
noelferreira: agd5f, yes
noelferreira: i have this cable, with this LCD TV and this same computer working if i use my nvidia onbloard card hdmi output
noelferreira: agd5f, so i think the problem is not physical
noelferreira: can you help me with xrand to fix the problem agd5f ?
T_UNIX: hey guys
T_UNIX: isn't the driver intended to set the primary output?
T_UNIX: I mean a default one? e.g. if there is hardware acceleration on only one crtc/output (don't know the internals)
dgbaley27: I'm getting tons of these: kernel: [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CB3C (len 62, WS 0, PS 0) @ 0xCB58
dgbaley27: followed by: kernel: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 1sec aborting
dgbaley27: I think it's happening when starting/restarting X when vga_switcheroo is set for "OFF"
dgbaley27: /join #xorg
spstarr: wow
spstarr: http://www.glx-dock.org/
spstarr: !!!!!!!!!11
spstarr: er
spstarr: wrong channel..
spstarr: r600g looks to be interesting
rhodan: Is there a channel for mesa3d?
Daekdroom: rhodan, I think the closest it gets to mesa3d channel is #dri-devel
Droste: or #dri
rhodan: Are Portage's warnings about "poor programming practises" to be taken seriously?
rhodan: Should I report them to upstream?
rhodan: * QA Notice: Package has poor programming practices which may compile
rhodan: * but will almost certainly crash on 64bit architectures.
rhodan: *
rhodan: * Function `_mesa_get_incomplete_framebuffer' implicitly converted to pointer at intel_context.c:900
rhodan: * Function `_mesa_get_incomplete_framebuffer' implicitly converted to pointer at intel_context.c:900
rhodan: ;)
airlied: rhodan: don't see that in the tree anymore
MostAwesomeDude: rhodan: We take it seriously-ish. Sometimes Portage is wrong.
Droste: what's the name of the extension which enables vsync for 3d apps?
rhodan: Do you have QA assurance tools? Couldn't they incorporate Portage's nitpicker code to automatically test every commit?
MostAwesomeDude: rhodan: Patches to the tinderbox would be appreciated. Might have to track down cjb and ask him.
rhodan: Oh, that's what a tinderbox is?
MostAwesomeDude: At the very least, though, there's one false positive: text relocations in libGL are required and so we can't not have them.
rhodan: I can code a hello world in bash.
rhodan: You can tell me whatever you want ;)
AndrewR: agd5f, assertion from ray demo was caused by patch from 28341 ..:/ Sorry, false alarm
rhodan: Does the r300's core interrupt masker have a pointer-driven ABI for thread intercommunication? I think Windows XP has that.
rhodan: ;)
rhodan: I think it does the register reorderswapping itself, on the track-zero PCB. But I'm not sure :P
rhodan: If kwin runs smooth by disabling direct rendering in sysemsettings (with r300g), is that a kwin bug?
rhodan: +compositing, of course.
melkor: Can I use stream computing with the open source drivers?
MostAwesomeDude: Not at the moment.
RAOF: Something screwy's happening in radeon_dri2_frame_event_handler - when GL clients go away (most easily reproduced by flicking between screensavers in gnome-screensaver-preferences) all sorts of Xserver crashes are getting triggered.
melkor: It looks like they're moving past stream to opencl anyways.
melkor: Which my card will never handle.
RAOF: https://bugs.freedesktop.org/show_bug.cgi?id=29310 is the bug I'm seeing.
RAOF: I'm not familiar enough with the preconditions for radeon_dri2_frame_event_handler to be called to go further than the simple, other-problem-exposing patch attached there.