Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-6-26

Search This Log:


mikkoc: hi, i compiled 2.6.31 with kms support enabled.. now the console turned black
mikkoc: X is fine
mikkoc: i have libdrm compiled with --enable-radeon-experimental-api
mikkoc: brb, i recompiled xf86-video-ati from kms-support just to be sure
MrCooper: userspace doesn't affect the console - is CONFIG_FRAMEBUFFER_CONSOLE enabled?
mikkoc: ah let me see
mikkoc: CONFIG_FRAMEBUFFER_CONSOLE=y
mikkoc: CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
mikkoc: i can see the console at the very beginning, with the penguins and all
mikkoc: then it turns black
MrCooper: airlied, glisse: BTW I think radeondrmfb should default to 8 bpp, but when I tried it the display was corrupted, and even starting X in 32 bpp didn't fix it. Can you reproduce that?
mikkoc: card is x1400
MrCooper: mikkoc: ah, then it could be some startup script
MrCooper: mikkoc: glisse's recent radeondrmfb fix might help
mikkoc: such as? it always worked before
mikkoc: MrCooper: so what do i need to do?
mikkoc: MrCooper: i see this in dmesg
mikkoc: fb1: radeondrmfb frame buffer device
mikkoc: registered panic notifier
mikkoc: is that good?
MrCooper: mikkoc: when did it stop working?
mikkoc: MrCooper: when i enabled kms on 2.6.31-rc1
mikkoc: i never used kms before
mikkoc: here's the dmesg output http://pastebin.ca/1475148
MrCooper: mikkoc: you could try current Git or airlied's drm-fixes branch, in particular I think glisse's commit f92e93eb5f4d56d73215f089580d53597bacd468 might help
MrCooper: just a guess though
mikkoc: ah that requires pulling a new kernel... dont have time for that, will the fixes be in rc2?
MrCooper: yeah
mikkoc: hm, i might try the git snapshot
mikkoc: that would work out
airlied: michaellarabel: sounds like you have vga= lines
airlied: remove that
airlied: MrCooper: I'll try 8bpp later, I only tested 16bpp in the server so far.
mikkoc: airlied: was that vga= to me?
mikkoc: yes i do have it
airlied: mikkoc: oops yes.
airlied: damn tab complete.
mikkoc: i'll remove it thx
airlied: needs to add a patch to radeon to takeover from vesafb
airlied: forgot to do it
mikkoc: airlied: still black after removing vga=, but it seems it turns black when udev starts
mikkoc: might not be kms related after all
airlied: mikkoc: sounds like fbcon not loaded then.
mikkoc: ah
airlied: though if vesafb works
airlied: it should be
airlied: so it might be kms messing up
mikkoc: lsmod|grep fbcon returns nothing
mikkoc: neither vesafb
glisse: airlied: so what about surface ? :)
chithead: mikkoc: vesafb is not a module, grep in kernel config for FB_VESA and FRAMEBUFFER_CONSOLE
mikkoc: CONFIG_FRAMEBUFFER_CONSOLE=y and CONFIG_FB_VESA=y
mikkoc: i'll try disabling kms, just to make sure it's not a regression in 2.6.31
MrCooper: airlied: your vline patch has a typo in r100.c: ttm_crtc -> drm_crtc
glisse: MrCooper: btw i need to find where i put the nonconformant patch
glisse: i though i pushed it
glisse: airlied: also with your vline patch one can defeat command stream verification
glisse: also what about my preallocate patch ?
glisse: it cleans up the cs code a bit beside preallocating stuff
mikkoc: airlied: disabling kms solves the black screen problem
mikkoc: btw, the scripts coming after udev are "mounting /dev/pts" and "mounting /dev/shm", so it might be one of those too
mikkoc: udev is 141
airlied: glisse: yeah i was thinking more about surface, maybe you are right we might only need to really worry about front buffer
airlied: though I wonder how much CPU overhead it'll involve.
glisse: airlied: we loose on fallback anyway
airlied: glisse: reply to the vline patch with the problem :)
airlied: glisse: true I suppose optimising for fallbacks isn't worth it really.
airlied: my only worry is still with texture tiling in sw fallbacks, since mesa swrast can't handle it yet
airlied: we'd have to DFS on first access to the texture and untile it, or enhance swrast to do some detiling inline
airlied: glisse: I'll also review the prealloc patch on Monday and queue it up
glisse: airlied: i think we can start with untiled texture
glisse: and then add mesa knowledge about tiling for texture
glisse: in gallium it's easy, i think it shouldn't be hard in classic neither
airlied: hatse writing detile functions :)
airlied: btw how do we plan to do the tiling? on blit to VRAM?
airlied: for textures
glisse: also i think we should name tile flag device dependant like R100 up to R500
glisse: new hw have quite different layout iirc
airlied: I'm not sure there is a major advantage in advertising all the varied tile modes
airlied: some of them are probably not useful
glisse: for texture i don't know, i think we should worry about texture once we look how we could tweak mesa to access texture, i guess once we know that tiling texture will be easy :)
airlied: it just making sure we don't need to bust the API
airlied: granted we can expose generic MACRO/MICRO and add card specific later I suppose
glisse: i think we should allow userspace to play with tiling flag of 2d blit and assume userspace knows what it does
airlied: glisse: you still need to have tiling info
airlied: the DDX has to tell the 3D driver
glisse: yeah we need that, what i mean is that kernel should not force flag on 2d blit
glisse: if userspace is too dumb then it means we are too dumd ;_
airlied: why would it help to not enforce it?
glisse: i thought than in the first approach you wanted to enforce tile flag on 2d blit according to kernel knowledge of buffer
airlied: maybe we should just add set/get tiling ioctls instead of mangling create
airlied: then we can punt on making a decision :)
glisse: yeah set/get sounds better, i think better is even one ioctl properties which can set/get different properties, of course right now we only have tiling
airlied: tiling and swapping
glisse: but we might have compression and other things like that latter
glisse: yup swapping too
airlied: well r600 tiling is about 60 types :)
glisse: for create buffer we still might want to add a flag for hyperz
MostAwesomeDude: So, userspace does or doesn't care about tiling?
glisse: MostAwesomeDude: userspace does care
airlied: glisse: we have flags for that if needed
glisse: and have to if it wants to use tiling :)
airlied: as long as they are just bits
airlied: glisse: the other q is if we need to change mmap call
MostAwesomeDude: So, are BOs tiled on creation, then?
MostAwesomeDude: Just trying to reconcile this with Gallium.
glisse: airlied: if we put surface only on scanout the surface reg should be programmed at crtc-set base
glisse: but i wonder what happen when we switch btw different X server
glisse: MostAwesomeDude: not on creation but you can call properties right after
glisse: maybe we can getsurface first time a buffer is bound to a crtc
glisse: then if there is more scanout buffer than surface new scanout buffer are untiled
glisse: it should still be more than enough for most usecase
MostAwesomeDude: glisse: So, if I do a bunch of drawing on a BO, then decide later on that I wanna tile it, what happens?
airlied: glisse: we still need surface on map or fault, surface isn't related to scanout
airlied: it has to be related to the CPU actually wanting to access the surface
glisse: MostAwesomeDude: you set tile properties on it and it's up to userspace to rearrange data
glisse: airlied: why do we need it on map or fault ?
MostAwesomeDude: glisse: So, the efficient thing to do would be to decide once, at creation, what kind of tile it's going to be... are there any use cases which make sense for tiling to change after creation?
glisse: if we program surface once for scanout buffer we need to update it when buffer move
airlied: glisse: its just inherently wrong to associate scanout and surfaces
airlied: a surface has nothing to do with the GPU's ability to scan out the buffer
MostAwesomeDude: that++
Zajec: mikkoc: did you solve your problem?
airlied: a surface is for CPU access, so need to be associated with mapping/faulting
Zajec: mikkoc: is you have fbcon compiled into kernel, it won't be listed in lsmod
Zajec: mikkoc: maybe patches from glisse's dir will help you
glisse: airlied: i know that, but if we put surface only for scanoutbuffer best is to associate once we know a buffer is a scanout one
mikkoc: Zajec: no, i'll wait for rc2
mikkoc: cuz git1 snapshot doesnt seem to have those patches
Zajec: mikala: right
airlied: glisse: I think we should associate when the CPU accesses the buffer we are scanning out
airlied: though actually I really don't like scanout and surface being associated
glisse: airlied: just trying to avoid adding callback here
airlied: I just think later you'll want to use them for something and come to regret taking shortcuts now
airlied: if fbcon was to get rendered to offscreen we'd be screwed
glisse: or we could alloc surface with properties ioctl, userspace telling properties that the buffer will be used as scanout
airlied: we currently blit fbcon contents to the X frontbuffer at driver startup in kms
airlied: so we get seamless startup
airlied: it could end up using sw for that by mistake
airlied: I'd rather it still did the right thing
glisse: airlied: what i said is once a buffer is know to be scanout program one surface reg and never change it beside if the buffer change
MrCooper: yeah, that's basically what I pointed out in my followup
glisse: so each scanout buffer will still have its surface reg even if not actually scaned out
MrCooper: note that if we decide to use surfaces for byte swapping the X front buffer, I don't think it'll be feasible to handle the lack of a surface for a front buffer that resides in VRAM
airlied: glisse: 4 X servers with pageflipping?
airlied: thats not a hard limit to hit
glisse: airlied: what i said is if we run out of surface reg we assume untiled
airlied: well 3.5 X servers sicne fbcon will have one
glisse: and userspace have to query through properties to know if the buffer is actually tiled or not
glisse: once you have that much server running you have to accept that thing might start to be slow
glisse: not even mentioning getting low on vram
airlied: not really, designing to fail doesn't seem like a good idea
airlied: one of the servers will probably get kicked out of VRAM
airlied: I run my laptop with 3 servers quite a lot, since we start a server to do user change on top of the one per user
glisse: so we always have to assume userspace know how to access tiled buffer
glisse: and don't care about surface
airlied: glisse: wfb?
glisse: downloadfrom screen with macrotiled only
glisse: sounds like easier solution
airlied: I don't think we need to worry about not having a surface, if we just do the fault time handling
airlied: if we get surface ping-pong then the user is doing something very unusual
airlied: like vt switching really fast
glisse: airlied: i worry that doing the fault time handling could impact perf a lot more than having sf know what to do
airlied: the check at fault time doesn't seem like a major overhead
glisse: and what happen if we run out of surface ?
airlied: glisse: we unmap one of the users and steal his
glisse: so if we got more 8 user trying to access surface backedup buffer we might enter an infernal fighting on mmap
airlied: glisse: my only worry is some stupid deadlocking problem
glisse: which sounds like a harder faillure
airlied: glisse: that might make it not work at all.
glisse: so it's better to assume surface never existed :)
airlied: since we have all those mmap sem ordering issues.
glisse: and if userspace want tiling it's up to it to deal with that
MrCooper: glisse: DownloadFromScreen where? PrepareAccess is currently all or nothing, so in the worst case you could have untile whole front buffer -> CPU changes one pixel -> re-tile whole front buffer
airlied: I'd be interested in a wfb implementaion about as much as hole in the head
glisse: MrCooper: in exa doesn't fallback try to download from screen to perform sw rendering on local buffer ?
airlied: making wfb fast is very messy, you'd probably end up using llvm )
airlied: glisse: not for pinned frontbuffer
glisse: airlied: my feeling in all this is that doing magic at mmap is way to dangerous and prone for add failure i would rather allow only 8buffer to have tiling and then tell userspace it can't have anymore tiled front buffer
glisse: when you got that much Xserver or whatever running you have to accept that perf will decrease if you don't have this need shiny hw with 32surface reg :)
MrCooper: glisse: the driver handles pixmap allocation, there's no second buffer
glisse: i guess i was feeling like the future pixman existed
MrCooper: airlied: I doubt even LLVM would help for wfb, e.g. for blits the wrapping callback is called for each byte...
airlied: MrCooper: woudl we need wfb for swapping without regs?
MrCooper: I think so, and that would be really bad, you can't disable/enable wfb dynamically so you take overhead even when you wouldn't really need it
Zajec: R5xx and R6xx cards have two digial outputs blocks: LVTMA and TMDSA... what about r7xx?
logari81: some days before I had noticed that:
logari81: vdrift: radeon_common.c:1016: radeon_validate_bo: Assertion `radeon->state.validated_bo_count < 32' failed.
logari81: with this bt
logari81: http://pastebin.com/m15af4375
logari81: today occured this:
logari81: gmsh: vbo/vbo_save_api.c:216: map_vertex_store: Assertion `vertex_store->buffer' failed.
logari81: could the two problems be related to each other?
logari81: chip: RV410/M26, mesa: git from ~20th June
phoenix64: I am afraid this question might be inappropriate, but are there any performance comparisons of the oss driver and fglrx?
glisse: phoenix64: on phoronix
sylware: Hi, anybody knows if there is a r7xx board with passive cooling?
bridgman: phoenix64; phoronix runs comparisons between open and fglrx drivers every year or so
phoenix64: hm, also opengl comparisons? I atm only find 2d ones
glisse: yes gl too
bridgman: sylware; I have seen passive 4350, 4550, 4679 and heard about passive 4770, not sure about anything higher/hotter than that
bridgman: s/4679/4670/
phoenix64: ah, that was a combined test. Looks quite synthetic though what I have here
phoenix64: hm, no, was 2d
sylware: bridgman: ok thx
bridgman: there should be some game benches in there, all gl
bridgman: http://www1.sapphiretech.com/us/products/products_overview.php?gpid=280
Zajec: bridgman: can you explain me please, what is situation of digial outputs on ATI cards?
Zajec: bridgman: does every card have TMDSA and LVTMA?
Zajec: in rhd_timds.c I can see for example comment:
Zajec: * Gets replaced by DDIA on RS690 and DIG/UNIPHY on RV620.
glisse: Zajec: with hw there is never an every rule
phoenix64: argh, I am too stupid to use google probably. I don't find anything -.-
glisse: some card have somethings some other doesn't
sylware: bridgman: that will allow me to wait for fan management in silence :)
Zajec: glisse: just some more or less view would be nice to have :)
bridgman: Zajec, as I understand it the blocks all got changed when we added Display Port
Zajec: glisse: what is DDIA and DIG/UNIPHY? are that some blocks that replaces TMDSA?
bridgman: DDIA was something different IIRC; muxing either PCIE lanes or video onto the same pins
Zajec: er, but RV620 doesn't have display port
bridgman: this is all going from memory and very low quality information
bridgman: yes it does
Zajec: oh :)
bridgman: the chip does, even if the board doesn't
bridgman: when we launched the chips nobody was shipping display port monitors (D'oh !!)
bridgman: so as you can imagine the board partners weren't exactly falling all over themselves to put display port connectors on the cards they built
glisse: phoenix64: http://www.phoronix.com/scan.php?page=article&item=amd_r500_mesa_catalyst&num=1
Zajec: ah, slowly starts making sense
phoenix64: thx!
Zajec: bridgman: so DDIG is actually what? digial output? or kind of technology for... er, for what? minimalizing needed amount of memory?
glisse: Zajec: digital output
bridgman: http://www.phoronix.com/scan.php?page=article&item=amd_r500_legacy&num=1
Zajec: and every card has 2 digital outpus, right?
Zajec: it's just about which ones
bridgman: typically but not always
Zajec: is there >ati< card with more digital outputs?
bridgman: I still see cards being built with 1 DVI-I, 1 VGA and 1 7-pin TV
bridgman: mostly 2 digital these days though
glisse: Zajec: the thing here is that boardmanufacturer decide which connector they put
bridgman: the chips can only drive two different signals at the same time anyways, so not much benefit to having >2 of anything
glisse: if they wish they can put only svideo connector
Zajec: ok :)
Zajec: may I use information I got from you without copyrights? :)
Zajec: for writing comments in driver :)
bridgman: no concerns here
bridgman: IP law is different in France, so ask glisse separately ;)
Zajec: :D
glisse: we don't care about ip here
Zajec: fine
glisse: well at least ip are only valid for somethings you can touch ;)
bridgman: yeah, try violating the Bordeaux name and you rot in a jail cell ;)
Zajec: glisse: oh, are you in France? you work for some distro, am I right?
Zajec: bridgman: :D
glisse: bridgman: oh you know for such crime we still got few guillotine working ;)
bridgman: cool
bridgman: I'm glad the old traditions are being kept alive
bridgman: even if the participants are not ;)
glisse: Zajec: yup working from france
glisse: i think bridgman would like me to trade good wine against gpu board :)
Zajec: glisse: from France for distro/company in other country?
glisse: i am working for Red Hat
Zajec: glisse: and Red Hat according to Wikipedia is localized in USA :) nice, I didn't know you work remote for them
Zajec: ok, last questions from annoying newbie :)
Zajec: 1) does display port use TMDS?
Zajec: 2) does DDIA tranmit TMDS only?
Zajec: 3) does DIG/UNIPHY transmit TMDS only?
Zajec: i would really love you for answering these :)
glisse: http://www.x.org/wiki/DisplayPort
Zajec: didn't think about X's wiki
Zajec: ok, so DisplayPort uses some new (alternative to TMDS and LVDS) format?
Zajec: format/signal...
glisse: yup
glisse: wikipedia has a short good description of dp
bridgman: 1. no, display port is different
bridgman: 2. yes, I think so (mostly used for HDMI IIRC)
bridgman: 3. no, it handles DP as well AFAIK
Zajec: great, thank you
bridgman: but again, all from memory, coffee not taken effect, your mileage may vary, may contain nuts
airlied: UNIPHY can do LVDS/TMDS/DP
airlied: on rv620 up I think there are capability to have 6 uniphys
airlied: dual-link DVI takes 2 uniphy transmitters
Zajec: thanks airlied
airlied: DDIA is special TMDS over PCIE lanes
Zajec: can you check my doc patch, please? http://estudent.put.poznan.pl/rafal.milecki/rhd_dig_doc.patch
Zajec: yeah, it's for radeonhd for now, hope agd5f will can use it
airlied: if you look at radeon you'll see dce reference
airlied: IS_DCE3_VARIANT and IS_DCE32_VARIANT
airlied: they are display engine versions
Zajec: oh, see it
airlied: also I think the rs690 had a uniphy on it
airlied: you also have to worry about DVO, there are DP cards with an off-chip DP chip
Zajec: DV0 is name of cards group or that external chip?
bridgman: I think it's the protocol between GPU and external chip
airlied: yeah its a data protocol with an i2c control bus
airlied: its where you put new display drivers when you haven't time to make the on-chip one work :)
bridgman: ahh, so there is a good reason for it ;)
Zajec: what is DVOA?
Zajec: if (IS_DCE3_VARIANT) { /* save DVOA regs */
airlied: the first DVO output
Zajec: ah, sure, A suffix
Zajec: so is that 0 [zero] or O? :)
bridgman: o like output
AStorm: Zajec, get a real font
bridgman: f0nt ?
Zajec: oh, my miastake, airlied really wrote DVO...
Zajec: ups :)
AStorm: bridgman, mine shows dotted zeros
bridgman: mine has a backslash through zero
bridgman: which makes it look like the "o" in other countries
bridgman: I love standards ;)
AStorm: either is good
AStorm: no, that o is slashed the other way around
Zajec: i start hating that... why my M82==RV620 has UNIPHY according to radeonhd: ?!
Zajec: (II) RADEONHD(0): Connector[2] {RHD_CONNECTOR_DVI_SINGLE, "HDMI_TYPE_A DFP1", RHD_DDC_2, RHD_HPD_0, { RHD_OUTPUT_UNIPHYA, RHD_OUTPUT_NONE } }
nanonyme: Yeah, I tend to use the slash too if I have to do alphanumeric in handwriting and the it's important you make out the significance between O and 0. :)
Zajec: part of radeon_driver.c: /* save UNIPHY regs */ if (IS_DCE32_VARIANT) {
Zajec: so UNIPHY should be only on DCE 3.2... and my RV620 is DCE 3 :/
airlied: Zajec: there is an else to that if statemtnt
Zajec: ups
Zajec: damn, i'm really to tired
bridgman: saying RV620 is DCE 3 is like saying it's 6xx
Zajec: 3.0 i meant
bridgman: it's true but you can be more specific - 3.0, 3.1, 3.2 etc..
Zajec: 3.1? there is such?
bridgman: somewhere; probably 780
bridgman: we don't always find the proper naming until after the driver is written ;)
bridgman: agd5f knows all this stuff; ask again on Monday ;)
airlied: yeah I don't think 3.1 was sufficiently different for us to worry
bridgman: atombios can hide the small differences, but it's not designed to hide things like new blocks
Zajec: and... what is difference between transmitter and encoder?
airlied: Zajec: encoder does the bit encoding for LVDS/TMDS/etc, transmitter does the physical layer
bridgman: and bit encoding is where the "Transition Minimized" part of TMDS comes from
bridgman: 8 bit characters get converted to 10 bit patterns, but the 10 bit patterns are easier to transmit and receive over a real-world wire, ie they have a narrower range of frequencies to worry about
Zajec: ok, encoder meaning sounds easy
Zajec: so transmitter is connector?
Zajec: or is there still some difference between transmitter and connector?
Zajec: by connector I mean DVI/HDMI/D-SUB
bridgman: yeah, connector is different again
bridgman: rgb analog can go to vga or DVI-I
bridgman: tmds can go to DVI-D, DVI-I or HDMI
airlied: wonders if anyone has seen a DVI-A :)
mjr: I think I have, on a dvi-to-vga adaptor ;P
bridgman: so think about CRTCs, encoders, transmitters as being patchable inside the chip
bridgman: transmitters generally 1:1 with pins, but pins are mapped to connectors by board designer
glisse: airlied: wb pool for page allocator doesn't seems to give a perf boost here on igp
bridgman: and that wiring is documented in the bios
airlied: glisse: does it save CPU?
glisse: hard to say
bridgman: except for 5xx HPD which was semi-documented ;)
airlied: glisse: I used sysprof to see 20% in page alloc
airlied: but I suspect yoo are using WC :)
Zajec: uh... ok... would like to save I slowly get it, but I don't belive anymore I'm near to understand whole GPU construction :P
Zajec: *to say
glisse: airlied: page alloc is not what is taking time for me
airlied: glisse: are you using WB for everything?
glisse: i think on igp it's what it does
airlied: I was using WB for all my DMA buffers and hitting it back then.
airlied: but maybe some DMA buffer optimisation might help
bridgman: CRTC etc... goes from memory to raw digital video data (stream of bytes)
airlied: zzzz &
bridgman: encoder converts (if needed) to a different digital format (eg 8b/10b or generating a digital representation of NTSC/PAL composite video
bridgman: transmitter goes from that digital reprsentation to appropriate analog levels (eg TMDS and LVDS use different voltages etc.. on the links)
bridgman: transmitter wired to pins; board mfg wires those pins to connector
bridgman: display port is just another kind of link
glisse: airlied: according to sysprof ttm_page alloc is quite low on the profile, top of the profile is mls_compute_sid and sidtab_search_context
bridgman: but it gets wierd because DP can then be converted to just about anything else
airlied: glisse: sounds like you aren't maxing the CPU, or selinux is on :)
Zajec: bridgman: ok, now i should really got right picture of that
glisse: selinux is on
Zajec: bridgman: it was just that wiki: http://wiki.x.org/wiki/Development/Documentation/HowVideoCardsWork calls encoders+transmitters as outputs
glisse: airlied: i guess for tiling we need more thinking
Zajec: thank you :)
airlied: glisse: I can't ermember what I tested with either, proably gears or ipers
glisse: gears but q3 doesn't show diff in perf
suokko: Building new kernel with Jeremo's pool allocator :) Let see how it works
nanonyme: is hoping some kernel rc soon will like his CPU so he'll get to try out the new stuff too :)
Xeccos: (EE) RADEON(0): Cannot read V_BIOS (3) Input/output error -- http://dpaste.com/60073 , Mobilitiy Radeon HD3650, anyone got any ideas?
suokko: nanonyme: rc1 has been tagged
suokko: Xeccos: Does fglrx work with your card? (Just in case you have tried it)
Xeccos: suokko, i have tried it, and it doesn't work either
suokko: That error sounds a lot like broken hw or badly writen bios data
suokko: bridgman: should know the answer :)
suokko: At least he has more knowledge about that kind of failure
bridgman: Xeccos, does the laptop have switchable graphics, either ATI/Intel or ATI/ATI ?
Xeccos: it has two ati cards, the other being a 3200
bridgman: yeah, just opened the log
bridgman: I've seen this before when there are two GPUs; maybe the driver is trying to read BIOS off the wrong one or something
bridgman: do you have the ability to switch 780 graphics on/off in BIOS and if so what is the setting ?
Xeccos: i would totally believe the bit about a poorly written bios, when I got the machine acpi was completely nonfunctional
Xeccos: i don't think theres a setting in the bios, i'll go check
bridgman: most of acpi is in the SBIOS though, only a bit in vbios
Xeccos: i choose which to use by specifying the BusID in the xorg.conf
bridgman: understood, but sometimes that doesn't seem to be enough; the driver still can't read the bios
bridgman: in fact it never seems to be enough ;)
suokko: Just a queston. Why is radeon_reg.h kept in xf86-video-ati and in mesa dri? I guess there should be way to share the code between them :)
glisse: because we want to able to compile one without the other
Xeccos: there is not a setting in the bios to disable or choose a primary card
bridgman: suokko; this is something I bring up periodically; whether we should be treating the X driver, mesa driver and ddm driver as a single entity rather than three separate drivers
bridgman: the consensus is always a resounding "no" ;)
suokko: glisse: How about a small library that is shared between both? (Ok. This might be more complicated than duplicating the code)
glisse: bridgman: we dream of that since year ;)
glisse: suokko: too much pain
glisse: suokko we hope at one point that one driver will be enough
glisse: something like gallium
glisse: at least i hope so
suokko: yes
suokko: I think Gallium is too near future so not worth starting to move code to a common library shared between drivers.
bridgman: Xeccos; might be worth giving radeonhd a try to see if it behaves differently, but I think it has the same problem
bridgman: bbl
MostAwesomeDude: suokko: Gallium *is* essentially a shared acceleration library.
suokko: yes. I know :)
Xeccos: i tried radeonhd with 2.6.29 with similar results
suokko: But current radeon could have had shared library code long time ago. But maybe my C++ experience have made me think libraries are way too easy to create and use :)
MostAwesomeDude: suokko: Could have, yes. But it didn't.
Xeccos: just tried with 2.6.30 and radeonhd doesn't work, with either card
suokko: Xeccos: What if you try to read the bios from sysfs your self?
Xeccos: haven't tried
Xeccos: couldn't say I know how
Xeccos: i'm willing to try were I givin instruction tho
suokko: /sys/pci/bos/devices//rom
suokko: There should be your video bios
suokko: readable for root only
mikkoc: how can i fix this error:
mikkoc: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
mikkoc: [dri] radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
mikkoc: i have mesa master and xf86-video-ati from kms-support
MostAwesomeDude: mikkoc: Looks like a userspace bug WRT DRM version.
mikkoc: i have libdrm master with the experimental radeon flag
suokko: mikkoc: You probably are missing new enough libdrm or wrong xf86-video-ati
mikkoc: i just recompiled both
mikkoc: maybe i need to recompile xorg-server to pick up the changes?
chithead: probably wrong branch/git tree
suokko: mikkoc: no. More likely you installed them to /usr/local and xserver doesn't look from there
mikkoc: nah, gentoo ebuilds are ok i think
Xeccos: i get a read error when I try to less the 3650
suokko: Xeccos: Sees like that rom file isn't easily read able with cat :(
Xeccos: so is there anything that can be done?
Xeccos: could it still work without being able to read the bios or do I need to wait for a kernel (or kernel patch) that lets it work or what
suokko: You need the bios data for operating the card
Xeccos: ok, so I need to wait for a kernel, that sucks
AndrewR: suokko, does recent mesa master work for you after "r200: make use of DMA buffers for Elts a lot better." ? For me this commit broke at least demos/tapot and q3
AndrewR: * mesa/progs/demos/teapot
suokko: yes. broken. I have seen that kind of rendering before
suokko: Also textures are rendered often under the 3D image
ub_1: Did anybody get S-Video working on R500 (Radeon 1900XTX)? All I got is severely distorted image.
_Groo_: hi/2 all
_Groo_: airlied: ping?
_Groo_: hi/2 all
nanonyme: o/
_Groo_: invokes the demons of the radeon realm, RISE airlied, glisse and the gang
_Groo_: hi nanonyme \o/
nanonyme: Hey. Happened to still be here, just came back from a terrace round.
_Groo_: wants to ask airlied if groo needs to ask rs485 fbo support in haiko
_Groo_: nanonyme: terrace round? whats that?
nanonyme: Sitting in terraces aroudn the city, enjoying Sun shine, cold drinks and life, mostly.
nanonyme: s/dn/nd/
_Groo_: nanonyme: looks nice, although boring for me
nanonyme: Depends on if you have friends with you.
_Groo_: nanonyme: still boring :D
nanonyme: *shrug* Suit yourself.
stousignant: quick question here, how can i set the console resolution with radeon kms ? my target resolution is 1680x1050
skodde: hi everybody, i followed these instructions http://airlied.livejournal.com/66958.html but my card (Radeon X1650 XT) seems to not work properly, here is the kernel log: http://pastebin.com/m1b139e4f , is there something that i can do?
skodde: (btw i'm using the last drm-fixes branch for the kernel)
stousignant: have you tried the lastest git sources rc1 ?
skodde: stousignant: yup, i just tried this other one 'cause with the rc1 it was simply freezing the system, at least now i got a broken console but a working (without acceleration) X
skodde: the console works for a while anyway, during the initialization of the radeonfb i think, then it switches back to vga but there is no output, just a frozen screen
stousignant: maybe it's the radeonfb the problem, on my side i've did not compile the radeonfb module and it's booting well but i've got no console => but a working X with accel
stousignant: well not the rc1 i'll try it out in a sec but the drm-next branch
skodde: stousignant: i think the drm-next branch is older then the .31rc1 (and so of the drm-fixes branch)
skodde: stousignant: anyway you suggest to try to not compile the fb driver?
stousignant: yup
stousignant: i'll try the rc1 bits and be back :)
skodde: let's try without the fb
skodde: same result
daum: hey guys- i just installed ati-driverss, however it seems aticonfig isn't finding my x1550 card
MostAwesomeDude: daum: This channel is for the open-source drivers, not fglrx.
MostAwesomeDude: For fglrx help, check #ati.
mjr: What he said, but I'll add that afaik x1550 isn't supported by latest fglrx. Don't know more, don't ask.
daum: ah i've heard that but according to ati's site it stil ahve it
daum: anyways, do the opens ource drivers support x1550 with dual monitor?"
daum: (that's all i really need)
soreau: I don't see why not
MostAwesomeDude: daum: Yes.
soreau: Where's agd5f been anyway?
MostAwesomeDude: Vacation.
soreau: Ah, know when he's due back?
MostAwesomeDude: Nope, sorry.
bridgman: I think agd5f is back monday
MostAwesomeDude: Ah.
bridgman: I hope so anyways ;)
soreau: bridgman: Thanks :)
yangman: not planning to come back after Canada Day? ;)
bridgman: no, but then again he lives in the US ;)
bridgman: I'm taking next week off though
bridgman: like it says on the t-shirt, I AMD CANADIAN
yangman: ah, I always thought he was in the Markum office too
bridgman: it looks better on the t-shirt; the D in and overlaps with the D in Canadian
yangman: don't know why I thought that
bridgman: nope, Richard and I are in Markham, Alex is in Virginia, Cooper is in Shanghai
MostAwesomeDude: cooper is on/off IRC now, I noticed. :3
bridgman: yep, everyone except agd5f still has to do it from home
bridgman: time to ping the nice firewall police again
bridgman: then again they do keep the worms & spam out, so I can't complain too much
bridgman: 37 million spam emails a day or something
MostAwesomeDude: Wow.
bridgman: yeah, it's impressive
bridgman: I still haven't figured out where they're getting our mailing list addresses
bridgman: I can't believe the spammers are finding them by shooting random addresses at the server
bridgman: that reminds me, I also need to nag the nice firewall police about not allowing sends to mailing lists from non-amd addresses
soreau: Does anyone happen to know the actual maximum texture size for rv250?
darksun_: i have a rv250 mobility 9000, does anyone know what the max texture size is suspost to be? mines reporting 1024, i was under the assumption it was supposed to be 2048?
MostAwesomeDude: 2048x2048 IIRC.
darksun_: any ideas why its reportign 1024?
bridgman: where are you seeing the limit ? maybe not enough memory or something ?
soreau: He's seeing the limit in the output of 'glxinfo -l|grep MAX_TEXTURE_SIZE' and the bug fix for the driver misreporting this info here is seemingly not working http://wiki.compiz-fusion.org/Hardware/ATI
darksun_: thnx soreau
bridgman: wow, that's probably the best answer I've heard in weeks ;)
soreau: =]
darksun_: i found a thread about it on launchpad, but no solution in there
daum: i'm looking at the drivers: http://xorg.freedesktop.org/wiki/RadeonFeature but ti seems they are all for vidoe cards that are pre x1550?
darksun_: mines VERY pre x1550
darksun_: lol :P
soreau: daum: Using gentoo?
daum: soreau, yes
bridgman: daum, R500 is X1300-X1950, R600 is HD2400-HD3870, R700 is HD4350-HD4890
soreau: daum: Remove ati-drivers, make sure your kernel config is ok http://www.gentoo-wiki.info/Radeon#Kernel_options then boot into it. xf86-video-ati should already be installed.
darksun_: ok, found an xorg.conf "hack" lemme try it
soreau: You may also have to compile xorg-server with -radeon iirc
daum: soreau, do i need really agp support? i have a x1550 pciex1 card
soreau: daum: I think you should follow those instructions, yes
darksun_: nope :/
darksun_: it worked without working
darksun_: i didnt get the garbage on the right side of the screen, but i didnt get anything anywhere lol
soreau: darksun_: What did you try?
darksun_: something with texturesize
darksun_: i lost the page when i reset :/
daum: soreau, alright so once i do that, how do i setup the dual monitor support?
soreau: daum: With xrandr
bridgman: airlied; ping - you guys interested in KMS results from an IGP345 ?
bridgman: for now I told the owner to use -nomodeset
darksun_: well, i know it CAN do 1400x1050, knopix live cd does it at that full compiz effects :/
airlied: bridgman: yes if he is running 2.6.31-rc1-git1 or higher
airlied: bridgman: otherwise he needs to run that, since I only fixed the ATI AGP driver.
bridgman: I think he's running out-of-box F11
bridgman: will check
bridgman: tx
bridgman: hmm, even with -nomodeset he's getting the same-ish error
bridgman: http://pastebin.com/d4b2c232e
bridgman: it is -nomodeset in the boot string, isn't it ?
bridgman: this isn't latest git, but I was hoping to avoid kms and just get him running
airlied: bridgman: nomodeset no -
airlied: bridgman: I need to backport the ATI AGP changes to F11
Scoobaspeaz: airlied: he is asking for me..he was helping me in #ati
Scoobaspeaz: so if i set -nomodset that wont do anything to help my problem?
bridgman: apparently you don't want the dash, so just "nomodeset" not "-nomodeset"
Scoobaspeaz: ah ok
Scoobaspeaz: after i download these updates i will set that in grub.conf and reboot
Kaneda: ok bridgman you back
Kaneda: airlied, you here
Kaneda: maybe you can help me in bridgman's place
airlied: Kaneda: maybe.
Kaneda: ok i have an x850 and im on ubuntu jaunty
Kaneda: and it works just fine for a desktop but im using it with xbmc for a media center
Kaneda: but it doesnt detect my tv through svideo
MostAwesomeDude: Ooh, goody, more XBMC buggies.
Kaneda: in gdm mode
MostAwesomeDude: Oh, wait. That's not an XBMC bug. :T
Kaneda: it detects it in ttyl mode
Kaneda: well i had it on intrepid and i couldnt get the resolution to work right either
airlied: hmm not sure we ever got r400 tv working
airlied: but if we did you probably need to enable load detection
airlied: xrandr --output S-video --set load_detection 1
airlied: or somethinf like that
Kaneda: this one
Kaneda: 76,310
Kaneda: ops
Kaneda: Option "TVDACLoadDetect"
airlied: you can do it at runtime now
airlied: the option might work.
Kaneda: would this page be sufficient for testing
Kaneda: http://www.x.org/wiki/radeonTV
airlied: pretty much
airlied: the enabling tv-out dynamically bit
Kaneda: cause i looked up the tv online to find out what it supported and ntsc was supported
Kaneda: http://www.dealtime.com/xPF-Toshiba-36AF53
Kaneda: i wish i could trade it for an lcd or plasma
Kaneda: but its what i have and i dont have the money for a new one :)
Kaneda: Can't open display
Kaneda: thats the response i get
airlied: you have X strarted?
airlied: you need to be inside the X session
airlied: if you can't get X to start then the statically options are probably needed
Kaneda: well im doing it remotely from ssh but i am monitoring it from another monitor
Kaneda: and the gnome is loaded
Kaneda: and im running in terminal
hifi: export DISPLAY=:0.0
Kaneda: :~$ sudo xrandr --output S-video --set tv_standard ntsc
Kaneda: Can't open display
hifi: dont use sudo if the X is running for your user
Kaneda: ?
Kaneda: i have to use sudo to run as root
airlied: is only root logged in on the display?
hifi: so you did start the X server as root?
Kaneda: my user is root technically
airlied: well export DISPLAY=:0.0 should help
Kaneda: :~$ sudo xrandr --output S-video --set tv_standard ntsc
Kaneda: Can't open display
Kaneda: oops
Kaneda: :~$ sudo xrandr --output S-video --set tv_standard ntsc
Kaneda: X Error of failed request: 164
Kaneda: Major opcode of failed request: 150 (RANDR)
Kaneda: Minor opcode of failed request: 15 ()
Kaneda: Serial number of failed request: 24
Kaneda: Current serial number in output stream: 24
Kaneda: i did the display part as well and it worked fine
hifi: tru it without sudo, just for kicks
hifi: try
Kaneda: same thing
airlied: Kaneda: does xrandr show an S-video output?
Kaneda: and i was looking at gnome so x should be going right
Kaneda: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024
Kaneda: VGA-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 304mm x 228mm
Kaneda: 1024x768 60.0*+ 75.0 70.1 60.0*
Kaneda: 832x624 74.6
Kaneda: 800x600 72.2 75.0 60.3
Kaneda: 640x480 75.0 72.8 59.9
Kaneda: 720x400 70.1
Kaneda: DVI-0 disconnected (normal left inverted right x axis y axis)
hifi: now theres your problem
Kaneda: i know s-video is hooked up
Kaneda: cause when i booted my system i saw lines and crap on my screen
airlied: the X driver isn't seeing it
airlied: maybe we don't enable it for r400
airlied: got an xorg log fie u can pastebin
airlied: ?
hifi: what card one other guy was using who also wanted working s-video but in the end we recommended to buy R200
hifi: you'll get a 9200 PCI for about $10 I think
Kaneda: your looking for xorg.conf right
Kaneda: airlied,
hifi: no, log
hifi: /var/log/Xorg.0.log
hifi: pastebin that