Nightwulf|work: hi all
verwilst: since fglrx sucks so badly :(, i'm looking for an OSS alternative :) how useful is radeonhd with a 4870 card lately? :)
verwilst: especially with 2 screens
Zajec: verwilst: EXA and Xv, no problems about 2 screens
Zajec: no 3D
verwilst: 3D is the least of my worries for now
verwilst: i just get garbled screens with fglrx :)
Zajec: resuming, suspending in 1,2.5, base power management in current git
verwilst: it's always something with those grrm
Zajec: know that :)
verwilst: Zajec: so xrandr --left-of bleh stuffs works on my card probably
verwilst: and do i still need a git drm?
Zajec: verwilst: there is actually one little problem about --left etc. you have to prepare "virtual" line in your xorg.conf
chithead: modesetting does not need drm
Zajec: no, 1.2.5 is enought
verwilst: i'll just add this https://launchpad.net/~tormodvolden/+archive/ppa
verwilst: and that should be enough ( 1.2.5 deb )
Zajec: ah, git drm... didn't read carefully
chithead: if you have kernel 2.6.30 you will get 2d and video acceleration out of the box
Zajec: you need 2.6.30 for EXA, but only for that
verwilst: ah yeah, have to add that virtual line for my intel driver too
Zajec: (EXA and Xv)
Zajec: verwilst: hopefully in future we will get rid of this :)
wirry: hm...on my laptop --left... worked w/o the virtual line...(x1600m, r500)
verwilst: well, if it does multiscreen and does basic 2D stuffs, it already does more than the official one :P
verwilst: but i guess 2D accel. is pretty needed
verwilst: otherwise dragging windows and such is awfully slow, right?
chithead: yes, scrolling and moving windows will be slow without exa
verwilst: yeah, but that's fine if i have 2.6.30 or higher right
verwilst: any plans for UXA? :)
chithead: uxa is not suitable for anything else than intels igp
verwilst: so it will stay an intel-only thingy?
verwilst: what about GEM?
chithead: gem and uxa are specifically designed for intel igp chipsets. there is a phoronix article on all those things
verwilst: yeah i know, but it's hard to see the trees through the forest in the end :)
verwilst: my understanding was that it's designed by Intel, but usable ( in the end ) by the other drivers as well :)
chithead: only the gem kernel interface will be used, the implementation behind it is different
verwilst: chithead: cool
verwilst: this is a pretty vibrant channel actually
v4nelle: guys readeonhd give 3d support on ati x1400?
chithead: yes, if your kernel and mesa are recent enough
v4nelle: i have 184.108.40.206 and i install drm and modules from git
b4283: is 3D acceleration for r5xx scheduled ?
b4283: i'm kinda stuck right now because catalyst won't support 2.6.30
bridgman: b4283; 3d accel has been there for a year or so
bridgman: but it doesn't have all the GL features of fglrx yet
bridgman: is there some specific feature you're looking for ?
b4283: ah, quake 3 feature to be exact
chithead: v4nelle: the kernel modules that ship with 2.6.28 should be sufficient, and mesa 7.2
bridgman: b4283; which distro are you using ? most current distros include a working driver set
bridgman: there was a 3d performance regression on certain chips in the last round of distro releases but I think that only affected IGP parts
b4283: bridgman: Archlinux on a 780G
b4283: entering the game is like.. 5 frames per sec
chithead: 780g does not have open source 3d support yet
b4283: yeah, and i needed a drm module update to get Xv working
bridgman: 780g is a 7xx display block with 6xx 3d core, not 5xx
b4283: but 2.6.30 already has one built in
b4283: bridgman: i read the model type from freedesktop.org/radeonhd
b4283: but i don't really know how are they distinct
bridgman: there's a good wikipedia page that covers all the radeon parts, hold on a sec...
bridgman: be warned, it's big ;)
bridgman: but basically X + 3 digits is 4xx, X + 4 digits is 5xx, HD2xxx or 3xxx is 6xx, HD4xxx is 7xx
b4283: i know 780G == HD3200
chithead: b4283: also see the radeon manpage. although it is not up to date I think
b4283: bridgman: wow,thx
udovdh: I got a sig11 with latest radeonhd?
udovdh: egbert, ?
udovdh: a make clean
udovdh: and a new build result in a sig11
udovdh: install of an older radeonhd rpm fixes the issue
yangman: udovdh: full log please
udovdh: that is it inthe patebin
udovdh: no errors in xorg.log
yangman: just the backtrace is useless because debug symbols aren't on
yangman: need to see the full log to get an idea what the driver was trying to do
udovdh: there is not much to see but I will try to show you
udovdh: I just got the logs from the rpm driver
udovdh: whithout dri
udovdh: so my user experience is very dramatically reduced
udovdh: I let git step back a bit
udovdh: will now try the slightly older git
udovdh: how much is libX11 involved in radeonhd?
udovdh: also I get in ./configure:
udovdh: No package 'xorg-server' found
udovdh: while I have the devel package
udovdh: and I can build radeonhd
udovdh: for a xorg.log
udovdh: with the driver
udovdh: is it something in fedora that was updated this afternoon?
udovdh: or is it the driver code?
udovdh: does the pastebin say anything?
yangman: it's segfaulting on an EXA path
yangman: that hasn't changed in the driver in months
yangman: either a change in libexa is causing issues, or it's a bug in EXA
yangman: can't say without seeting a backtrace with debug symbols
udovdh: exa wasn't updated in the past 24 hours
udovdh: and I was capable of rebuilding radeonhd for f11 because of xorg server binary version differences
udovdh: yangman, which debugsymbols?
udovdh: because they might add up considerably I noticed
udovdh: and how to gdb?
udovdh: gdb startx?
yangman: gdb X
yangman: startx is a script
udovdh: ah, ok, will try
udovdh: X just sits there
udovdh: black screen
udovdh: does nothing
udovdh: only when I kill stuff
udovdh: so no bt
udovdh: what else can I do to find the cause?
udovdh: for http://pastebin.com/d2cb9f47e that is
udovdh: X gets to line 740 of that pastebin and then nothing
yangman: X already does a backtrace dump of its own, so even just getting the name of the function in radeonhd that's involved helps
yangman: did you compile it yourself?
udovdh: that is why I am here
udovdh: else I would complain to redhat
udovdh: already found a real bug in libgcrypt w.r.t. VIA padlock
yangman: call symbols should be on by default. I have no idea why it's not there
udovdh: I just do a ./configure
udovdh: and make
udovdh: configure complains about packages
udovdh: but they are there, enough to build radeonhd
udovdh: can I force the symbols?
udovdh: the drv so is 2.7 M
yangman: then it should already be on
udovdh: radeonhd_drv.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
udovdh: yangman, any ideas for this puzzle?
yangman: you can try gdb again
yangman: make sure you're controlling it remotely
udovdh: on my other, dual screen, machine with hd2600pro i see no problem
udovdh: even after updateing git and a fresh build
udovdh: I just tried the most recent git built by that machine
udovdh: works ok
udovdh: so it must be the build environment?
udovdh: back to the ./configure difference
udovdh: xorg-x11-devel packages are the same
udovdh: it says though:
udovdh: checking for XORG... configure: error: Package requirements (xorg-server xproto fontsproto ) were not met:
udovdh: No package 'xorg-server' found
udovdh: yet I have xorg-x11-proto-devel-7.4-14.fc11.noarch
udovdh: both machines don't have it
udovdh: also it says No package 'xorg-server' found
udovdh: when there is no xorg-server on the working machine
udovdh: is pkg-config involved in the failing test for xorg-server?
yangman: what autoconf requires don't necessarily correspond to a distro's package name
udovdh: found it
udovdh: one of the devel packages was i586 instead of x86_64...
udovdh: which was overlooked
udovdh: now configure completes
udovdh: gotta go now.
cxo: I get an error when loading X "MC not idle"
cxo: xf86-video-ati gives just a blank screen
v4nelle: guys i have mesa-7.0.3 , libdrm-2.3.0 and xf86-video-radeonhd-1.2.3 with ati X1400...but i havent 3d accel......why?
adamk_: v4nelle: I don't believe r500 support was introduced till much later in the mesa drivers.
adamk_: Mesa 7.2 perhaps?
v4nelle: i need mesa 7.2?
adamk_: At least.
v4nelle: ok.....i will try it
yangman: v4nelle: at least 7.3
v4nelle: i need another version of drm of radeonhd?
chithead: radeon and radeonhd use the same drm/libdrm/mesa
yangman: at least 2.6.24 kernel as well, actually
v4nelle: adamk, i think x1400 is M54 and not r500...there is 3d support for M54?
MostAwesomeDude: v4nelle: X1400 is supported.
pepee: the driver is not working for me
pepee: my mobo is ECS A740GM-M
pepee: running Ubuntu jaunty with this package: 1.2.5+git20090609.fc31eb65-0ubuntu0sarvatt~jaunty
pepee: taken from: http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu
aberration: hi, does anyone know if hdmi audio is supported on the 4350?
chithead: radeonhd supports hdmi audio, provided that the kernel and hardware also do
aberration: chithead: on all models?
aberration: also, is the alsa configuration the same for radeonhd and catalyst?
chithead: I think only rs690 was unsupported until recently, all others should work in the latest release. I have no idea about catalyst
aberration: chithead: there was a tagged release that added support?
chithead: iirc 1.2.5 supports hdmi audio
aberration: that must be the problem then
aberration: ubuntu's using 1.2.4
aberration: i will just use arch instead
aberration: thanks for the help
nfrs: I'm a programmer, might be willing to contribute code, but have no drivers experience. is there a dev guide to get started? how tall is the entry barrier?
yangman: nfrs: not much higher than most other poorly documented C ;)
nfrs: yangman: what about the first question?
yangman: read code, poke around code, ask questions
yangman: it's how most of us get started
nfrs: is there some learning practice that novices are advised to follow?
yangman: be patient? ;)
nfrs: that's a default:
yangman: find a section you want to work on, and just go at it
yangman: there's tons of open bugs and tons of still missing features
nfrs: are there general docs on video cards out there on the net that will be relevant?
yangman: they're no different than any other software
yangman: you write to registers via mapped memory and the hardware acts accordingly
yangman: no different than any other hardware, rather
yangman: look at the cursor code in rhd_cursor.c
nfrs: well, I don't have any experience with hardware drivers
yangman: it's a nice, small place to start that doesn't have a lot of layers
yangman: it's really not that different from typical software development, just more caveats
yangman: instead of open(), you call mmio_map(). instead of read(), you call REG_WRITE(), etc
yangman: just lower in the stack
yangman: the abstraction parts are already done
nfrs: read() should be equivalent of read, no?
nfrs: I mean, REG_READ :)
yangman: er, sure
yangman: you get the idea ;)
nfrs: are registers the videocard memory?
nfrs: or are they like CPU registers?
yangman: like CPU registers
nfrs: how many of them?
nfrs: and width?
yangman: again, you're better off looking at driver code
nfrs: how do you debug a driver?
nfrs: esp. a display driver
yangman: it's just a piece of software
yangman: not much different
nfrs: yes, but it works in the kernel
yangman: not the Xorg drivers
nfrs: so won't putting a breakpoint make the running driver stall => freeze the debugger?
yangman: drm drivers, yes
yangman: but kernel debugging has its own set of tools and facilities
nfrs: so novices aren't supposed to touch drm?
yangman: well, I didn't say that
yangman: it's a different part of the overall stack
nfrs: I figure it must be harder
yangman: Xorg drivers act entirely in user space
nfrs: how do you debug a Xorg driver? from the text console?
yangman: hardware manipulation is done by writing into memory ranges that's mapped to the corresponding hardware
yangman: drm exposes a different path to access the hardware, and typically doesn't involve X except for making sure it's setup, and that X stays out of the way when it's supposed to
nfrs: hm. why 2 different ways?
yangman: the sane thing, however, is to put bits that interact directly with the hardware into kernel space
yangman: this is why there's a push towards kernel mode setting
nfrs: isn't writing to memory-mapped registers direct interaction with hardware?
yangman: it is
nfrs: what exactly is "direct interaction"?
yangman: but the propagation is still done in kernel space
Neo_The_User: direct rendering / talking directly to hardware
nfrs: but as far as I understand, that's the way that the user-space part works, as well
nfrs: Neo_The_User: what kind of code/commands do you use for that?
yangman: drm exposes an API to userspace, not register themselves
nfrs: so the xorg driver is a layer above drm?
Neo_The_User: well technically spreaking, low level instructions
nfrs: writing to mmio-mapped region makes the kernel-space driver transfer the data?
yangman: no. xorg drivers, as they are now, take a different path
Neo_The_User: which require IRQs and all that ;)
nfrs: so xorg infrastructure has its own low-level facilities to translate the mmio writes/reads into low-level commands?
yangman: ignore what Neo said. that's a separate thing
Neo_The_User: ....yeah im lost
nfrs: AFAIK, there should be a kernel-space driver intercepting the mmio writes/reads anyway, no?
yangman: the push is towards having drm provide things like a API call to change resolution, and setup displays
nfrs: or some part of kernel itself?
yangman: what has been the case historically, and still is for most drivers, registers are written to directly to make things happen
nfrs: sounds like a lot of API calls
nfrs: might be hard to cover all (future) use-cases
yangman: it's a lot saner than having to write dozens of registers with specific values that may vary from model to model
yangman: the kernel still has to do this, but it's the component that should have been doing it in the first place
nfrs: what do you mean "the kernel still has to do this"?
yangman: manipulating registers
nfrs: so right now you have a lot of synchronization going on
nfrs: between kernel-space and user-space drivers
yangman: the mmio thing is really a non-issue
yangman: at least it's a non-issue if you just want to contribute Xorg driver code
nfrs: well, for one I'll have to study the registers
yangman: look at the driver code
yangman: reference the docs as you need to
nfrs: is there something that the card is able to do, which is not exposed through registers? 2d? 3d? video?
yangman: everything is exposed through registers, plus mapped memory
nfrs: the video card's memory is also mapped? all of it in one bank?
yangman: no, there's a limit to how much can be mapped
nfrs: what's the limit? how do you overcome it?
yangman: which is why there's also work being doen to build a in-kernel memory manager for graphics systems
nfrs: lots lots and questions. sorry :)
nfrs: s/lots and/and lots/
nfrs: that's where dev guides are useful
yangman: things have been changing rather dramatically in recent years
nfrs: yeah, would be hard to keep the docs up-to-date. still a pity
airlied: you can never answer enough questions :(
yangman: you'd need to read the code to be able to understand things sufficiently anyways
airlied: history has proven self-starters do well at graphics drivers :)
airlied: the main thing is to find a problem or feature and try and do just that
airlied: gpu programming is too broad to take in at once
nfrs: well, I obviously want to work on 3d :)
airlied: well 3D would imply working on mesa
nfrs: but god knows how far I am from there :)
airlied: well you don't need to understand how 2D drivers work or modesetting to do 3D
nfrs: driverS? so there are several of them?
yangman: different parts of a fairly large stack
airlied: there are 3 components to a Linux GPU driver
airlied: the 2D X.org driver, kernel drm driver, mesa 3D driver
nfrs: what is the drm driver currently responsible for?
nfrs: I think I should start with bugfixing, anyway, seems like the best bet to get accustomed with the environment
airlied: its changing, but historically it just provides a mechanism for unprivledged processes to send command to the card
airlied: has some docs
airlied: however the kernel modesetting push is moving a lot of code from the 2D X.org driver into the kernel drm driver
nfrs: so these commands (sent through drm) are API to some of the things you can do through registers
airlied: well you do card setup generally with registers
airlied: acceleration is usually slightly more complex
airlied: you normally set up buffers in RAM between GPU/CPU
airlied: and program something on the GPU to execute those buffers
nfrs: there must be some kind of bootstrap. does it happen in the kernel or in xorg?
nfrs: buffers in RAM <- memory-mapped?
airlied: again at the moment 2D driver does most of the bootstrap (along with BIOS)
nfrs: or does GPU access the main memory directly?
airlied: this is moving to the kernel drm doing it
airlied: gpus can normally access main memory
airlied: normally via a GART (remapping page table)