airlied: glisse: any reason radeon_object is so secret (i.e. not in a .h file?
airlied: it kinda a pain to add tiling I end up with lots of parameters added to lots of functions
Tatsh: uh
Tatsh: is this normal?
Tatsh: OpenGL renderer string: Software Rasterizer
Tatsh: from glxinfo
Tatsh: direct rendering: Yes
crdlb: Tatsh: only when you have no 3d acceleration :)
Tatsh: i have none
Tatsh: like, Qt's demo openGL apps are reporting i have no support for PBuffers and all the 3d stuff runs but EXTREMELY slow
nha: in this context, Direct rendering: Yes means that the software rasterization is done in the client
nha: well, that's expected with software rendering
Tatsh: so, how can i fix it?
nha: enable hardware acceleration?
nha: what hardware do you have?
Tatsh: ati radeon xpress 200m
Tatsh: i can post my xorg.conf
nha: you shouldn't need an xorg.conf
nha: everything should just work automagically for this card
nha: unless your distribution messed up or you made some manual changes that broke something...
Tatsh: nha no but i did change my xorg.conf a few days ago
Tatsh: because xinerama was not enabled
nha: oh
Tatsh: with that enabled, a bunch of things act strange
nha: I don't think xinerama is properly supported with all the new stuff
nha: what do you need it for, anyway? can't xrandr do what you need?
Tatsh: xrandr worked okay if i only want to use my laptop monitor
Tatsh: but i usually connect to an external
Tatsh: and what happens is KDE (3.5) gets the data from X server (whatever functions etc) to find out available resolutions
Tatsh: in my xorg.conf i have 1440x900 manually
Tatsh: yet KDE only thinks I can go as high as 1280x800 (my laptop's LCD)
nha: okay, some observations:
nha: 1) maybe try starting the X server without xorg.conf
Tatsh: then, apps like Firefox for example only think i have 1280x800 pixels available starting from the top left, they will maximise to full size but say like full-screen Youtube, 1280x800 starting from the top left
nha: 2) check if you can setup your monitor properly using the "xrandr" command-line tool
nha: 3) if it works fine with the xrandr tool (and it most likely will), please talk to the KDE people to fix their tools
Tatsh: hold on
Tatsh: what do you mean setup? i thought xrandr was temporary
nha: historically, I've also had some crappy experience with the desktop environments' resolution setup tools
nha: well, xrandr settings are lost once you restart the X server, that's true
nha: but you can always just run the xrandr tool again
nha: and if you can configure your monitor with the xrandr tool but not with the KDE GUI, then clearly it's not our fault ;)
Tatsh: well i mean it was okay to use xrandr but still the issue was KDE not receiving resolutions the same way xrandr is
nha: that's a KDE bug, then
Tatsh: xrandr could see i had a monitor attached (VGA-0) and that its maximum resolution was 1440x900, NOT 1280x800
nha: good
Tatsh: so i guess i have to go back to no xinerama enabled
Tatsh: ?
nha: yes
nha: and please talk to the KDE folks to fix their software
nha: because if xrandr reports the right resolutions, then clearly everything is working correctly on the X.org side of things
crdlb: I have a feeling that kde 4.x might work better in that respect
nha: I would sure hope so - kwin in early 4.x was totally broken wrt multiple monitors, I do hope they got their act together
Tatsh: i'm afraid they don't care about kde 3.5 anymore
Tatsh: but i do plan on updating soon
Tatsh: just don't know if i trust the PIM to migrate my settings correctly, definitely keeping a backup of ~/.kde
Tatsh: nha how does this explain the ff issue?
Tatsh: ff is querying incorrectly too?
crdlb: is this with xinerama?
nha: ff?
Tatsh: firefox
Tatsh: this is with xinerama disabled in xorg.conf
nha: since I've never seen a screen resolution feature in firefox I can't really comment :}
Tatsh: Option "Xinerama" "false"
Tatsh: or should i simply not have it there at all?
nha: that should be fine, although as I said, if you really have a modern X.org, you shouldn't need any xorg.conf at all
Tatsh: you mean that literally the file can be missing?
fpoibaf: to r300 developers: sauerbraten segfaults with current mesa git. Worked fine a week ago.
fpoibaf: Renderer: Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX/SSE2 TCL (DRI R300 Project)
fpoibaf: Driver: 1.4 Mesa 7.6-devel
fpoibaf: WARNING: No framebuffer object support. (reflective water may be slow)
fpoibaf: WARNING: No occlusion query support! (large maps may be SLOW)
fpoibaf: WARNING: Non-power-of-two textures not supported!
fpoibaf: Rendering using the OpenGL 1.5 assembly shader path.
fpoibaf: init: console
fpoibaf: sauer_client: radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed.
fpoibaf: Aborted
fpoibaf: I can do a bisect if needed, maybe tomorrow.
MostAwesomeDude: Hm.
MostAwesomeDude: I'm seeing three warnings that we shouldn't be seeing.
fpoibaf: MostAwesomeDude: I always got the 3 warnings. What's the problem?
MostAwesomeDude: fpoibaf: FBO and NPOT warnings really shouldn't be there.
MostAwesomeDude: Unless...
MostAwesomeDude: fpoibaf: Are you on KMS or non-KMS?
stikonas: this is non-kms according to renderer string
MostAwesomeDude: stikonas: Will it include "KMS" if it's KMS?
stikonas: it will include DRI2
MostAwesomeDude: Well, if it's DRI2-enabled.
MostAwesomeDude: I wonder if DRI1 radeon-rewrite has FBOs...
stikonas: MoseAwesomeDude: no
stikonas: at least it shouldn't be enabled
Tatsh: i'm waiting for many things on my hardware but still i plan on upgrading before end of summer
stikonas: FBO's doesn't work for me even with DRI2
fpoibaf: MostAwesomeDude: I am on non KMS
MostAwesomeDude: fpoibaf: Ah. Not sure then.
MostAwesomeDude: You should definitely bisect.
fpoibaf: OK, I'll try tomorrow
Tatsh: okay restarting X with new options
Tatsh: namely Xinerama is commented out in my xorg.conf
rah: MAKE IT BE GOOD
rah: *cough*
airlied: glisse: btw also probably want to look at drm_calloc_large
airlied: for any big kmallocs
airlied: esp at runtime
nanoki: make working=userspace,kernelmodules
nanoki: Hrm. :)
nanoki: guesses if working means compilable, lots of stuff is fully working =^_^=
glisse: airlied: radeon_object is secret so underlying memory manager can change
glisse: but we can have a public part to radeon_object
glisse: i just would like to keep all ttm_ into 2 files at most
airlied: it a bit of a pain as I need access o the object size, current offset into VRAM (not MC address) tiling flags + pitch
glisse: there is function for that
glisse: but we could compute those value once when object is validated
glisse: why mc address doesn't work ?
airlied: surface regs don't take MC addres
glisse: i don't remember tiling needing offset in vram rather than gpu offset
airlied: you don't remember surface regs then :)
airlied: first mistake I amde the last time I wrote this code
glisse: anyway bottom line is to keep memory manager isolated :)
glisse: so when do you want to set surface reg ?
glisse: at gem_map time ?
glisse: if there is free reg
glisse: airlied: btw you are not working on fixing fb ?
glisse: just to know, so i do patch to convert it to pinned front buffer
glisse: btw Linus patch to catch bad pte might be helpfull with my sis bug :)
glisse: i definitly need to become more familiar with the inner of linux mm
suokko: airlied: I think this allocation error while having heavy IO is sometimes hard locking y system: http://pastebin.com/m31bf06dc
glisse: suokko: it's likely not a hardlock you can ssh right ?
suokko: No I can't
suokko: But I I use wpa encyrpted wlan witout hardware wpa support so if userspace is locked I lose networking
suokko: Also sys rq doesn't work
suokko: I'm compiling kernel and I get a few allocation failures all the time
suokko: Also queston: Why drm&ttm seems to have duplicated cache flushing code?
glisse: what is duplicated ?
glisse: where ?
suokko: drm_cache.c and ttm/ttm_tt.c
suokko: Only minor difference but I don't know ow important that is: call to wbinvd()
glisse: drm_cache is for intel
suokko: But it looks like same code except that one call in end
airlied: glisse: convert it to pinned, fixing fbdev is a bigger job than i'll get to in this kernel cycle
glisse: airlied: i was not implying fixing the whole fb
airlied: I've got a patch to merge the caching flushing
glisse: just fixing radeonfb of kms
glisse: airlied: btw does your drm-linus branch supposed to boot ?
airlied: no we can't fix just that, have to overhaul of fbdev to do locking
airlied: glisse: I don't have a branch anymore, its all merged
airlied: still no luck on rs690 > 4GB pages
glisse: i am saying i am converting to pinned buffer that's what i mean by fixing
airlied: glisse: yes thats the best fix for now, I haven't done it yet
airlied: I was tooling around on powerpc today, eventually got it to boot my custom kernel
airlied: kms dies on the rv515 I had in it
glisse: well i am trying to fix builtin boot but no luck
glisse: now trying to make firewire debugging working
airlied: any ideas whats its different than intel?
airlied: you have any serial conolse?
glisse: no serial on my motherboard
airlied: if you want I can play with that instead
airlied: I have a serial debug setup a twork
glisse: and i loose my serial null modem
airlied: you can do the keep Linus happy patch :)
glisse: anyway now kernel doens't even boot for me without modesetting or radeon
glisse: it stops at rtl
airlied: I'm generally just running Linus tree and hacking on top of it
glisse: been 3 hour i try to understand why linus tree doesn\t
glisse: boot
airlied: I started tiling hacks on my laptop, so it booted for me earlier
airlied: rtl?
glisse: network
airlied: generally I just search lkml when it doesn't boot and hope someone else hit it first :)
airlied: glisse: btw you sure you're page issue on SiS isn't the same isuse?
glisse: happen without fbcon but i will check
glisse: it might be the fb issue
glisse: crap i got the feeling that this is the hd which is dying hard
glisse: what is the parameter to select the runlevel ?
glisse: jsut the runlevel number right ?
suokko: yes
airlied: yup
suokko: I guess I was late at moving from ext3 to ext4. Now my desktop is a lot smoother while compiling kernel :)
suokko: But still allocation errors in radeon_cs_parser_init
airlied: yeah I suspect we need ot use drm_calloc_large
airlied: kmalloc ing > 1 page isn't a good idea
airlied: once the system is running
suokko: What about irqs? Are they disabled while allocating?
glisse: irq doesn't matter here
glisse: irq path doesn't alloc memory
airlied: nope, hopefully we don't GFP_KERNEL in an atomic, but should be okay
suokko: I was just thinking that all backrtraces tht I saw had included some irq handling before calling radeon ioctl
airlied: probably some stuff on the stack
Zajec: glisse: have you done any r6xx/r7xx KMS work locally?
Zajec: i know about your drm-next
Zajec: (r600-kms-wip branch)
glisse: no i am working on issue on r1xx-r5xx
Zajec: ok
Zajec: thanks
AndrewR: suokko, hello. my crash/oops shortly after loading radeon from recent git kernel was related to PAT in some ways. At least disabling PAT makes agp mode work. Slow, but not crash.
suokko: AndrewR: And I jsut try to compile kernel with PAT enabled to check if it provides better performance for cache control of pages
muep: Are there still important pieces of R600/R700 docs missing, or has AMD released the required documentation for developing OpenGL drivers?
glisse: muep: documentation is available
glisse: but you don't write a driver in 1 month
muep: I know those things
muep: I just wondered if the released documentation which has been coming available bit by bit, is already sufficient
glisse: documentation + various code drop is enough
Zajec: feels we miss AtomBIOS parser for power stuff
muep: nice to know
Zajec: there are tables in BIOSes:
Zajec: 000f: ae6c Len 0185 Rev 04:01 (PowerPlayInfo)
Zajec: we can't read
AndrewR: i found simple way to mask PCI devices with fakephp (there should be more modern way for doing this, according to modinfo fakephp). just echo 1 > /sys/bus/pci/devices/_dev_number/remove. And echo rescan > /path-to-host-bridge/rescan enable all of them back.
AndrewR: i was thinking about laptops wajt two gfx cads, but later realised what they may need more magik (output routing, power managment ....)
AndrewR: *with
AndrewR: **two. time to clean up my keyboard
Zajec: i would like to understand idea of CP ring
Zajec: should I read http://en.wikipedia.org/wiki/Token_ring ? it seems to be about network ring...
suokko: Zajec: CP ring is just a command stream where is write and read pointers running in a large array
suokko: And that is used so that driver writes commands for GPU to array and increments write pointer. Then GPU reads same array starting from read pointer and increments read pointer
Zajec: hm, ok, but then how does int radeon_ring_test(struct radeon_device *rdev) work? can you explain
Zajec: WREG32(scratch, 0xCAFEDEAD);
Zajec: radeon_ring_write(rdev, PACKET0(scratch, 0));
Zajec: radeon_ring_write(rdev, 0xDEADBEEF);
Zajec: what is this scratch register?
suokko: It is GPU register where PACKET0 writes DEADBEEF
Zajec: oh, ok, scratch sounds simple then
suokko: scratch register is just a register that can be used for driver functional purposes and it doesn't do anything graphics related in GPU
Zajec: but why do we make two writes? is this something always needed, or specified operation of this test?
Zajec: ah, i thought first answer was about scratch... ok, understand it now :) (scratch)
suokko: This is just test. So WREG32 makes sure that scratch register is initialized to known value and PACKET0 then is testing if CP works (so that after packet is processed register has changed value)
Zajec: ah, so we tell CP to write "0xDEADBEEF" into scratch registers which contains "0xCAFEDEAD"... and if scratch registers changes, CP is working
suokko: And that packet format which is used in CP array is detailed in r300 documentation
Zajec: simple! :)
suokko: yes :)
Zajec: many thanks for explaining :)
Zajec: these things are always so simple since you understand them ;)
suokko: yes. There is just too many simple things in GPU so combination is complicated ;)
Zajec: i somethimes wonder if well documented functions is something we want...
Zajec: would be nice to have for new developers
suokko: yes. I think that if you sent a patch adding comments to mailing list they would be accepted ;)
suokko: And that code commenting is great way of learning where everything is :)
Zajec: will seriously think about this :)
Zajec: sure it is :)
nanoki: airlied: Btw, any idea what "invalid ROM contents" from radeonfb might be a sign of?
nanoki: Comes on boot on my G4 + r300.
Zajec: what for we need to handle IRQs?
suokko: GPU can use IRQs to notice driver that now it has done the work requested by driver
suokko: Idea is that you fill CP with a lot of work to do. The last packet in stream is asking GPU to send the IRQ (ans possible some flag too) which driver then waits for (if some opengl function requires synchronization)
nanoki: suokko: I assume you need MSI enabled in kernel for the IRQ's to work properly, right?
nanoki: (At least for PCI express cards)
suokko: I don't know about that kind of technical details ;)
suokko: And I don't have PCIe hardware
suokko: Evil screen corruption in FF :(
nanoki: PCI express cards don't have an IRQ pin.
suokko: It went of after I scrolled but there were cyan boxes all around the screen
suokko: boxes=different sized regtangles
nanoki: Though you get a virtualized pin if you have MSI support on.
nanoki: (Also MSI is far superior to the traditional IRQ pin in terms of design)
nanoki: suokko: But yeah, this is low-level and people shouldn't have to care about this, distro maintainers should set the kernels up.
suokko: But anyawy. mesa radeon driver supports irqs and busy/short sleep waiting of GPU finnishing
suokko: Seems like screen corruption was caused by kernel memory allocation failure in radeon :(
suokko: anyway. I have to boot to new kernel :)
suokko: *Crossing fingers*
suokko: [ 24.451367] Xorg:2936 conflicting memory types db5a9000-db5aa000 uncached-minus<->write-combining
suokko: [ 24.451375] reserve_memtype failed 0xdb5a9000-0xdb5aa000, track uncached-minus, req uncached-minus :(
nanoki: Oh, lol. The laptop card is rv350, not r300. :) That's probably a comfort...
nanoki: (Actually says RV350 4E56 to be exact)
nanoki: Anyone got any idea what the latter part signifies?
glisse: nanoki: it's r300 family
nanoki: glisse: Yeah, I just thought it was the actual original r300 chip.
nanoki: Happy to realize it's at least a bit newer. :)
glisse: iirc 9500 is the original r300
glisse: and it's a bit rare
nanoki: This seems to be 9200.
nanoki: Hrm.
suokko: 4E56 is PCI id
nanoki: Right.
nanoki: ponders whether that multi-GPU thing could be useful with OpenCL
nanoki: tries to get r6xx-rewrite to work by loading r6xx-r7xx-3d on a Fedora stock kernel. Should theoretically work with the nomodeset option. :)
Zajec: nanoki: r6xx-rewrite isn't anything really working
nanoki: Zajec: Working as in not get kernel segfaults.
nanoki: This is kernel compatibility testing, really, nothing much more. Just checking if it only lacked the nomodeset option.
nanoki: (Mostly because I hate compiling my own kernels)
nanoki: Egh.
nanoki: Didn't work. :) DRM and radeon still got loaded because of some dependency.
nanoki: (Or because of initrd, whichever. Meh, I'll stick with custom kernels for testing then)
suokko: It would be nice to know why cache options for pages are so expensive with ttm in my system
suokko: In PCI mode it is a lot better but not acceptable (If cache handling takes over 30% of CPU time something is badly wrong)
suokko: But then again who knows about why that cache operation is so expensive and have to be done so often :(
glisse: suokko: it's simple AGP is not cache coherent so you have to use uncached memory
glisse: thing is we allocated/deallocate lot of bo when doing rendering
suokko: yes. But why not have some pool allocator in ttm to keep cache options same?
glisse: and there is no pool of uncached page, so ttm got to change cache policy of allocated page
suokko: :)
glisse: and changing cache policy of a page is costly (especialy on smp config)
suokko: I think it would give very nice performance boost at least in my system if having some pool alocator keeping memory with correct cache options
glisse: we will add a pool at one point
glisse: pool code is already in fedora 11
suokko: I guess I could experiment how much faster pool alocator is
suokko: ok :)
suokko: goes anyway coding pool allocator for fun ;)
logari811: on a M26/RV410 card with mesa from https://launchpad.net/~xorg-edgers/+archive/radeon I get this:
logari811: vdrift: radeon_common.c:1016: radeon_validate_bo: Assertion `radeon->state.validated_bo_count < 32' failed.
logari811: SIGABRT detected, releasing the mouse
logari811: Segmentation
logari811: what does it mean? is there any fix for it?
suokko: logari81: Have you installed some special kernel?
logari81: suokko: nop, 2.6.28 jaunty stock
suokko: Is vdrift program that caused the problem?
suokko: 45min download time :(
MostAwesomeDude: Hm. Can't understand why there's still BO counting problems in classic Mesa.
logari81: suokko: yeap vdrift is the game caused the error
suokko: MostAwesomeDude: There is at least in r200 driver still some buggy code
suokko: logari81: Can you get backtrace from asertion failure?
logari81: suokko: if you give me a tip how to do it, I can try
suokko: What do you usually use to launch the game?
suokko: You can add "gdb --args" before it
suokko: After a moment gdb stops just before game should start running. Now you have to tell it run with command "r" (or "run")
suokko: btw, Remember to set game to windowed mode
suokko: And then game will stop after assertion failure and you can type "bt full" to console
suokko: Also one useful point. It helps a lot if you install debug symbols for libgl1-dri package :)
suokko: Package which provides debug symbols is "libgl1-mesa-dri-dbg"
Zajec: if i don't use KMS, linux uses vesafb for setting my console, right?
Zajec: or radeonfb... ? how does it work, which one is chosen?
suokko: modinfo radeonfb :) There is list of pci ids that module supports
Zajec: and btw. what is vm? like: static void r600_vm_init(struct drm_device *dev)
suokko: virtual memory? virtual machine? :) No idea
Zajec: suokko: radeonfb doesn't containt my PCI ID
Zajec: # cat /proc/fb
Zajec: 0 VESA VGA
Zajec: so... vesafb is used
Zajec: ?
suokko: yes
Zajec: does vesafb manually sets PLLs? like ref_div, fb_div, frac_fb_div, post_div?
Zajec: or does it sets mode in some other, magic way?
mjg59: It calls the video BIOS
Zajec: ahh :(
mjg59: Well. vesafb doesn't. The mode is set at boot time.
mjg59: Then vesafb just uses the framebuffer address it was given
Zajec: but moment... using vesafb (video BIOS) I can still read current values of ref_div, fb_div, frac_fb_div, post_div, right? using some manuall tool I mean
Zajec: I mean... video BIOS touches ref_div, fb_div, frac_fb_div, post_div registers, right?
mjg59: Yes
Zajec: bingo :) I can now check what values uses video BIOS and what values KMS calculates :)
mjg59: On recent radeon hardware the vesa entry points probably call into the bios's ATOM interpreter anyway
Zajec: mjg59: if so, it does it in some better way that we do in KMS :)
Zajec: KMS causes flickering for my R6xx
nanoki: As in the framebuffer-only stuff?
Zajec: nanoki: hm? :)
nanoki: (Was under the impression it's not expected to work with X)
Zajec: nanoki: i just try to start clean console, not X
nanoki: Yeah, so framebuffer. :)
logari81: suokko: vdrift locks my keyboard and mouse so I have to kill gdb before I can generate the bt, any tip?
suokko: logari81: wait a sec
nanoki: doesn't care enough of framebuffer so he'll only try once someone says it can start X again :)
suokko: logari81: Create a while like this: http://pastebin.com/m1a6e2e8c
suokko: name it as "debug"
suokko: and in same directory where yo uwill start the gdb
suokko: and then you can run "gdb -x debug -batch --args ..."
suokko: And then you can copy the gdb output to pastebin :)
logari81: suokko: http://pastebin.com/m15af4375
suokko: logari81: Seems like similar problem was fixed just a few days ago
suokko: But if you are using the latest version it should be fixed there
logari81: suokko: mesa seems to be 2 days old
logari81: libgl1-mesa-dri: Installed: 7.6.0~git20090620.3b08a43f-0ubuntu0tormod~radeon
logari81: libgl1-mesa-glx: Installed: 7.6.0~git20090620.3b08a43f-0ubuntu0tormod~radeon
suokko: logari81: yes. So I suspect that you have found a bug that may till be in git
suokko1: screen corruption&hard lock for me :(
_Groo_: hi/2 all
Arvoreen: So, I have a RV530 (X1600) card that I want to configure as 2 seperate screens (not 1 virutal across 2 monitors --- have that working already). However, no matter what I've tried, I can't seem to get it to work....
Arvoreen: http://pastebin.com/m25ef8a65 has a copy of what I think should be a working xorg.conf and the log file for the server when I try to use that conf
Arvoreen: can anyone point me in the right direction?
_Groo_: anyone was able to add modelines to xorg.conf using dri2/kms? i can only add modes through xrandr.. the xorg ones arent honored.
adamk: _Groo_, It used to work for me here. Haven't tried recently but I might be able to give it a shot now.
osiris_: suokko1: does r200 advertise EXT_fog_coord?
suokko1: osiris_: yes
suokko1: I think I have seen it working too
MostAwesomeDude: osiris_: Yep.
virtuald: _groo_: works for me in the monitor section
_Groo_: adamk: thanks adam, its broken for some time now...
_Groo_: virtuald: doesnt work here for my LVDS... i can add and use them throught xrandr, but putting them in xorg doesnt change anything
_Groo_: rs485, dri2/kms latest codes
nanoki: airlied: No DRI2 even with agpmode=-1. :/
suokko1: But now in mesa 7.6 it is at least broken
nanoki: Also got a kerneloops on boot with agpmode=-1, unsure if it's related.
_Groo_: for the curious among yourselfs http://pastebin.ca/1470104
_Groo_: virtuald: dri1 or dri2?
_Groo_: brb
adamk: _Groo_, You are right.
adamk: It shows the modelines in the log file, but they are not available via xrandr.
adamk: Oh wait. Ignore that. I'll have to wait till I get home to check.
adamk: I was running 'DISPLATY=:0 xrandr' (which the typo) so it was still reading from the server I am currently at.
adamk: _Groo_, Alright, I just tested it... Fedora 11. Works as expected here after all. I added a modeline to the monitor section, restarted X, and it shows up as an option.
adamk: _Groo_, Try removing the modes from the Display SubSection, and merge them from the Modes section to the monitor section, just in case.
adamk: Sorry... merge the modelines from the modes section to the monitor section... But you probably figured that's what I mean.
_Groo_: adamk_: actaully i didnt, could you give me an example? :D
_Groo_: adamk_: merging the modes doesnt do squat
ernstp: should the driver manage the fan speed on my 4770 or should some card bios do that?
ernstp: seems quite a bit louder in linux than on windows but it's not running on 100% either
ernstp: maybe it just the lack of normal power management?
suokko1: ernstp: Have you set the power management options in xorg.conf?
ernstp: I think that depends on DRI and I have to disable DRI, but I haven't tried actually
mcgreg: as far as I know the radeon card have a hardware control over their fans?
ernstp: mcgreg: thanks
ernstp: restarting x
mcgreg: hmmm it is just as far as I know :) I am not 100% sure ... where is bridgman when you need him? :)
ernstp: :-)
ernstp: guess it's lunch in america
mcgreg: he is american?
mcgreg: no idea about that
ernstp: well they all work in canada or something, don't they?
mcgreg: no idea
Zajec: could someone explain me cp vs. ring, r100-r500 vs. r600?
Zajec: 1) r600_cp.c (no KMS) contains r600_cp_init_ring_buffer and r600_do_init_cp
Zajec: 2) r100.c (KMS) contains r100_cp_init only
spstarr: mcgreg: all you need to do is say...
spstarr: bridgman, someone needs your help :)
spstarr: mcgreg: stay on channel, idle, he will reply to your question
mcgreg: and he will appear, out of ntohign? :)
nanoki: Zajec: Hmm, maybe some additional abstraction layer somewhere?
spstarr: mcgreg: he tracks the irc logging
mcgreg: oh cool ;)
spstarr: this seems to be a unique #radeon trait :)
spstarr: and -hd
nanoki: spstarr: After which he'll be busy for some time reading the whole backlog. :P
mcgreg: I guess grep helps him ;)
spstarr: hehe
glisse: Zajec: for kms ignore r600_cp.c layout
spstarr: glisse: any r6xx for me to begin testing?
spstarr: KMS w/ r6xx?
glisse: r600_cp.c is for "old" radeon drm infrastructure
glisse: spstarr: no r6xx kms is at the bottom of todolist
spstarr: oh, ok
glisse: and todo is big
Zajec: glisse: so copying code from r600_cp.c to r600.c is bad idea? I wanted to fill "r600_cp_init" in r600.c this way
Zajec: i don't think way of initializing CP changes whether we use KMS or not...?
nanoki: Wouldn't you also need to implement the memory manager?
Zajec: nanoki: for now I skip MM part ;)
Zajec: nanoki: I was told MM in KMS is needed because many apps may want to access GPU in same time...
Zajec: nanoki: as long as I try make console only working, that shouldn't matter I think
Zajec: (no X)
glisse: Zajec: before cp we need to have mm & fbcon working
glisse: then cp
glisse: then cs
glisse: oh and before cp but after fbcon irq
Zajec: hm, ok, so I should play with mm & fbcon
Zajec: glisse: can I find any docs about radeon's MM?
Zajec: any explaination for start would be nice
Zajec: the best would be starting what we need MM for :)
glisse: my wip branch have the begining of that
glisse: then as a start use a memcpy copy function
Zajec: yes, i know it
Zajec: (branch)
glisse: see radeon_ttm.c for memcpy function
glisse: well setting copy,blit in asic callback should work
Zajec: > grep -c memcpy ./radeon_ttm.c
Zajec: 3
glisse: things is explaining how to do it takes me longer than doing it :(
Zajec: yeah, that's a problem for new developers :/
glisse: if my wip branch compile than it should be able to do fbcon
glisse: but i think it's buggy
Zajec: glisse: could you maybe just sum up what for we have MM and why r1xx MM isn't enought for r6xx?
glisse: best thing to do is try to debug until fbcon work
Zajec: glisse: i got errors because lack of cp... that's why I wanted to fix that first
Zajec: and black screen with little flickering on bottom (bad PLLs?)
glisse: forget about mm, code will fallback to memcpy, for hw accel bo move we need a lot more work
MostAwesomeDude: Zajec: Summary: r6xx+ work a bit differently WRT DMA and CP.
glisse: don't try to load X
glisse: just load fbcon
Zajec: i don't ! :)
glisse: if you can see console then you can start worrying about cp
Zajec: glisse: do you mean I should load fbcon somehow manually?
glisse: better to have fbcon as a module
nanoki: glisse: Do any other devs besides you know enough to explain what it needs? :)
Zajec: for now I was just starting system and waiting for results (black screen after moment)
glisse: Zajec: you likely need to load it by hand
glisse: depends on how its compiled
glisse: and other voodoo factor
Zajec: MostAwesomeDude: ok, so if CP is different on r6xx I understand we need other cp_init... but don't understand MM changes needed for r6xx :) anyway glisse just told I should ignore that until I get fbcon working :)
MostAwesomeDude: Zajec: Yeah, I can see the convo. :3
nanoki: Probably a good point, debugging MM will probably be insanely more convenient with fbcon. :)
Zajec: will just check fbcon for start
Zajec: is there some way to have in dmesg name of every function of fbcon/drm called?
Zajec: something like logverbose 7 for X
Zajec: so I could track what is started when
suokko1: Zajec: modinfo drm
suokko1: But debug isn't going to split out every function call
glisse: Zajec: modprobe drm debug=8
glisse: or add drm.debug=8 to kernel bootline
Zajec: ok, added it to modprobe.conf
glisse: or echo 8 > /sys/modules/drm/parameter/debug
Zajec: :)
Zajec: is going to check what he hacked
Zajec: does kenel boots in threads? can I disable it if it does?
Zajec: that's because I added many "mdelay(3000);" but don't see difference :)
glisse: there is an upper limit to mdelay value
Zajec: ahh :P
glisse: above which the kernel ignore the mdelay
glisse: it's platform dependant i think
Zajec: lol, never would think abouth that
glisse: mdelay 50 usualy is long enough to give time to printk to happen
Zajec: glisse: mdelay 50 is... 0.05 sec...i won't see DRM_INFO output before something breaks my display ;)
Zajec: and I try to understand which command breaks my display :)
glisse: Zajec: on loading kms will likely reprogram enough reg so that vga console isn't viewable anymore
Zajec: err, so that is expected?!
glisse: Zajec: yup
Zajec: so I need load fbcon to get console again?
glisse: tail -f /var/log/message through ssh is the way we proceed
suokko: Zajec: You should delay loading drm/radeom modules untill you have root filesystem mounted in rw mode
glisse: i pretty much hacking through ssh
suokko: Then you can save it to a file and view without modeset
glisse: best to do is to load radeon module once the system is booted
Zajec: ok, i'll blacklist it
Zajec:
glisse: Zajec: yes you need fbcon to get console again
Zajec: thanks
_Groo_: hi glisse
_Groo_: could you please check why i cant set modelines in xorg.conf with my rs485? i can only add them using xrandr... and xrandr by default only shows me one modeline
glisse: _Groo_: their are bugs in edid reworks
glisse: patch are underway
_Groo_: glisse: im using mesa master, drm master, but your drm-next for kernel, and i cant use xf86ati kms branch for now... gives me beautifull stripped boxes
_Groo_: glisse: could you pllleasse keep updating your drm-next? 2.6.30 is very unstable on my machine for now
nanoki: _Groo_: drm-next implies "going to get merged to main kernel tree".
_Groo_: nanoki: unfortunatelly linux staging tree is way to unstable on my machine... and i dont have enough knowledge to cherry pick the drm/radeon bits
_Groo_: and port it back to 2.6.29
nanoki: _Groo_: You don't need the *whole* of the staging tree?
_Groo_: nanoki: and how do i backport the radeon parts
airlied: run Linus tree is usually the best way to test
_Groo_: airlied: i cant... for now it brakes some lvms and my eth5k :( i can only use glisses tree
_Groo_: airlied: the rest is cutting edge though...except for xf86ati which is broken in rs485 (stripped sqaures on x start and then crash)
nanoki: airlied: D'you reckon I'd have better or worse chances of getting the PPC r300 to work with pre-2.6.31 git snapshot than with F11 stock kernel? ;P
airlied: nanoki: in kms
airlied: ?
nanoki: Yeah.
airlied: f11 kms doesn't do ppc
airlied: so only linus tree does
_Groo_: airlied: rs 485 fbos? :) cookie awards!
nanoki: Oh. :)
airlied: _Groo_: it on the list
nanoki: airlied: Right, off to play with Linux tree then.
airlied: its just not near the top
_Groo_: airlied: will be in mesa right?
airlied: _Groo_: the work on my other chips
_Groo_: airlied: how about modelines that wokr in edids? i cant modeline using xorg.conf, only xrandr :(
airlied: so not sure why 485 is different
_Groo_: airlied: because everything is hard with this shitty card :P
airlied: sounds like X server issue
airlied: well fbo code is the same for all cards
_Groo_: airlied: well i added the modelines to monitor section, also tried using section mode instead, no use, no modelines.. using 1.6.99.1
airlied: use xrandr/
airlied: ?
_Groo_: airlied: http://pastebin.ca/1470104
_Groo_: airlied: xrandr works but i loose the config after a Xrestart :(
soreau: I sometimes add an xrandr command to X startup somewhere
_Groo_: soreau: its the way to go unfortunatelly :(
soreau: What's unfortunate about it?
_Groo_: soreau: its a ugly hack.. X should be able to detect modelines correctly
_Groo_: airlied: without FBOS, wow doesnt work with directx ;)
_Groo_: airlied: neither do virtualbox directx or vmware workstation
_Groo_: airlied: opengl works fine tough
nanoki: _Groo_: Does anything you mentioned actually *not* use Wine? ;)
Zajec: glisse: after hacking radeon_device_init to not fail because of lack of CP/irq/etc I can modprobe radeon and modprobe fbcoc... after loading radeon I get black screen flickering on bottom and after modprobing fbcon I loose any backlight
Zajec: glisse: how can I debug this?
Zajec: also I get error: Jun 22 23:04:19 linux-aodr kernel: [drm:drm_helper_initial_config] *ERROR* connectors have no modes, using standard modes
Zajec: but it shouldn't be so critical to turn off backlight... right?
nanoki: Hmm, are we recommended to enable "Lots of debug output from Radeon driver"? ;)
airlied: thats not in the radeon driver
airlied: you don't want radeonfb
nanoki: Oh? Oops.
nanoki: Right. Now it's sorted out.
nanoki: Gneeh, Linux kernel git doesn't like my CPU. :)
glisse: Zajec: laptop ?
glisse: Zajec: if drm have no proper mode for your screen on laptop you wont see thing
glisse: is it with linus tree merged into my r6xx wip ?
glisse: if so edid need to be fixed
glisse: patch are underway afaik
Zajec: glisse: yes, laptop. PANEL without EDID
Zajec: glisse: hooray !
Zajec: glisse: i've something to hack now ! :)
Zajec: glisse: actually it's linus tree with your patch manually applied
glisse: Zajec: well hopefully edid will help you can also try to hardcode your panel videomode into mode detection
glisse: get if from xorg
Zajec: glisse: radeonhd is not able to get EDID as well, it uses ATOMBIOS_GET_PANEL_MODE, rhdAtomLvdsGetTimings to get mode for my PANEL
glisse: got to go
Zajec: glisse: thanks for your whole help
suokko: Lucky me that kernel stack is zeroed in boot :)
bridgman: mcgreg; sorry about the slow summoning, still no IRC at the office
bridgman: unless I cheat and I'm supposed to set a good example ;)
bridgman: I don't know if it's 100% but certainly "most" radeon cards have fan controllers
bridgman: I guess it's possible to put a small quiet fan, run it at 100% all the time and save a buck or two on the fan/temp controller but I haven't actually heard of that happening
bridgman: most of the boards have a single chip that reads temp and controls the fan
bridgman: there's a diode junction on the chip wired out to a pin; temp/fan chip uses that to determine temp and set fan
bridgman: there's a bit of programmability but we haven't dug into it much yet
bridgman: the sequence is kind of "basic power management, then finish 3d, then more power management, then some video stuff TBD"
bridgman: and apparently we need interrupts in there somewhere ;(
bridgman: so am I talking to myself or what ?
airlied: bridgman: you get that query I sent about rs690?
bridgman: yes, started digging through the code today to figure out who to ask
bridgman: I assume you want "how it really works", not "what we documented" ?
airlied: yes the real world is much nicer :)
bridgman: I think Alex already sent you all the docco we had so I didn't bother looking for more...
bridgman: ok, will do; probably tomorrow
airlied: yeah I wrote the code from the docs so I suspect lies or stupidity
bridgman: they're all in Toronto anyways
airlied: I'm just trying to rule out lies firt
airlied: first
bridgman: it's not lies or stupidity, it's cannonball
bridgman: opening line from the movie... "Wassa' behind me, it donna' matter"
bridgman: we wrote docs, we made a chip, it works
bridgman: then along comes the open source project ;)
airlied: bridgman: I suspect the driver has a big don't allocate > 32-bit memory in it :)
airlied: like who actually uses PAE :)
bridgman: it's possible; there have been some interesting things happening around the 4GB mark, although it could just be coincidence ;)
bridgman: in theory we're good above 4GB; I know we are with XP and it uses the same memory manager code
airlied: like the PTE entry looks like its good for 40-bits on the rs690, just doesn't seem to actually do what I expec though
bridgman: there's usually a trick discovered during bringup, fixed in the driver code and not put back into the hardware docs ;)
bridgman: we'll find out
AndrewR: airlied, anything simple i can test about broken cubemaps on r200/dri2 right now? (there was some debug env. variables for radeon driver, just not sure what exactly can be helpful ...)
AndrewR: bridgman, hello (not very useful message, but you aren't talking to vacuum here)
airlied: AndrewR: not really if the simple mesa tests can reproduce it then its just a matter of fixing the code
bridgman: tx ;)
suokko: What can cause kernel error telling that paging request can't be handled?
AndrewR: suokko, like this? Jun 21 05:42:14 (none) kernel: X: page allocation failure. order:4, mode:0xc0d0
airlied: suokko: running out of memory :)
AndrewR: i think this patch from glisse was about allocation problem: http://article.gmane.org/gmane.comp.video.dri.devel/36522
suokko: That was caused my own hacked version of TTM manager
suokko: And it as page alocation failure this time
AndrewR: suokko, hacked as run completely uncached? or something more exotic?
suokko: uncached was disaster ;)
suokko: But now I tryed to write pool allocator for pages which might reduce caching setting changes
airlied: suokko: there is an allocator already written
airlied: in rawhide trees
suokko1: BUG: unable to handle kernel paging request at f883d029 :)
airlied: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_page_alloc.c;h=73a3c6da7f25c6e1ca3233590f14dcca98de38f2;hb=drm-rawhide
airlied: it works quite well for rawhide but has some possible information leaks in it
suokko1: I did implement it using static arrays (I jsut wanted to see how much pool allocator might speed up everything)
airlied: it speeds up everything a lot :)
airlied: thats why I wrote one in rawhide
AndrewR: airlied, xrandr
AndrewR: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096 (i don't think my rv280 can handle such big screen with acceleration at least currently)
bridgman: I don't think it can handle 4k x 4k unless the refresh rate was very slow
bridgman: there's a maximum around 2kx2k or 2560x2560
bridgman: but think about 2K as a practical max, I think
airlied: 3D maxes out
airlied: but 2D can do it:)
bridgman: 2560 ?
airlied: 3D goes to 2560 I think
suokko1: And because non-power of two textures aren't supported max texture is 2048
AndrewR: sorry, i just run xrandr --rotation under KMS and it gives me black screen. I kill X - and logs was spammed with ------------[ cut here ]------------
AndrewR: WARNING: at lib/list_debug.c:26 __list_add+0x27/0x5c()
AndrewR: Hardware name: MS-6380E
AndrewR: list_add corruption.
AndrewR: tons of this. time to update my kernel, i think
suokko1: airlied: Where is list functions implemented?
AndrewR: (and i hope new kernel will fix my nfs bug(s), at least some nfsd commits look very interesting)
airlied: AndrewR: include/linux/list.h
airlied: AndrewR: was there some drm functions in the backtrace?
AndrewR: airlied, it fills full dmesg http://pastebin.ca/1470546 but from quck look - no, not drm-related. just massive corruption.
AndrewR: new kernel compiling ... (i'm fine with git kernels ..until they ate my hdd :))
suokko1: pool->pages[pool->size++] = ttm->pages[i]; <- This line caused kernel failing :/ (If I understood objdump correctly)
suokko1: airlied: drm_put_page should clear pages that are going to free list so no information could leak with uninitialized memory locations. Later given back to use.
airlied: suokko1: thats the plan
airlied: memcpy on uncached memory would be slow
airlied: but if its mapped write combined it actually mighht not suck so much
suokko1: Is it possible to use GPU for nvram clear?
suokko1: I mean is it practical and fast :)
airlied: for the uncached memory using the GPU might actually be faster than the CPU
airlied: but you'd have to try to see
suokko1: And it could be different story in another machine
suokko1: But if that memory isn't going to be required soon memory clear could be just queued for CPU and page would be ready for use only after GPU has cleared the page.
suokko1: But then again GPU might in very high use and that would just add too much extra work for GPU