wsnelr: It looks like I got much farther with loading radeon.ko on my diskless Radeon 2400 HD Pro system. I basically had to make sure /sys was mounted so the firmware files would load, and udevd for good measure. The message I get now was listed the other day with an answer to upgrade to a newer version (git repo perhaps?) where it is fixed, but perhaps someone can remind me. It says radeon kernel...
wsnelr: ...module verson is 2.0.0 but verstion 1.17.0 or newer is needed. And then Acceleration initialization failed a bit later.
DanaG: ah, that's userspace having been built without KMS.
Ghworg: Hmmm, suspend appears to be broken and not having tried for a few days I have 246 commits to bisect :-(
gellmar: checked yesterday kms modeset
gellmar: colour vertical stripes across the screen
gellmar: with a square instead of mouse pointer :(
gellmar: why does this appear?
gellmar: should I patch the RadeonDRIGetVersion?
airlied: did you read the message
airlied: either you are using kms with a non-kms driver
airlied: or you didnt load the kernel module beofre X started
gellmar: no, I haven't read
gellmar: connection faulted
gellmar: so I was kicked off the channel
gellmar: and... if you mean in Xorg
chithead: gellmar: your xf86-video-ati is not kms capable. disable kms or compile kms capable ddx
gellmar: yes I read
gellmar: which parameter should I specify?
gellmar: to enable it?
gellmar: in autogen.sh
chithead: kms will be compiled in automatically if libdrm_radeon is detected
chithead: watch for configure message about kms
wirry: hmm...did i get it right: glsl is enabled by default when using git-master? so i can remove enable_glsl_test... in my cflags?
chithead: only for r600 I think
wirry: well then im good to go ;)
gellmar: chithead: config.log says xserver-xorg is 1.6.0
gellmar: so I need to build newer one from source?
chithead: xserver version is mostly irrelevant
gellmar: the result is no
chithead: you need libdrm built with --enable-radeon-experimental-api though
gellmar: 2.4.16-git built with radeon
chithead: pastebin config.log
gellmar: that;s for driver
chithead: hm ok, seems that libdrm 2.4.16 wants xorg-server 1.6.2
gellmar: how to load the driver before x?
gellmar: of coz I can rebuild the server
chithead: if you have framebuffer console before X starts, then the module is already loaded
gellmar: how to check that?
chithead: whether you have text console or framebuffer is obvious if you look at the monitor
gellmar: everything is in text mode
gellmar: I mean normal text console
chithead: if you are in text mode then radeon kernel module is not loaded
gellmar: how can I check from logs if it is loaded or not?
gellmar: currently I have only SSH access
gellmar: 5 min
gellmar: is here
gellmar: chithead: so I need to rebuild xorg-server?
GoGi: does 6.12.4 include kms support for r700?
soreau: If I had to guess, I would say no
gellmar: rebuilt radeon with KMS flag
gellmar: no messages about xserver-xorg
gellmar: but what can I do with loading radeon and drm kernel modules?
gellmar: they definitely don't want to be loaded at boot
gellmar: modprobing drm and radeon manually from console gives black screen...
uyf: hi everybody i'm wondering if someone could help me with a problem, i compiled a kernel from arlieds drm-2.6.git, from branch drm-radeon-testing and now the kernel hangs at boot, i'm using the generic kernel config from my distribution with slight modifications (radeon modesetting on by default) . what could be causing this?
soreau: uyf: Does it make a difference if you boot with nomodeset ?
uyf: soreau: no i haven't tryed i should just pass the option modeset=0 to the module or what?
soreau: No, just add nomodeset to the kernel parameters
soreau: This will disable kms altogether
uyf: soreau: aha i will try that, thanks
uyf: soreau: i booted without modeset and it worked, but it seems my problem was that i hadn't compiled built in drm driver.
soreau: That can present a problem indeed ;)
uyf: strange the fbcon module is missing now too, after recompile. i must have messed up my git clone
soreau: If you compiled FRAMEBUFFER_CONSOLE into the kernel, it wont show as a module
uyf: sorueau: yes i did, i'm a little confused since i reinstalled slackware and i didn't save any config files
uyf: soreau: but i shouldn't use CONFIG_VGA_CONSOLE=y, right?
uyf: soreau: nm i figured out what i did wrong now
soreau: VGA_CONSOLE=y shoudnt be a problem
uyf: soreau: weird i have to try and reboot with new kernel, hope kms works now
edgecase: could tickless kernel cause r100 slowdowns?
spreeuw: edgecase: where do you experience them?
rehabdoll: hum, linux doesnt install R700_rlc.bin for me, where can i find it?
BioTube: rehabdoll: http://marc.info/?l=dri-devel&m=125960757404659&w=2
Droste1: ach das kann ich nich glauben :-)
rhodan_: Firefox locks up X while loading a big image. Steps to reproduce: Open Firefox, load http://whatimg.com/images/16523761854358315700.jpg; ?????; Lockup!
rhodan_: Doesn't lock up with Chromium
rehabdoll: rhodan_: works for me
rhodan: I'll compile it myself. Perhaps that makes it better.
legend2440: does anyone know if the open source drivers will work with Radeon x1950xt to get tv out working with ubuntu karmic? open source drivers work fine except for tv out and amd has stopped supporting this card
adamk_: legend2440: When you ran 'xrandr' does it show any options for the S-video output?
adamk_: legend2440: http://www.x.org/wiki/radeonTV suggests that you can enable tv-out with a few xrandr commands, in fact.
legend2440: adamk_: yes i have tried them and yes xrandr shows S-video output but all i get is snow when i try to play an avi on tv
legend2440: here is a script i use when playing avi movies
legend2440: xrandr --addmode S-video 800x600
legend2440: xrandr --output S-video --mode 800x600 --set tv_standard ntsc
legend2440: xvattr -a XV_CRTC -v 1
legend2440: /usr/bin/mplayer -vf eq=0:0 -aspect 4:3 -fs "$*"
legend2440: xvattr -a XV_CRTC -v 0
legend2440: xrandr --output S-video --off
legend2440: it worked great in intrepid but ever since jaunty i get no tv out
adamk_: Can you just enable s-video and use it as part of your extended desktop, though?
legend2440: in jaunty they upgraded xorg-xserver to 7.4 and thats when it stopped working
legend2440: yes well i get output to tv but its just snow
adamk_: Alright, so it's not the playing of a video that causes the snow, but simply enabling the s-video port. When you did this in Intrepid, were you using the open source driver?
legend2440: no when i used intrepid amd was still providing the fglrx driver so thats what i used
adamk_: So we don't know if this ever worked with the open source drivers, for you. Have you tried updating your drivers to see if a newer version works properly?
legend2440: well just the standard ubuntu upgrades that karmic provides every once in a while
legend2440: the open source drivers work great for everything even compiz but not for tv out
legend2440: with karmic
adamk_: Unfortunately, I don't know how up-to-date karmic is. You might want to check if there is a PPA (https://launchpad.net/ubuntu/+ppas) that includes a newer driver.
legend2440: adamk_: ok i will do that thank you
adamk_: If that still doesn't work, you can hang out on here and wait for one of the developers to chime in. Or open up a bug report.
legend2440: adamk_: ok thanks or maybe i'll ask Santa for a newer video card. one that amd still supports
bridgman: legend2440 is already gone ?
seb_: hi everybody
AndrewR: Found one BUG .... modprobe radeon benchmark=1 gives me this: http://pastebin.ca/1721400
AndrewR: videocard = 01:00.0 0300: 1002:5964 (rev 01) (prog-if 00 [VGA controller])
AndrewR: Subsystem: 1787:5964
adamk_: bridgman: Apparently. What's the trick to getting tv-out to work in that case?
bridgman: going from memory here, but the key points seem to be :
AndrewR: bridgman, hi. Looks like evil AGP strikes (me) again ...
bridgman: - devs are still working on tvout but 5xx seems to be the least cooperative
bridgman: - I *think* composite was working better than svideo, not sure if svideo worked at all but airlied or agd5f would know better
edgecase: AndrewR, you using the ubuntu ppa pkgs?
bridgman: some of the changes over the last few months were pretty significant, so picking up fairly recent master has to help
bridgman: the last major fix I saw was end of Aug, probably too late for Karmic
edgecase: i had to use the PPA pkgs for xorg-edgers, karmic KMS dunnut werk
AndrewR: edgecase, no, self-compiled everything (kernel from drm-linus up to r1xx-r5xx compressed textures fixes)
edgecase: the drm-radeon-testing branch is the place to be, IMO
bridgman: AndrewR, kms or no ?
bridgman: never mind, looks like kms ;)
AndrewR: bridgman, kms
bridgman: crashing or corruption ?
kimf: Is there a way to get compositing enabled without writing an entire xorg.conf? Using the xf86-video-ati driver on an r520 card
edgecase: kimf, i think you want xf86-video-radeon ?
bridgman: ati is a wrapper, it should load radeon automatically
edgecase: as long as you have radeon installed
edgecase: just saying
adamk_: kimf: Is there a problem you are having? Xorg should automatically use the radeon driver and "just work"
AndrewR: http://pastebin.ca/1721406 (/var/log/messages from same time frame .... it forces AGP to PCI but still crashes in benchmark mode, and probably some of my black screens caused by same (invisible) oops? )
kimf: adamk_, compositing doesn't seem to be enabled
adamk_: kimf: So let's start at the top.... Do you know if 3D acceleration is working? Checking the output of 'glxinfo | grep -i render' should tell you.
kimf: adamk_, have direct rendering. Need the OpenGl renderer string?
adamk_: Yes please.
kimf: OpenGL renderer string: Mesa DRI R300 (R520 7109) 20090101 TCL DRI2
adamk_: So you're definitely using the correct driver, and even have DRI2 enabled.
adamk_: What is telling you that compositing isn't enabled?
kimf: gnome-do at least, and compiz doesn't seem to work either
adamk_: What distribution?
kimf: On Arch at the moment.
kkuno: kimf, 3d is enaled also with non root users?
adamk_: kimf: What's the output of 'LIBGL_ALWAYS_INDIRECT=1 compiz --replace ccp &' ?
kimf: adamk_, http://pastebin.com/m1ed98487
kimf: kkuno, current user is in the video group
adamk_: kimf: If that's all you get, that suggests that compiz started up.
kkuno: kimf, with arch compiz has not a good profile
kkuno: and maybe it's started, but without effects
kkuno: and without decorator
kimf: Ok then. Will play around a bit with compiz and decorators then. But still doesn't explain why gnome-do is saying compositing is not enabled
adamk_: kimf: Well, without compiz or another compositing manager running, gnome-do will complain.
kkuno: kimf, try this profile
kimf: adamk_, good point :)
adamk_: cairo-dock does the same thing. It needs a compositing manager to work properly. And, by that, I don't mean it just needs compositing enabled in Xorg.
kkuno: or simply try metacity with composite, if you have gnome
spstarr: ok i did a profile sysprof and glxgears
spstarr: top offenders:
spstarr: r600_dri.so: read_hpet??
kimf: kkuno, profile didn't seem to help much
spstarr: #2: read_hpet: self 4.28% total 4.28%
spstarr: something busted with hpet?
spstarr: turns hpet off
bridgman: what is hpet ?
kkuno: kimf, did you load it with ccsm?
spstarr: a timer
spstarr: bridgman: hey brb
edgecase: you running tickless kernel?
edgecase: bridgman, hpet is an alternate to 1980's PC timer chip
edgecase: it's also a prerequisite to a tickless kernel (dynticks)
kimf: kkuno, it works. Just missing decorator. :) Getting somewhere at least, and learning new things :)
kimf: How do you enable metacity with compositing?
spstarr: removing hpet gives me #2 offender
seb_: following this thread---> http://www.phoronix.com/forums/showthread.php?t=20484 i try to have KMS working on a R710 class chip
seb_: but i have many issues ....
spstarr: is this due to the power management stuff turned on?
bridgman: seb; what is the first issue ?
bridgman: I didn't think the current pm code hooked into acpi
bridgman: pretty much self-contained
spstarr: it sure seems to be
kkuno: kimf, open gconf-editor
spstarr: thats what the DRI is telling me
kkuno: apps --> metacity --> general
kkuno: composite manager
seb_: bridgman: mesa autogenerated tree from git://anongit.freedesktop.org/mesa/mesa doesn't build
edgecase: using oprofile?
spstarr: [ 16.619454] radeon 0000:01:00.0: power state changed by ACPI to D0
ghepeu: spstarr, cat /sys/devices/system/clocksource/clocksource0/available_clocksource
seb_: i use xorg 1:7.4+4 from debian
ghepeu: acpi_pm is the default clocksource if you disable hpet
ghepeu: (that is, the '80s timer accessed through acpi)
spstarr: acpi_pm_read() reads the ACPI timers
spstarr: turns that also off....
kimf: kkuno, ahhh Thanks :) That worked great. :)
edgecase: spstarr, what are you fixing, slow with KMS?
ghepeu: I'm not sure your pc is going to keep working if you do that...
spstarr: edgecase: IRQ stalls
edgecase: spstarr, ah, maybe i have the same problem
ghepeu: or, if you have another clocksource you're just going to see that as the top offender
spstarr: edgecase: which GPU?
spstarr: ghepeu: until i get it down to using just PIT? :)
edgecase: Radeon Mobility M7 LW [Radeon Mobility 7500] [1002:4c57]
edgecase: spstarr, if there is a stall, and CPU is mostly idle, it's *normal* for timer interrupt to be top user of CPU
edgecase: i don't think profiling is that useful for finding cause of stalls
ghepeu: yes, that 'top offender' is probably just a consequence, not the origin of the problem
spstarr: egbert: even rescheduled interrupts?
ghepeu: spstarr, you'd need to profile the gpu
spstarr: RES: 102153 107507 Rescheduling interrupts
spstarr: this is rising fast w/o reason
ghepeu: that wasn't possible one-two years ago, maybe now that we have a almost completely reworked infrastructure
spstarr: im using sysprof
kimf: kkuno, now I just need to get the compiz decorator working. At least I know that everything else is working. Thanks
spstarr: a kernel module that shows all kernel/userspace calls
ghepeu: yes, but if the problem is on the gpu, all you're going to profile is the kernel/userspace waiting
kkuno: kimf, emerald is installed? also, have you tried using fusion-icon?
ghepeu: in that case, the only calls you'll get are timers, interrupts and so on
kimf: kkuno, yup have emerald installed and also fusion-icon.
edgecase: could it be waiting for vsync ?
ghepeu: don't know. iirc the idea was to avoid stalling the gpu, but I don't know what effectively was implemented
kimf: kkuno, hmmm there it just started to automagically work :D Just switched between compiz, metacity and emerald and gtk-window-decorator and reloaded the wm a few times in between :)
Nezmer: "git archive --remote=git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git HEAD" gives me "fatal: The remote end hung up unexpectedly"
Nezmer: Is that expected ?
edgecase: Nezmer, you doing something special, instead of just git clone?
Neo_The_User: does anybody know when glsl 1.5 came out? was it in august?
Nezmer: edgecase: I don't want to clone. I just want to fetch a snapshot without using gitweb because I'm using a remote headless server
edgecase: i don't know how to do that, sry
Nezmer: edgecase: thank you for replying anyway
Neo_The_User: Nezmer: a snapshot of what? i can give you the link
BioTube: Nezmer: git clone --depth 1 should do it
bridgman: find the commit message for the code you want, should be links to snapshots there
bridgman: is that what you are doing ?
spstarr: well, turning off ALL the timers shows ;)
spstarr: poll_idle 88.42% total / self
spstarr: so we can eliminate it being a timer issue
Nezmer: BioTube: that seems to be the solution. thank you
edgecase: spstarr, what you want is to find the function that waits the most
spstarr: im not seeing a clear winner there
spstarr: #2 is the DSO itself at 0.80% self and 0.80% total time
spstarr: and the DRI is doing:
edgecase: i don't think a profiler is the right tool
spstarr: spin_unlock_irqrestore / kmem_cache_alloc_notrace and page_fault
spstarr: 3rd most offender is the r600_cs_parse() routine
spstarr: command submission
spstarr: memcpy() is #4:
spstarr: and there is radeon_bo_fault_reserve_notify()
edgecase: page_fault is suspicious to me + memcopy
spstarr: page faults are not fun
spstarr: all from memcpy() tree
spstarr: my impression was if there is any page faults in the DRM and buffer objects we get stalls
edgecase: what would be nice is a trace whenever kernel idle thread runs, what wchan D process are in
spstarr: edgecase: which GPU do you have? can you run with KMS to confirm this?
edgecase: something could invalidate PTEs unnecessarily? constantly putting them back
spstarr: if its an r6xx+
edgecase: spstarr, i have R100m :)
spstarr: you can tell me if glxgears shows stalls
edgecase: but everythying is painfully slow
spstarr: loads second life to really trigger stallouts
edgecase: how can i tell if i'm stalling?
edgecase: i'm thinking there could be performance counters, actually page faults are accounted by most unix kernels yes?
penguin42: Hi, I've got an RV710/HD 4350 and in my xorg.0.log it says: Detected total vidoe RAM=524288k, accessible=262144k (PCI BAR=262144K) - is that normal? The card does supposedly have 512M
edgecase: but the specific GPU cases could be counted separately, like in ttm_bo_vm_fault()
bridgman: penguin42; that's normal
bridgman: it's telling you that the CPU can only access 256M, but the GPU can access all 512M
penguin42: bridgman: Cool - out of curiosity, why doesn't it expose all the RAM?
bridgman: I think it's a convention in the PCI spec, not 100% sure though
spstarr: ok profiling with network
spstarr: let's see what the stall is coming from
penguin42: bridgman: Hmm odd, thanks
bridgman: until 64-bit became common you probably didn't want to expose more anyways, since every bit of vram exposed reduces the amount of address space available for system ram
penguin42: anyway, good job guys - this card seems to work fine on 2D in the Ubuntu Karmic set using the free drivers, and frankly the software 3d is as fast as the 3d on my old i945
spstarr: radeonEmitVec12() ?
bridgman: penguin42; you should be able to get hw accelerated 3D as well
spstarr: ok that routine is from secondlife
bridgman: although I guess you would need new kernel/drm as well as a new mesa driver
penguin42: bridgman: I was going to give it a go, do I need to rebuild the whole of X or just build the /usr/lib/dri/r600_dri.so ?
BioTube: penguin42: you'll likely need to rebuild libdrm as well as mesa
spstarr: bridgman: perhaps this is due to my HZ set?
bridgman: you need r600_dri.so plus new drm code; might be easiest to pick up a new kernel
bridgman: probably need a new libdrm as well, i'm losing the picture again these days
penguin42: bridgman: New kernel is easy, I'm already running the lkml git kernel; it looks to me like it doesn't have kms for the 7 series yet
bridgman: I think it does; 600 usually refers to 6xx and 7xx
bridgman: anyways, you don't need kms for 3d
edgecase: penguin42, try drm-radeon-testing kernel ?
bridgman: although you'll need kms + gem/ttm for gl 2.x
penguin42: edgecase: Ooh where do I get that?
penguin42: I'll probably get the kms anyway, I like it - and anyway it should be able to fit my penguins on the screen
bridgman: spstarr; what is hz in this context ?
bridgman: and what is all that high pass filter crap ?
spstarr: the system polling
spstarr: bridgman: im not sure why SL is using that
spstarr: but tl_decode_cblks() is triggering page faults
edgecase: penguin42, git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git ; git checkout origin/drm-radeon-testing
penguin42: edgecase: Thanks!
edgecase: spstarr, do these page faults require mapping vram or gtt or something beyond plain ram-backed pages?
spstarr: well, I have 512MB vram, DRM does not support more than 256 at the moment
penguin42: Out of curiosity, has anyone figured out if OpenCL can be made to work with these drivers?
edgecase: yes but does each page fault require some cache cohenrency CPU <--> GPU, which is costly?
spstarr: that, I'm not sure
bridgman: penguin42; it's being worked on, running over Gallium3D drivers, but I think there's still a bunch of work to do
spstarr: turns off MSI
penguin42: bridgman: Cool, still that's promising that it's being worked on - I'm in no rush, but I do fancy having a play with OpenCL at some point
bridgman: for now you probably should pick up the closed drivers and Stream SDK; that gives you OpenCL on both CPU and GPU
penguin42: bridgman: Yeh I'll get around to that sometime
bridgman: we also have an OpenCL implementation for CPU
penguin42: ooh - just found xorg-edgers - with prebuilt Xorg packages
bridgman: yep, that is handy
penguin42: well that seems to work - I got an odd crash out of gnome-panel during start up, and when I first zoomed in on google earth it all went rather white - but zoomed out and back in and it's ok and very fast
evil_core: hi,is it true that pageflip has been implemented for r500?
bridgman: or was it just implemented as part of adding irq support to 6xx/7xx ?
zjblabs: is xgl support available in the radeon driver?
BioTube: zjblabs: xgl is a dead project
zjblabs: BioTube, understood
BioTube: AIGLX provides all the capacity compositing window managers need
zjblabs: BioTube, if you say so
zjblabs: BioTube, however, does the radeon driver support xgl was my question
BioTube: xgl was an xserver based on opengl
zjblabs: does the radeon driver support it?
BioTube: if it doesn't need OGL > 2.0, it should work
zjblabs: thank you BioTube
spstarr: DRI is hitting 58.80% of total time
spstarr: dumps XML and logs bug
spstarr: maybe something in this will help the devs cause this just does not happen with no KMS and no IRQ
spstarr: i'll have to compress the XML it's 19MB
bridgman: spstarr, why do you care ? the time is just spent busy-waiting when there's nothing else to do
bridgman: it's really a time-reporting issue more than anything else
spstarr: bridgman: well, the stalls make playing network games impossible for example
bridgman: sorry, I read that wrong; thought you said "didn't happen *with* IRQ"
bridgman: never mind ;)
spstarr: ya only when IRQs on
adamk_: rnoland_: Were you able to reproduce the problem?
spstarr: it seems to be IRQ related removing some devices had 'lesser' stalls
spstarr: but im unconvinced
spstarr: reboots into no KMS
spstarr: bridgman: the simple test is this
spstarr: load glxgears full screen with KMS move mouse over the window (title bar) notice the stalls
spstarr: w/o KMS, do the same thing. no stalls
spstarr: looking at sysprof w/o KMS.. I see no memcpy() hits
spstarr: heavy offender is drm_ioctl() next is copy_user_generic_string()
spstarr: bridgman: the page faults with KMS (and IRQs) on is bad
spstarr: page_faults with non-KMS is very insignificant
spstarr: runs secondlife and does sysprof
evil_core: it measn I can make patch between 2.6.32 and drm-radeon-testing?
spstarr: bridgman: something doesn't seem right
spstarr: bridgman: if we have IRQ support why would the DRI get hit even more vs non-KMS?
bridgman: probably something isn't right ;)
spstarr: KMS w/ IRQ: self = 58.25 total: 58.80%
spstarr: non KMS: 12.15 total: 12.30%
spstarr: bridgman: seems very odd to me
bridgman: unless the KMS solution is giving higher performance through higher efficiency, in which case the CPU utilization could be higher
spstarr: I didnt notice any different in CPU util
bridgman: a perfectly optimized system would have 100% GPU and 100% CPU utilization when running the hardest workloads
bridgman: yeah, I wouldn't expect it
spstarr: bridgman: it would be nice to have a 'gputop' program :)
spstarr: I do notice that timers with KMS + IRQ seem to be more used vs non-KMS
spstarr: read_hpet is 0.11% call each time and non-KMS it is 0.02%
spstarr: irq storming or something going on?
spstarr: even the USB functions like ehci_work is higher with KMS + IRQ vs not
spstarr: bridgman: i know the IRQ code is quite hot still, so im sure there is bugs in it
evil_core: so kms+drm-readeon-next will drain battery quicker on r500?
bridgman: if you were using the power savings options on non-KMS, probably
bridgman: if not, probably no difference
evil_core: I got set them in xorg.conf, but not sure if were supported by driver
evil_core: I got 20-30 wakeups in powertop while idling
evil_core: on T60p
evil_core: dunno if it was good score
spstarr: what is TOTO
spstarr: (II) RADEON(0): TOTO SAYS 00000000cfff0000
spstarr: BIOS Bootup Message: ^M
spstarr: M86M DDR3 600E/700M
spreeuw: alices dog
bridgman: I always wondered about toto as well
bridgman: dorothy ? thought alice was from resident evil and those dogs didn't look like they had names
spstarr: yelps in pain
spstarr: ingrown toenail just got worse and infected a little :/
bridgman: soak it in salt water until you can get some good drugs
spstarr: got the polysporn on it
evil_core: what is IRQ, Interrupt...or something else?
bridgman: Interrupt ReQuest
bridgman: useful for a few reasons; sync-to-vblank, and knowing when memory buffers used for submitting commands can be freed up and re-used
gellmar: finally rebuilt the xorg-server
gellmar: and got a failure :(
bridgman: well, you're braver than me ;)
edgecase: so they used to sell those SSL accelerator cards for webservers... now CPUs are fast enought to not care, and/or nic has hardware ipsec... but what about GPU as an accelerator for webserver image accel?
edgecase: maybe resize images, or perhaps generate CAPTCHAs?
edgecase: with offscreen rendering, don't even bother with a framebuffer
bridgman: probably not enough work to bother; even a wussy GPU can resize 60 images a second for video playback
MostAwesomeDude: Yeah, this is already done.
bridgman: I guess for very high resolutions it makes sense; apps like Photoshop have used GPU acceleration for complex filtering for a while
edgecase: orly? neato
edgecase: i meant for webserver tho... various apache threads using GD library could submit commands to GPU
MostAwesomeDude: eosie: Ping. Reading through your revamped shader-matching code.
MostAwesomeDude: edgecase: Not with GD, no. You'd need something explicitly designed for it.
MostAwesomeDude: WSGI could be used to have an OGL context.
edgecase: right, it would take the place of GD
edgecase: basically PHP calls some_image_op() that is a native library... which submits to GPU, returns result
edgecase: presumably to/from mmap()'d buffers
MostAwesomeDude: TBH I really really really don't care about PHP.
edgecase: yeah it sucks, just thinking about use cases for GPU
evil_core: IRQ is for r500 also?
bridgman: or there would already be PHP=Gallium3D binding ;)
bridgman: yes, AFAIK all of the radeon parts support them
bridgman: but it sounds like the IRQ-driven pageflip may not be there from what you were saying earlier
evil_core: I need to include r600/r700 firmware in kernel for r500?
stikonas: evil_core: no
edgecase: is there a vblank driven pageflip, that doesn't use CPU interrupt? i mean, GPU handles it?
bridgman: the 6xx/7xx handle interrupts differently and require that a new block be initialized; 5xx and earlier didn't have that block
bridgman: the old overlay hardware used to have vblank-triggered page flip, and some of the CRTC registers can be set so that changes only take effect on the next vblank, but not sure if the CRTC mechanism can support pageflip
edgecase: i thought there was a CP command "wait-for-vblank"
evil_core: is it enough for r500 to apply it against 2.6.32, or should I really switch to newer kernel?
bridgman: I thought agd5f was polling a register rather than using CP; don't remember seeing wait for vblank in the PM4 packets
edgecase: kinda a waste of gpu idling for vblank tho, *if* you had some other work
bridgman: evil_core, I think those instructions should work - but if pageflip was only implemented for 6xx/7xx so far then not sure it will help
evil_core: bridgman: are you talking about phoronix post i posted link to?
bridgman: edgecase; yeah, double/triple buffering lets the GPU work ahead more, but unless the app is completely GPU bound the GPU is going to have to idle eventually
evil_core: ok, So I will try to recompile kernel with those patches
bridgman: I had been under the impression pageflip was implemented for all GPUs at the same time though, which was why I suggested newer drm in the first place
bridgman: a newer drm is probably going to be better anyways with all the work going on but not sure it will help with the specific issues you mentioned
bridgman: need to use the phone for a bit, bbl
Rabauke: hi, I've got a 4350. LIBGL_DEBUG=1 glxinfo gave me: libGL error: dlopen /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/xorg/modules/dri/r600_dri.so: undefined symbol: radeon_bo_is_referenced_by_cs)
Rabauke: and software rasterizer is used. can someone help?
Rabauke: i'm on 2.6.32 and using the today's git
BioTube: try rebuilding with the latest libdrm
Rabauke: I use latest libdrm
Rabauke: libdrm-git-20091220-1 libgl-git-20091220-1 mesa-git-20091220-1 ati-dri-git-20091220-1 xf86-video-ati-git-20091220-1
Rabauke: this is a nightly build repo
edgecase: is there something that multiplexes requests to GPU? say between Xorg and something else?
edgecase: or is xorg the thing intended to do that?
BioTube: i would've thought the drm
edgecase: would that handle 2 apps sharing GPU? not clobbering each other's buffers, etc?
BioTube: that's the point of KMS
edgecase: i mean i can run 2 glxgears at once, just not sure at what level things are multiplexed
edgecase: er, layer
da1l6: drm-radeon-testing modules panic on boot when KMS is enabled.
Zajec: could sb help me with my PM patch maybe-causing some issue? http://bugs.freedesktop.org/show_bug.cgi?id=25718
da1l6: NULL pointer dereference in ttm_bo_reserve+0x18/0x120 [ttm].
da1l6: Card is Mobility Radeon HD2600 (M76). With kernel 2.6.33 drm modules it boots fine.
da1l6: There doesnt seem to be any logs from this :(. I could try to take pictures of the screen, if that helps.
evil_core: Zajec: I can try it on r500 if you want
Zajec: evil_core: would be nice
evil_core: Zajec: I need apply it on kernel?
Zajec: yes, it wasn't commited anywhere yet
Zajec: evil_core: try this together with mentioned Atom patch
evil_core: Zajec: can you giff me links to patch files?
Zajec: report results on dri-devel@ or in https://bugs.freedesktop.org/show_bug.cgi?id=25718 in case you experience problems
Zajec: sure, moment
evil_core: I would add them to kenrel-desktop.spec and rpmbuild it
Zajec: http://email@example.com/msg45742.html http://firstname.lastname@example.org/msg45666.html
evil_core: I am rebuilding 2.6.32 with backported drm-next anyway now
GoGi: I have kernel 2.6.32 how do i enable kms for radeon?
BioTube: GoGi: radeon.modeset=1
GoGi: it is not possible to have this as default?
BioTube: yes, but that option's in staging(kms is officially experimental)
adamk_: GoGi: If you recompile your kernel and enable KMS by default in the staging drivers section :-)
evil_core: Zajec: which apply first?
Zajec: evil_core: both should apply fine
Zajec: evil_core: in any order
Zajec: evil_core: atom patch was created first
Zajec: you can apply atom patch firs
Zajec: but this wouldn't matter, i think
Zajec: evil_core: remember about setting dynpm=1
GoGi: and do i have to enable any frame buffer device for the text console?
evil_core: Zajec: about setting that I will by worrying, after succesfull rebuilding all including Mesa and kernel ;)
evil_core: so it will take hour or two probably
Zajec: i'm going afk watch some movie
GoGi: "Works is underway to provide support for R6XX, R7XX"
GoGi: so these do not work in 2.6.32?
BioTube: GoGi: they do
BioTube: nobody's updated the description yet
BioTube: and it's still not feature-complete
BioTube: (such as the power management discussion going on right now)
adamk_: GoGi: You need to enable the framebuffer console, but you should not enable any specific framebuffer driver.
evil_core: Zajec: anything interesting today in TV?
BioTube: Zajec: with a 3450(rv620?) and V7, your patch causes no problems
DanaG: ingrown toenail? ugh, had one of those -- or rather, TWO of those. the full treatment for it sucks. (sorry, was reading backlog)
DanaG: yeah, I'm off by, oh, about an hour.
evil_core: + < /home/users/evil/rpm/packages/kernel-desktop/kernel-desktop-kms-add-dynamic-engine-reclocking-V8.patch
evil_core: 1 out of 3 hunks FAILED -- saving rejects to file drivers/gpu/drm/radeon/radeon.h.rej
evil_core: 2 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/radeon/radeon_drv.c.rej
evil_core: 1 out of 3 hunks FAILED -- saving rejects to file drivers/gpu/drm/radeon/radeon_pm.c.rej
evil_core: atombios applied succesfully
evil_core: hmm...I didnt applied HDMI patch for 2.6.32, maybe it will help
evil_core: now only one line isnt applying, because I dont have default and current clocks printfs, only cimply clock
slon_: Hello guys :)
slon_: Maybe someone knows how to fix lagg in wine?
slon_: trying to play wacraft3 on a ati 3600 direct rendering is ON
evil_core: Zajec: any way i wrote middle patch, so it applied on 2.6.32 :)
muep_: slon_: what graphics driver are you using?
slon_: muep_: radeon 3650
nightmorph: is KenMays here? for the love of ##^@&, someone tell that guy to leave changelogs when he edits RadeonProgram
nightmorph: it's pissing me off to see invalid results and have to go reverting edits, much less trying to make sense of why something was done
twnqx: someone fix head to support suspend/resume again :X
nightmorph: but on the positive side, today's checkouts of mesa/libdrm/xf86-video-ati work nicely with xorg-server 1.8 snapshot 2 :)
nightmorph: urbanterror's lookin' good, as usual
mjt: agd5f: you know that the 18.104.22.168 -stable commit (500b758725314ab1b5316eb0caa5b0fa26740e6b) breaks at least some onboard vga cards...
mjt: here it broke amd780g (the system becomes unbootable)
nightmorph: hmm, what's a recommended setting for TCL mode in driconf? there's little documentation on it
nightmorph: something that won't break my x stack, that is
airlied: mjt: does drm-radeon-testing work?
airlied: wonders if a later commit fixed things
mjt: airlied: i just got to the discovery stage
mjt: tried to debug why 22.214.171.124 does not boot here
mjt: ok, what _is_ radeon-drm-testing?
mjt: git://anongit.freedesktop.org/git/mesa/drm does not contain that branch as far as i can see
BioTube: mjt: it's a kernel branch
mjt: aha got it
airlied: or linus 2.6.33-rc1
airlied: hasn't tried VGA on rs780 in a while
mjt: vga is wrong word probably (if that's a word :)
mjt: it hangs when loading radeon.ko modeset=1
mjt: "hangs" is wrong word too: the screen goes blank till reset, and apparently disk access is broken too
mjt: but it replies to pings and even shows sshd prompt
airlied: can you get dmesg from it?
mjt: well, maybe netconsole
airlied: you can't ssh in?
airlied: try ssh hostname dmesg
airlied: I've noticed sometime we can't get a tty when it hangs like that
mjt: no, that does not work either. it definitely hangs on any disk access after that, but it also hangs on some cached i/o
airlied: must crash holding bkl
mjt: that tty issue is when it can't create a pseudo-tty
mjt: so ssh -t should work (it just brings shell)
Nezmer: Are "R700_rlc.bin" and "R600_rlc.bin" available in any kernel tree or anywhere official other than mailing list archives?
mjt: sshd never accepts the login
mjt: but i've an idea
Nezmer: I want to package them for my distro
airlied: guesses it might require IRQ support or something for that patch to work
airlied: I'll have a look later today
mjt: Nezmer: what they're used for?
nightmorph: Nezmer: i ran into an issue when i upgraded to xserver 126.96.36.1991 where those disappeared -- everything fell back to software rendering
nightmorph: updating to xserver 1.8 and rebuilding the ati stack fixed that
mjt: bah. So I can't get dmesg even when loading the module when logged over ssh
mjt: next try is the netconsole
nightmorph: not really sure why the firmware was there in one version and gone the next and back again
Nezmer: nightmorph: I grabbed the firmware for a mailing list archive and it worked. But I want an official source If I want to package it
Nezmer: for = from
nightmorph: Nezmer: yeah, several gentoo and phoronix forumites reported having to the same thing recently. i just updated my git checkouts at the same time as the xserver update, and everything Just Worked(tm)
nightmorph: didn't have to get the firmware from MLs or bugzillas
Nezmer: nightmorph: What's weird, I don't see them under firmware on any tree. Can you search for their location If you still have the kernel tree around
nightmorph: Nezmer: what kernel tree? afaik it wasn't a kernel tree issue, but something shipped with mesa
nightmorph: i'm on .32 stable, not .32.3 or .33
nightmorph: i have no firmware trees in my kernel that i know of
nightmorph: but lemme poke around
nightmorph: ah, never mind, i know whatcha mean
nightmorph: i was thinking external firmware; lemme see here...
Nezmer: nightmorph: .32 stable shouldn't need them anyway but thanks for tip. I will till the users suffering from this.
nightmorph: Nezmer: huh, this is weird. i'm running the command to check which package owns all these RV7** firmware files, but it's not reporting anything
Nezmer: nightmorph: probably you grabbed them manually like me ;)
nightmorph: maybe some part of the x stack was requesting the wrong firmware filename, compared to what's actually in there?
nightmorph: i'm running a vanilla kernel source -- no additional patches, straight from kernel.org
nightmorph: and i haven't recompiled it in several days
nightmorph: Nezmer: like i told you a few times, i've never had to manually download any firmware images
twnqx: you have to, now.
Nezmer: nightmorph: I get that. I have no problem (although some users do). I'm just looking for an official source for the firmware files for future builds
twnqx: nightmorph: the old versions are installed by the kernel on "make install"...
nightmorph: Nezmer: check kernel.org's git tree, i suppose...
Nezmer: nightmorph: That's what I did before asking here ;)
airlied: is the offical src
nightmorph: thanks, airlied
Nezmer: airlied: thanks. But why aren't they included in .33 trees ?
airlied: Nezmer: firmware doesn't get included in the kernel
nightmorph: what about all these other firmware images?
airlied: unless it was already there
airlied: look at the wirless fws for example
nightmorph: all these RV710, RV770, etc. files
airlied: they were in the kernel and got converted to firmware files
nightmorph: (apologies for the gitweb spam)
Nezmer: airlied: hmm. So they will have to be shipped in separate packages. good to know
nightmorph: airlied: what's the reasoning for moving them out into yet another thing to fetch?
twnqx: annoying users
airlied: nightmorph: firmware isn't shipped with the kernel
nightmorph: it ain't? i thought there's always been some kinda firmware shipped in the kernel, even foss firmware
nightmorph: although...i do recall the qla2xxx firmware for sparc disk controllers getting punted...
airlied: nightmorph: firmware that were in the kernel stay there, new firmware get shipped spearate
airlied: all wireless fws aren't in-kernel
MostAwesomeDude: No new firmware's being accepted, and maintainers are being asked to move it out.
nightmorph: ah, okay. is this a new trend?
airlied: my distro just handles it
airlied: not really
nightmorph: for maintainability reasons, license reasons, or...?
airlied: all of the above
airlied: there is a linux firmware git tree with all of them in it
airlied: just need to get distros to package it
airlied: in FEdora I just shipped the fw with the DDX
nightmorph: well, i appreciate ya'll tellin' me. i imagine gentoo's future kernel ebuilds will have a few more SRC_URI lines for fetch magic
nightmorph: i'll poke dsd et al and see what they'll do for .33 and up
Ghworg: Debian has firmware-linux-free and firmware-linux-nonfree, so all the debian-derivs should pick those up
nightmorph: ubuntu will prolly write their own :p
nightmorph: unlike the nouveau thing that's going on, we don't have to worry about radeon fw being in the "nonfree" category, do we?
Ghworg: Radeon fw is nonfree under the debian definitions
nightmorph: debian also has a more restrictive take on things than gentoo
Ghworg: Gentoo has it easier since they don't host the files themselves (as I understand it), they just link to upstream stuff
MostAwesomeDude: Gentoo has the same policy as Debian, but Gentoo also doesn't mind "fetching" things at install-time.
bjaglin: airlied: hi, i just pulled drm-radeon-testing and tested your fix legacy rmx patch on my RV250. It did improve the situation for the non native resolutions, except surprisingly for 640x480 for which i get black screen without any warning... Is there something I can do to see what's wrong?
MostAwesomeDude: Gentoo's policy only technically covers the ebuilds.
nightmorph: Ghworg: true
nightmorph: it's all just scripts that fetch and compile for you, not actual repackaging
bjaglin: airlied, oh sorry, it was actually agd5f 's fix
airlied: bjaglin: wierd, 640x480 on my r100 works
airlied: bjaglin: can you try with --set "scaling mode" Center
airlied: just to see if it changes
slon_: Can someone give me a link on install the drivers? I have 188.8.131.52 kernel with XorgOnThe edge
airlied: will test on my rv370 laptop today as well
airlied: office &
slon_: anybody? :(
nightmorph: slon_: if that's on ubuntu and xorg-edgers, there are instructions on the ppa, and on google
MostAwesomeDude: airlied: FYI, I gave up on the rv410; RESYNC'ing the IBs didn't help. I went and bought a used rv580, and it's doin' great for me so far.
slon_: nightmorph: I installed them succesfully but I have 1.5 opengl and as I see there is 2.0 http://www.phoronix.com/scan.php?page=news_item&px=NzgyNQ
nightmorph: slon_: only if your card supports it
slon_: running 3650 so i think it should
nightmorph: slon_: did you read the rest of that? basically, opengl2 ain't really here because it still needs to be written for the rest of the stack
slon_: how to check is kms on?
maligor: you notice
maligor: it'll switch to a high res mode on module load
Ghworg: grep KMS /var/log/Xorg.0.log
nightmorph: slon_: grep -ir ks /var/log/Xorg.0.log
nightmorph: heh, Ghworg beat me to it
nightmorph: why did i throw the -r flag in there? never mind
slon_: (II) [KMS] drm report modesetting isn't supported.
bjaglin: airlied, it works as expected with 640x480 centered
nightmorph: slon_: it has to be enabled in your kernel, too
nightmorph: it's under the Staging drivers section -- "enable modesetting by default"
nightmorph: hmm, RadeonFeature lists HDMI Audio output, but what 'bout the status of just HDMI video from R700? that working okay?
slon_: what is KMS? and where in the kernel can I enable it?
nightmorph: kms = kernel modesetting
nightmorph: that's in the log snippet you posted
nightmorph: slon_: read around the Phoronix forums; bridgman has an excellent summary of KMS and how it relates to your desktop. heck, all the radeon/mesa/X devs have posted about it on the phoronix forums. they're all good reading :)
slon_: there is very much reading and very messed out :)
Ghworg: slon_: Boot with radeon.modeset=1 should enable it
slon_: and what are the benefits?
DanaG: weird... my Radeon 7500 has an unmarked, 26-pin header, "J5".
nightmorph: slon_: again, search for KMS among bridgman's post to find out what it is, what it does, and why it's good. your questions are already answered
Ghworg: VTs at native resolution
nightmorph: also, read the Feature tree at the bottom of this page: http://www.x.org/wiki/RadeonFeature
nightmorph: notice what KMS makes possible
nightmorph: slon_: here, read this: http://www.phoronix.com/scan.php?page=search&q=KMS
bjaglin: Zajec, i did some testing with the reclocking patch on my RV250 and found something strange when setting the clock quite low, are you interested?
slon_: a nice feature but nothing uber special
MostAwesomeDude: No, it's pretty special.
MostAwesomeDude: Without it, there's no memory management or DRI2.
MostAwesomeDude: Which means no Gallium and no GL 2.0.
hnsr: so i found out this bus error I keep getting is a problem unrelated to radeon
hnsr: sucks though, can't run 2.6.32 atm :(
hnsr: not the slightest clue either on how to debug it
evil_core: Zajec: drivers/gpu/drm/i915/intel_lvds.c:902: warning: passing argument 6 of 'acpi_walk_namespace' from incompatible pointer type
evil_core: include/acpi/acpixf.h:154: note: expected 'void **' but argument is of type 'int *'
evil_core: drivers/gpu/drm/i915/intel_lvds.c:902: error: too many arguments to function 'acpi_walk_namespace'
slon_: ok one final question where to enable it?
spreeuw: talking about memory management, why cant you use videoram above 256MB?
MostAwesomeDude: Because it's tricky to access for fallbacks.
MostAwesomeDude: glisse has been working on it though.
spreeuw: for the older cards you mean?
MostAwesomeDude: No, period.
MostAwesomeDude: Which is why we never used it pre-KMS.
slon_: where in that new grub is the option to enable KMS? cant find it
Ghworg: slon_: For grub2 in /etc/default/grub add it to GRUB_CMDLINE_LINUX I think
airlied: goes and busts the shit out of the API
airlied: welcome to recompile all your shit land
MostAwesomeDude: Which API?
spreeuw: slon_: its an option to kernel
slon_: that doesnt tell me much
spreeuw: title lfs
spreeuw: kernel /boot/bzImage root=/dev/sda1 radeon.modeset=1
airlied: MostAwesomeDude: libdrm
airlied: libdrm_radeon really
slon_: spreeuw: ?
nightmorph: slon_: go read the ubuntu docs for it
nightmorph: they've got stuff on how to enable it
spreeuw: oh the new grub
slon_: where to put this radeon.modeset=1 ? :D
spreeuw: thats a bunch of bloat
spreeuw: wait till its stable
airlied: sits back and awaits ppls pain + complaints
nightmorph: airlied: i welcome all pain in the name of progress
nightmorph: well, most pain
spreeuw: it will probably get redesigned 5x anyway so dont learn anything yet
MostAwesomeDude: airlied: Oh, I don't really care.
MostAwesomeDude: It shouldn't be too tough to fix up.
Ghworg: I was planning on switching to the packaged version of libdrm, I guess I won't be doing that then :-)
edgecase: so there could be 2 3d apps running, one with opengl, and the other with Direct3D submitting CP commands ?
nightmorph: ah, excellent
airlied: edgecase: yes
edgecase: i mean direct3d is an api that spits out CP commands, same as opengl...
edgecase: ok cool
airlied: there is no difference at the hw level
airlied: just CP commands
edgecase: i wonder what the wine people are doing for d3d
airlied: if you did a D3D state tracker for gallium that would work
airlied: they are doing D3D->GL conversion
airlied: since they have to deal with binary drivers
edgecase: yeah, ugly
mjt: airlied: I've a dmesg from the failing system. But nothing really interesting
airlied: its not so bad with newer GL
maligor: I think it'd be rather ugly doing a d3d state tracker too
maligor: elegant for the use purpose but..
airlied: D3D requires a lot of Windows API stuff
airlied: MESA is proposing an extension so the wine guys can bypass a lot of the GL stuff
airlied: and just stick a shader from DX into GL
edgecase: just pondering, that windows apps often use d3d api, so in theory then you could stick a d3d stack in wine, and have it spit out CP commands,
edgecase: and dri would keep it separate
airlied: it would have to be based on gallium or something similiar
edgecase: not just copy windows .dlls hehe
airlied: well I suppose you could write D3D->radeon hw but it seems a bit wasteful
MostAwesomeDude: Like cairo-drm.
edgecase: well the windows d3d core does 3d3 -> radeon, but the low-level of windows driver isn't dri now is it
mjt: airlied: http://paste.debian.net/54549/ -- that's all. There's no OOPS or anything like that, and I can't do anything else on the system, incl. sysrq (but ping works). 184.108.40.206.
edgecase: ok nm i'm just intellectually probing this new KMS toy you all made for us :)
maligor: I should imagine d3d would have a driver api
maligor: d3d ddi apparently
slon_: so like I've done modprobe -r radeon drm
slon_: modprobe radeon modeset=1
slon_: and I've got a black screen :(
DanaG: hmm, how about modprobe fbcon?
mjt: slon_: revert to 220.127.116.11
mjt: or maybe i'm out of context
mjt: apparently there's a broken commit in 18.104.22.168
edgecase: maligor, could use d3d core .dll and write ddi then, not sure it would save any work tho
slon_: reverted kernel KMS is on
slon_: warcraft3 still laggy
edgecase: slon_, winehq has an app db with all kinds of tweaks and hints
mjt: slon_: so was I right wrt 22.214.171.124 vs 126.96.36.199?
slon_: I know
slon_: It is not a tweak problem it is about the drivers, fglrx are good for wine gaming
slon_: but pretty suck for desktop use(compiz)
slon_: so will wait for 2.6.33 kernel and some major changes :)
Zajec: evil_core: i can't help you with problems with backporting stuff to .32
turmlos: airlied: Isn't Sunday the 20th? :)
spreeuw: yes it was
airlied: turmlos: oops, time travel confuses me
spreeuw: I recompiled today so I should be fine
spreeuw: the kernel I mean
airlied: you didn't read it then
spreeuw: it downloaded 10 meg of git pull
spreeuw: saw nouveau got in
airlied: does it mention the kernel
edgecase: which pkg breaks things? so i can avoid updating it for a few days
airlied: edgecase: all of them not the kernel
airlied: i.e. the ones in the goddamm topic
spreeuw: for irq you need a dev kernel
spreeuw: the userspace stuff I rebuild every day anyway
evil_core: anybody know working backport for 2.6.32?
spreeuw: evil_core: that dev kernel is stable enough to run for me
spreeuw: evil_core: if that was what you're asking, dunno if its planned for 32
evil_core: but I wanted to change kernel-desktop.spec file simply, to still got BFS/ToI patches, etc
GoGi: what exactly is gallium?
airlied: driver framework
airlied: for more info
evil_core: is there ToI and BFS for drm-readeon-testing?
edgecase: so ddx = xorg-driver-video-radeon ?
edgecase: so what is missing in newer radeon hardware, 2d blit engine?
BioTube: edgecase: the entire 2d engine
nightmorph: edgecase: R600 and up just have the 3D stuff
nightmorph: dedicated 2D engines are for older hardware, r500 and under
edgecase: heh now if they can get rid of VGA they'll really clean up the die space :P
nightmorph: down with BIOS, while you're at it
airlied: they mostly got rid of VGA from the core parts of the chip
edgecase: so does any of the up to the minute Power mgmt stuff take effect with R100?
nightmorph: alas, there's no such thing as a cruft-free design
airlied: its now a small block that renders txt mode-> graphics mode
airlied: and scans out graphics mode
edgecase: ah neat
nightmorph: edgecase: there's a page on that, RadeonFeature
airlied: the chips can't scanout text modes directly anymore
nightmorph: x.org/wiki/RadeonFeature, should have power mgmt status
edgecase: no more l337 bios fonts ;<
edgecase: nightmorph, ty
nightmorph: edgecase: if you're wondering how specific apps are doing, same link, but substitude RadeonProgram after wiki/
nightmorph: which reminds me, i'm going to kick that KenMays guy in the seat of the pants, as well as anyone else that doesn't leave changelogs
nightmorph: airlied: is it possible to get a lock on the wiki such that any nontrivial edits are REQUIRED to have something in the CL field?
airlied: nightmorph: no idea probably have to ask the freedesktop wiki ppl
nightmorph: airlied: that's what i thought, but i couldn't find any contact info. i was hoping that some radeon regulars 'round here might have powerz
edgecase: is RadeonFeature uptodate with past few days of fiddling tho? some of those features have different support status for KMS/non KMS?
nightmorph: edgecase: click the Log button at top right
nightmorph: edgecase: looks like an I
nightmorph: the glsl changes are in
edgecase: someone in here was working on KMS PM stuff, i'm curious if there's anything relevant to R100 i can test
edgecase: that page looks like PM stuff for user modesetting
nightmorph: power management should work in the nonKMS whatsit at least, for r100
edgecase: maybe a starting point would be a couple extra rows for KMS versions of features
edgecase: yes i've used DynamicClocks etc with UMS, it's the KMS i'm curious about
nightmorph: i'm only keeping up with r700 KMS power management; last i heard some more patches have been written, but haven't been pushed into mainline
nightmorph: dunno if those also apply to
nightmorph: kms is the future, so ums is getting more and more outdated/irrelevant
nightmorph: it's sometimes tough enough to keep one wiki page updated, let alone two :)
nightmorph: it's one of the reasons why radeonHD status was punted to its own page, though i can see your line of reasoning working for both sides
MostAwesomeDude: Actually, the reason I kicked rhd status off that page is because the page was otherwise too wide to fit on any of my monitors.
edgecase: doesn't have to be a separate page...
DanielHorne: Evening, guys..
edgecase: the first 2 rows are "DDX modesetting", and KMS...
nightmorph: MostAwesomeDude: heh, pragmatism ftw
DanielHorne: I've been doing a bit of work on FB acceleration for the kms stack
nightmorph: MostAwesomeDude: but it did seriously improve readability too, so don't discount that
edgecase: so just split off or make explicit if PM status is for ums or kms
edgecase: it's vague
MostAwesomeDude: Imagine UMS is bitrotting.
DanielHorne: One thing I haven't found a good explanation of: there appears to be two blitting functions - PACKET3_BITBLT_MULTI and DP_GUI_MASTER_CNTL
DanielHorne: Not sure which I should use.. any pointers?
edgecase: well, UMS PM works, KMS is WIP
edgecase: so, rotting sure...
MostAwesomeDude: It's not hard to do. Imagine there's no drivers outside the kernel, too.
MostAwesomeDude: Imagine all the legacy bits, slowly melting away... Whoo hoo, whoa yeah.
edgecase: also, old 2d xaa shows "done", but it's actually bitrotted, has visual glitches
airlied: DanielHorne: the packet3 wraps the other one
nightmorph: i think i've entered a blissful state of zen relaxation
edgecase: i have to use EXA on rv200 actually
MostAwesomeDude: DanielHorne: Which chipset are you working on? It might be good to read through the solid and copy EXA hooks in the DDX
DanielHorne: Oh, I see.
airlied: DanielHorne: radeonfb also has some accel already
airlied: which might be useful to port
nightmorph: edgecase: exa's not an option?
airlied: though I don't think we'll be turning accel on by default on fbcon
nightmorph: i didn't think anything used xaa anymore 'cept fglrx
airlied: due to it decreasing the chances of seeing an oops
edgecase: yes, exa works well on rv200, and xaa is broken
nightmorph: no one's maintaining xaa, are they?
edgecase: perhaps default should be changed to EXA
DanielHorne: Work I've done so far was on an r500, though I just upgraded to an 5770
nightmorph: default is exa on hardware that supports it
nightmorph: 'cording to my logs for forever
edgecase: except rv200...
nightmorph: oh? hmm
edgecase: it defaults xaa, and is broken
nightmorph: what's your software stack version(s)
edgecase: it's ubunt xorg-edgers, sec
DanielHorne: This is my first attempt at a radeon patch, so it's probably pretty ugly..
edgecase: X.Org X Server 1.6.5
edgecase: Release Date: 2009-10-11
nightmorph: edgecase: that's ooooold
airlied: DanielHorne: the 5770 will be a bit harder to deal with
edgecase: ah ok then... dix sets default to xaa?
nightmorph: or maybe ubuntu patches the hell outta stuff. ubuntu's practically rewritten everything, so i've mostly given up trying to triage it
edgecase: ok i'll try again with up to date xserver
nightmorph: also, what ddx/mesa version you using?
DanielHorne: airlied: Yeah - i see that the existing r600+ blit hooks need to use shaders, but I suspect I can reuse a lot of the code that's there for it.
edgecase: xserver-xorg-video-radeon 1:6.12.99+git20091215.3a30210d-0ubun
edgecase: hmm that looks like some bastard version
airlied: DanielHorne: I ithnk the main reason we don't use the PACKEt3 in some places it you can't control the blit direction with it
edgecase: heh i guess i should just use git
airlied: but for fbcon stuff it should be fine
_Groo_: hi/2 all
_Groo_: hey airlied\
MostAwesomeDude: I'm so saddened that r600 blits are actually needed in-kernel.
MostAwesomeDude: But I guess that's life.
_Groo_: hey MostAwesomeDude
_Groo_: guys, googlearth is crashing with latest dri2/ddx/drm/xorg
_Groo_: as usual, evil rs485
nightmorph: there's not a TODO or "help wanted" page for radeon besides bugs.fdo, is there?
edgecase: MostAwesomeDude, blits for scrolling?
nightmorph: like...any desire for documentation, etc.
DanielHorne: I see.. radeonfb only accelerated the copyrect and solid fill hooks, - enough for accelerated console scrolling. I figure that porting those over to the kms driver would be the best way to go. I'd have to customise the r600+ blit shader code though.
soreau: _Groo_: Have you built mesa, ddx and x against latest libdrm?
MostAwesomeDude: airlied: I'll fix up radeon gallium as soon as new libdrm hits F12.
MostAwesomeDude: DanielHorne: http://dri.freedesktop.org/wiki/R300ToDo
MostAwesomeDude: nightmorph: http://dri.freedesktop.org/wiki/R300ToDo
nightmorph: MostAwesomeDude: ty
airlied: MostAwesomeDude: it won't hit F12
airlied: since I can't break the API in a stable release that easily
MostAwesomeDude: airlied: Oh. Guess I get to be lazy for a bit longer. :3
_Groo_: soreau: yes i did
_Groo_: soreau: want a pastebin?
MostAwesomeDude: nightmorph: Not much documentation needs to be written, really.
airlied: MostAwesomeDude: I already fixed up gallium
MostAwesomeDude: Well, at least, not for the actual HW.
MostAwesomeDude: airlied: Good man.
nightmorph: MostAwesomeDude: alas, all that stuff is hardcore C/driver hacking, which i'm no good at
nightmorph: i couldn't C my way out of a paper bag. maybe a wet one, but not a dry one.
MostAwesomeDude: nightmorph: Neither am I. :3
nightmorph: lies! you're, like, the man
soreau: _Groo_: No. file a bug
nightmorph: or something
_Groo_: soreau: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
nightmorph: no one ever wants docs, 'cept for distro-specific howtos
chithead: _Groo_: your kernel is too old, upgrade to 2.6.32
DanielHorne: airlied: thanks for the info
_Groo_: chithead: im with 2.6.32
chithead: hm, ok
nightmorph: _Groo_: also see https://bugs.freedesktop.org/show_bug.cgi?id=23715
nightmorph: this may be your bug
MostAwesomeDude: nightmorph: Sure, I'm the man, but I'm not as wonderful at this stuff as it might seem.
MostAwesomeDude: Took me a while to really get into it.
_Groo_: nightmorph: lol im the one who filled the bug!
nightmorph: then you're to be doubly commended for stickin' with it. you and all the other folks who make this work for us lowly peons
nightmorph: _Groo_: if the bug's already filed...
BioTube: is the gallium pipe-state tracker interface actually documented anywhere?
_Groo_: nightmorph: no, its not the same, it worked before but rendered crap, now its crashing radeon!
nightmorph: BioTube: i found http://jrfonseca.blogspot.com/2008/04/gallium3d-introduction.html
nightmorph: and http://dri.freedesktop.org/doxygen/gallium/
evil_core: Zajec: anyway, I fixed it myself. dirty fix, but why should I care if i915.ko will eat my kitten if I use radeon ;)
MostAwesomeDude: Oh, that doxy's hilariously out-of-date.
MostAwesomeDude: I'm actually working on docs right now.
nightmorph: MostAwesomeDude: awesome
edgecase: so is 8bit depth deprecated ?
nightmorph: not for NES!
evil_core: SNES rulez!
evil_core: what should I do to got GLSL and pageflip for r500?
evil_core: only compile mesa with gallium and r300/radeon driver?
MostAwesomeDude: Pageflipping is in the kernel.
MostAwesomeDude: And it's not provided for any chipsets right now AFAIK.
evil_core: and what about GLSL?
evil_core: and fbo
DanaG: wonders randomly about "tdfx": does it have npot support? and TFP support?
BioTube: evil_core: GLSL is a major WIP for r300-family chipsets
evil_core: /usr/bin/ld: skipping incompatible ../../lib/libGL.so when searching for -lGL
evil_core: /usr/bin/ld: i386 architecture of input file `array.o' is incompatible with i386:x86-64 output
evil_core: I cannot built 32bit Mesa with gallium
evil_core: 6it and 32bit w/o gallium is not problem
DanaG: *********************************WARN_ONCE********************************* File radeon_tcl.c function radeon_run_tcl_render line 499 Rendering was 307 commands larger than predicted size. We might overflow command buffer. ***************************************************************************
DanaG: that's with compiz on Radeon 7500.
DanaG: hwinfo --framebuffer gives: Model: "ATI V200"
DanaG: no R.
airlied: DanaG: does compiz work though?
DanaG: yup, it works just fine.
DanaG: Surprisingly well for 64 megs of RAM. Well enough for me to not need the 9800 Pro in that box.
DanaG: I mean, compiz works... until it quits.
DanaG: I set "fallback WM" to compiz... so when compiz quits, it restarts itself.
DanaG: A reliable trigger seems to be the "showmouse" plugin.
DanaG: Wait, even just opening a window triggers it.
DanaG: hmm, hyperz is off by default.
_Groo_: DanaG: hyperz?
DanaG: DRM version 1.0 too old to support HyperZ, disabling.
DanaG: Just random curiosity there... not likely related to this command-buffer overflow thing.
DanaG: hmm, driconf lets me set command buffer size.
airlied: we ignore most of those
airlied: esp with kms
_Groo_: hey airlied could you take a look at.. http://pastebin.ca/1721863
eosie: MostAwesomeDude: anything you wanted to share about my shader-matching code?
evil_core: BioTube: it means it doesnt work?
BioTube: evil_core: I don't know, except that it's incomplete
airlied: _Groo_: what makes it hpapen?
airlied: sounds like you need a newer kernel
airlied: if its compressed texture related
_Groo_: airlied: googleearth as usual
eosie: doesn anybody happen to no what is RB3D_CCTL.CMASK_ENABLE for?
eosie: *does anybody happen to know what is RB3D_CCTL.CMASK_ENABLE for?
eosie: it enables cmask ram, what is it?
evil_core: LIBGL_DEBUG=verbose glxgears
evil_core: libGL: OpenDriver: trying /opt/xorg/lib64/dri/tls/swrast_dri.so
evil_core: libGL: OpenDriver: trying /opt/xorg/lib64/dri/swrast_dri.so
evil_core: xmoto works like shit
airlied: evil_core: you are using swrast
evil_core: $ xdriinfo
evil_core: Screen 0: not direct rendering capable.
evil_core: but why?
airlied: evil_core: pastein xorg log file
airlied: eosie:no idea
airlied: eosie: there are more CMASK regs up higher but the regspec I have is fairly light on details
evil_core: I wanted to use Gallium
evil_core: so I loaded KMS
evil_core: glxinfo says its direct rendering :/
BioTube: evil_core: you need to rename the built sofile
evil_core: xdriinfo not
BioTube: and the software renderer can do direct rendering
airlied: you also aren't using KMS
evil_core: BioTube: Never DRI worked with KMS for me
airlied: or the kernel module wasn't loaded before X started
evil_core: airlied: I am
evil_core: it wasnt
evil_core: but xorg loaded it with KMS
airlied: then load it before starting X
evil_core: so restart X simply now??
airlied: iot mgiht work
airlied: or X might have mangled your gpu
DanaG: or rather, "wedged" -- I take "mangled" to apply to hardware. =P
DanaG: Or mangled gpu state.
DanaG: "wedged" is a good word.
DanaG: Works even for explaining some things to non-tech-ey people.
soreau: 'X gave my gpu a wedgie!'
soreau: Certainly laymens terms
Ghworg: Suspend failure seems to originate from ca262a9998d46196750bb19a9dc4bd465b170ff7 "drm/ttm: Rework validation & memory space allocation (V3)"
Ghworg: Compiling a kernel with it reverted to confirm, though it didn't revert cleanly so I may have borked it
evil_core: airlied: right, xmoto works now wonderfully
DanaG: now... what can I do with tdfx (voodoo3)?
evil_core: no tearing at all
evil_core: but quake3 hangs :/
DanaG: Or rather, how do I get something to start at lower screen-resolution on one video card, so it can use DRI?
evil_core: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
evil_core: for ut2k4
evil_core: its dmesg
evil_core: tc-elite, equal error
Ghworg: Yes, it appears I did bork it. I'll try again :-|
evil_core: Ghworg: mine problem?
DanaG: [drm] GPU not posted. Posting now...
DanaG: when booting with pci voodoo3 as primary, agp rv200 as secondary, and radeon.modeset=1.
DanaG: sets agp as primary boot device.
DanaG: heh, when it comes to computers, I AM a bit masochist.
DanaG: (a bit? =þ)
evil_core: I got too old kernel drm modules?
eosie: hm enabling cmask ram doesn't break anything
DanaG: okay, it seems I can't use a non-xrandr-1.2 card with an xrandr-1.2 card.
DanaG: er, 2.1
evil_core: screen flickers sometimes
evil_core: Zajec: are still?
MostAwesomeDude: eosie: I had problems, then I read them, then everything was fine.
eosie: FWIW, BGRA ordering of vertex colors is broken since pipe-format-simplify was merged
MostAwesomeDude: I'll see what I can do.
MostAwesomeDude: What were you using as a test?
evil_core: LIBGL_DEBUG=verbose glxgears
evil_core: libGL: OpenDriver: trying /opt/xorg/lib64/dri/tls/r300_dri.so
evil_core: libGL: OpenDriver: trying /opt/xorg/lib64/dri/r300_dri.so
evil_core: so its using gallium or not?
MostAwesomeDude: glxinfo, and look at the renderer string.
DanaG: [ 0.317491] (WW) TDFX(0): Direct rendering is not supported when VGA arb is necessary for the device
evil_core: OpenGL renderer string: Mesa DRI R300 (RV530 71C4) 20090101 TCL DRI2
DanaG: hmm, weird... even though I'm not using the secondary card at all, it still demands vga arbiter?
MostAwesomeDude: evil_core: So you're not using Gallium.
DanaG: hmm, how do I disable this "vga arbiter"?
evil_core: MostAwesomeDude: so how to enable it?
MostAwesomeDude: evil_core: Take lib/gallium/radeon_dri.so from your mesa build dir, and rename/symlink it to r300_dri.so, then put it somewhere in your LIBGL_DRIVERS_PATH.
MostAwesomeDude: DanaG: You don't want to disable vgaarb, probably.
MostAwesomeDude: You probably want to disable the other card.
MostAwesomeDude: ...Although I admit, I don't know how to do that. I just take out cards I'm not using.
DanaG: yeah, I ended up having to do that.
evil_core: MostAwesomeDude: cannot I simply set some ENV VAR?
evil_core: and what is that for?
evil_core: but is it usable under X?
MostAwesomeDude: evil_core: LIBGL_DRIVERS_PATH only points to a directory; the name of the actual DRI lib is rather hardcoded into the DDX.
DanaG: ugh, damnit, integrated card is blocking DRI this time.
MostAwesomeDude: evil_core: Not without a bridge like egl_glx. If you don't know what EGL is, you don't need it.
DanaG: Will have to boot old, pre-vgaarb kernel!
MostAwesomeDude: DanaG: Which cards are these?
evil_core: I remember that EGL was usedunder Xgl, bu its dead
DanaG: Before: Voodoo3 and Radeon 7500.
DanaG: Now: Voodoo3 and S3 UniChrome.
MostAwesomeDude: Only the cards participating in vgaarb can't do DRI; radeons should auto-opt-out of vgaarb and DRI just fine.
MostAwesomeDude: evil_core: No, EGL had nothing to do with Xgl.
DanaG: I'm trying to use the voodoo3, just for the heck of it.
Ghworg: For drm-radeon-testing bugs should I file a bug report or just post to the mailing list?
DanaG: How do I get it to ignore the S3?
airlied: I suppose I could add sysfs support to turn off vga cards
DanaG: Or a parameter to vgaarb:
DanaG: card mask, or something. Just use plain enumeration order.
airlied: the problem is we have to turn off the whole card
DanaG: That should be fixed, right?
airlied: its more of a PCI layer issues
DanaG: hmm, if I boot 2.6.31... that's pre-arbiter, right? Should just use the primary card?
evil_core: Gallium in use, but still black screen in quake3
evil_core: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
DanaG: hmm, if radeon opts out of arbiter... does that mean the other card should opt out, too?
evil_core: again for ut2k4
DanaG: Or rather, if there are two cards and one opts out... does the other need this mysterious "arbiter"?
airlied: DanaG: in that case I think it should work fine
airlied: the non-opt out card will get VGA decoding
DanaG: It didn't, for me. Odd.
airlied: though maybe only if X asks for that
DanaG: I have primary card set to "PCI" in the bios, to note.
airlied: tests kms with no BKL
MostAwesomeDude: evil_core: Does glxgears work?
DanaG: oh yeah, is there a general dri channel on freenode?
DanaG: libGL: using Glide library libglide3.so
DanaG: glxinfo: ../common/drirenderbuffer.c:69: driNewRenderbuffer: Assertion `format == 0x1908 || format == 0x8050 || format == 0x8058 || format == 0x81A5 || format == 0x81A6 || format == 0x81A7 || format == 0x8D48' failed.
evil_core: MostAwesomeDude: yes, i found bug
DanaG: phooey, /me gives up on voodoo3.
evil_core: will rebuild with those patches and try again
evil_core: but it will take some time definitely
DanaG: that assertion is in the way.
DanaG: driNewRenderbuffer: Assertion `format == 0x1908 || format == 0x8050 || format == 0x8058 || format == 0x81A5 || format == 0x81A6 || format == 0x81A7 || format == 0x8D48' failed.
DanaG: puts the rv200 back in.
DanaG: hmm, so what CAN you do with such old, not-very-useful hardware, such as that voodoo3?
DanaG: Just throwing it in the trash is not environmentally nice.
fudje: One of the laser tag places in my town uses stuff like that as wall decorations.
BioTube: DanaG: and there's always the option of leaving it at a scrapyard
airlied: someone always buys crazy old shity
fudje: y'know, I just came in here to ask a question, and realised that the answer was "pull latest libdrm and install it." This channel is awesome.
airlied: \o/ the topic worked
fudje: there's a topic?
fudje: oh yeah.
DanaG: okay, that's weird... my cursor is visible only on VGA, not on DVI.
DanaG: hmm, going to gnome screen-res thingy and merely hitting "apply"... fixed it.
DanaG: "DRM version 1.0 too old to support HyperZ, disabling."
DanaG: if ( sPriv->drmMinor < 13 ) + fprintf( stderr, "DRM version 1.%d too old to support HyperZ, " + "disabling.\n",sPriv->drmMinor );
DanaG: looks like it'
DanaG: it's hardcoded 1.$MINOR instead of $MAJOR.$MINOR.
DanaG: hmm, is top gear in glxgears supposed to be purple?
airlied: DanaG: no r100 has a bug still
airlied: but hyperz isn't supported with kms
airlied: I wrote supprot for it but just to see if it made ghears go faster
DanaG: hmm, has that conditional statement at least changed to not be 1.minor?
airlied: thats fine
airlied: oh it should be changed to check the major as well
DanaG: Was the purple a known bug? Related to hyper-z?
airlied: no its a bug in the flus
DanaG: bummer, can't ssh from fglrx -> radeon and keep GL.
DanaG: Old hardware can be fun sometimes.
DanaG: I found an "HP Visualize FX4" card... but it needs an AGP Pro slot (I think it is) right next to a PCI slot.
edgecase: DanaG, man radeon tells you how to disable vga
edgecase: Option "VGAAccess" "boolean"
edgecase: with KMS on maybe it should default off?
DanaG: Anyway, I've pulled the 3dfx card out...it gets rather hot.
DanaG: Hotter than the 7500, for sure.
airlied: edgecase: KMS ignores all that
edgecase: does it use VGA arbiter then or not?
airlied: with KMS radeon turns off the VGA decodes and opts out
edgecase: so it wouldn't interfere with DRM then?
airlied: it doesn't
edgecase: i thought he was running into that, nm
airlied: no he had two crappy cards
edgecase: well they should work same as ever, but the drivers are rotting
edgecase: anything but ati or nvidia is a relic really
edgecase: visiting the museum can be fun sometimes
MostAwesomeDude: Or Intel.
edgecase: ah right
MostAwesomeDude: Intel has *half* the market.
MostAwesomeDude: People seem to forget that a lot.
edgecase: i have an intel pci gfx card heh
edgecase: i740 i think
airlied: edgecase: no VGA arb makes them work sanely, which isn't to say same as ever
edgecase: i meant, they have same capabilities, the hardware doesn't get improved over time
edgecase: their drivers could be updated to not use vga possibly
cxo: svga.... why couldnt vmware have chosen a less ambiguous name
airlied: lots of old hw needs vga
airlied: its the only way it can set modes
airlied: however doing DRI with 2 cards that require VGA decodes on is very wrong
airlied: so you can't do DRI in that case
edgecase: even if it's only for modesetting?
airlied: edgecase: in theory the X drivers could opt out of arb if they can modeset another way
airlied: otherwise no
airlied: mainly because if one GPU sets a mode while the other is doing DRI it'll be bad
edgecase: well modesetting is infrequent, wouldn't arb make it work?
airlied: since you have to turn off all the memory decodes for the device
edgecase: need a lock then
airlied: and DRI could be using them
edgecase: single thread it
airlied: you can't
airlied: granted you probably could if you cared enough
airlied: nobody cares enough
airlied: since it would involve heavy changes to DRI1
edgecase: pause dri, drain queue, do modeset, resume
airlied: edgecase: thats single card
edgecase: pause all cards then, -> modeset, resume
airlied: the locking gets really messy since what happens if someone has the lock already
airlied: and you have to wait for them to let it go
airlied: and they talk to the X server with the lock
airlied: while X is blocking waiting for the lock in the kernel
edgecase: well if all radeon + nv + intel don't need vga, then yeah why bother
airlied: its not impossible, its merely not worth the effort
airlied: and proving it correct would be really hard
edgecase: i think the PCI SIG dropped the ball on VGA, they should have had an at least an optional standard flag for BAR with alternate decode
airlied: or at least a generic bit in the PCI config space for VGA on/off
edgecase: cards have it, just no standard for BIOS to detect where
edgecase: nv puts it at different offset in BAR than radeon, etc
airlied: most BIOSes acn't access the BAR
airlied: since 16-bit fail
airlied: so they have to remap it in at 0xa000, but since you can't generically stop other cards decoding 0xa000
airlied: you are sorta screwed
edgecase: well i'm not trying to make DOS do multihead, only a 32bit OS
airlied: so there wasn't a need to remap it so much as a need to be able to turn it off
airlied: since most OSes don't care about using VGA regs
edgecase: well with 3 cards, if VGA regs were in a BAR, std bios setup would map them, and OS could use all cards simultaneously
edgecase: same as having 2 SATA cards, etc
airlied: edgecase: VGA legacy resources is all that matters
airlied: most cards that let you remap them have support for alternate modesetting paths
airlied: and the OS driver can use that already
edgecase: i'm saying there's a way to keep them + support multi cards, within pci standard, if they had just gone the extra mile
airlied: its only there for DOS, no OS uses VGA regs beyond bootup
airlied: most things also use BIOS VESA calls anyways
edgecase: except for those cards that need VGA regs for modesetting
edgecase: i'm just saying PCI SIG could have solved it for even those cards, way back when
edgecase: everyone's content to keep ISA around a bit longer, ho hum
edgecase: special-case decodes take up die space on northbridge and the rest of the path
airlied: it was mainly crapy cards with ISA chips hacked to work on PCI
edgecase: well a pci to isa bridge chip, is still a pci core...
edgecase: it's a pet peeve of mine... will i see a PC that doesn't run DOS in my lifetime ?
MostAwesomeDude: Sure, I'
airlied: no then it wouldn't be a PC :-0
MostAwesomeDude: You've surely seen a Mac, right?
edgecase: heh i wonder if they have that PC stuff, PIC PIT VGA etc
airlied: no all gone
edgecase: the intel ones... i guess EFI doens't
MostAwesomeDude: Not "nice," just a different flavor of pain and suffering.
airlied: I assume VGA still decodes just not used by the firmware/OS
edgecase: yeah that's what i like
edgecase: windows 2000 can load bootvid.dll so even BSOD can avoid VGA decodes
sgvadds: Hi, could somebody tell me if there is some way to get rid of white areas to the right and below of console
cxo: parallel make on mesa fails
airlied: no surprise there
airlied: make on mesa is fail
MostAwesomeDude: I think somebody should just combine the automake branches from anholt and me, and push it to mesa master.
MostAwesomeDude: It really would be an improvement.
cxo: yeah, clean automake/autoconf is always best
sgvadds: I see 1024x768 console at the top-left corner of my primary monitor (native res 1280x1024) and uncovered area is white. I think it is caused by tv's max res 1024x768. But that area was black one or two weeks ago. Is it possible to use the same mode (1024x768) on the primary monitor or turn off using tv for console so that it may use 1280x1024? I tried radeon.tv=0 but get blank screens on both.
airlied: sgvadds: video=TV-1:d
airlied: on the command line might work
sgvadds: I'll try now, thanks
wsnelr: I'm making progress with inserting the radeon.ko driver but found my way to a little problem compiling Mesa-7.6. I'm getting a radeon_common_context.h error at line 405 which talks about an array type having an incomplete element type. Does anyone have some ideas on what to investigate for this? I need to get this compiled before the xinerama / kms support will be available to Xorg and the...
wsnelr: ...xf86-video-ati module.
airlied: wsnelr: use mesa master
airlied: wonders why everyone wants 7.6
wsnelr: I was figuring to just grab the latest stable of everything I could, including Mesa. I will try for the git branch of mesa now, thank you ;)