airlied: agd5f: hmm no luck with lid..
agd5f: natergator: https://bugs.freedesktop.org
legume: hi - is there any progress on the docs for the PCIE -> AGP chip on the RV530 yet?
agd5f: legume: I've looked into it, but I haven't gotten a chance to put anything together yet
CornedBee: TexturedVideo on my r500 works very nicely,
CornedBee: but it has a tendency of completely locking up the computer
CornedBee: beyond even the capabilities of SysRq to recover.
CornedBee: Does anyone know of this problem?
CornedBee: And: how do I track something like that down?
legume: agd5f:OK thanks.
legume: I have tried BusType PCI but this fails aswell, is this expected or a seperate issue. I get a log message about server in infinite loop.
agd5f: legume: I don't think that will work in this case
agd5f: CornedBee: are you using the latest drm from git? XAA or EXA?
CornedBee: no drm module at all
CornedBee: that would probably be it, right?
agd5f: CornedBee: try with the drm. the MMIO paths are not as stable for some reason on r5xx
CornedBee: I get the DRM module from the mesa repo, right?
agd5f: CornedBee: it has it's own
legume: agd5f: Ahh - I'll give up playing for now then :-)
Araneidae: I'm using a Sapphire X1650 card and wondering which driver to use. I was using the fglrx driver, but I'm unimpressed by its robustness. Which driver should I try -- I want 3D games to work!
ejs1920: i'm afraid you're stuck with fglrx for now if you want to play 3d games
CornedBee: none of the os drivers currently support 3d
Araneidae: Oh poo
ejs1920: they do for r300/r400
CornedBee: For the X1xxx cards, the radeon driver is probably closer to supporting it, but less stable
Araneidae: That's kinda frustrating. Is there active work on the radeon driver?
ejs1920: yes, lots
ejs1920: glxgears has been run on r500 hardware
ejs1920: people are working on it
Araneidae: That's cool. I see a bunch of options: vesa/fglrx/dbdev/(plain) in the "Choose Graphics Card Driver"
CornedBee: Yes, but most of them are fallback things
Araneidae: Oh. Am I best off trying the plain Radeon driver, and then going back to fglrx until things settle down?
Araneidae: What's really irritating about the proprietary driver is that after playing a 3d game, restarting the X server goes very peculiar -- a bit hard to describe, actually!
CornedBee: Well, the r500 3d support of the plain radeon driver is not available in any release
CornedBee: only in the developers' private codebases.
Araneidae: oh, ok.
ejs1920: indeed, and you need latest git for exa render accel and xvideo on r500
Araneidae: And how does the r500 relate to the x1650?
ejs1920: x1650 is r500 class
Araneidae: Hmm. I dithered between ATI and nVidia, and chose ATI because they're supporting OS ... but I'd also heard that nVidia drivers were lots better than ATI drivers. I guess I'm too early ...
CornedBee: For an end user, yeah, too early.
CornedBee: For freaks like me, just perfect :)
Araneidae: Cheers, thanks for the clear explanation. I'll go and put up with fglrx for now ...
roh: well.. i am still up for the adventure of building the git tree.. any pointers how to do that properly?
CornedBee: first, you get git
CornedBee: then you go to a directory and check out the tree
CornedBee: git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
CornedBee: or xf86-video-radeonhd, if you want to try the radeonhd driver
CornedBee: then cd into the new directory
CornedBee: mkdir build
CornedBee: cd build
CornedBee: ../autogen.sh --whatever
CornedBee: Those are configure-like options.
CornedBee: When autogen is done, make
CornedBee: and make install as root
CornedBee: Then you need to adapt the xorg.conf, but that's a different issue.
roh: well.. i currently use the tormod build of xorg-ati
roh: which does xrandr and gives atleast working modeswitching and native res.
roh: but no accel yet
roh: so the xconfig should be fine, right?
CornedBee: if you have the correct module path for your own builds
roh: hm.. i wonder if.. *diffing*
roh: do i need dri from git also?
CornedBee: only if you actually plan on developing some 3d support, I think ;)
styrman: join #ati
styrman: has someone seen something like this before? http://img90.imageshack.us/my.php?image=shot0000nq6.jpg i have no idea where to pindown the problem
roh: yeah.. works
roh: for dri.. any hints? or same concept, different repo
roh: hm.. textured video doesnt work without dri?
roh: which is it? http://anongit.freedesktop.org/git/mesa/drm.git ?
tilman: roh: depends on what card you're using. for r3xx and r4xx, the stable drm is good enough for textured video
tilman: is that r6xx?
roh: i think so
ejs1920: no its r5xx
tilman: no idea whether there's drm support for that yet. i know there's a drm branch for r5xx
roh: "ATI Mobility FireGL V5250" (ChipID = 0x71d4
roh: (WW) RADEON(0): R500 support is under development. Please report any issues to email@example.com
roh: jap. 500
agd5f: all r5xx chips should work with the drm from git
roh: is that http://anongit.freedesktop.org/git/mesa/drm.git ?
agd5f: roh: git://anongit.freedesktop.org/git/mesa/drm
roh: very smooth so far.. for bleeding edge stuff
roh: modules compile, load.. now the fancy moment.. restart the x
roh: should i switch to EXA via configfile or does the x fiddle that out itself?
roh: eeek. with EXA on and dri everything looks like that screenshot someone posted above
roh: that one
timofonic: Hello. I have problems with xorg under a ATI Radeon 9200SE (R280 I think). Not sure if I can ask about this in this channel, but channels of my linux distro an #xorg not reply about it so I suposse there could be people with experience on radeon hardware
timofonic: Here is the log: http://rafb.net/p/JNFSOr63.html Here is xorg.conf: http://rafb.net/p/P0SXEs78.html
roh: and what is it what does not work?
roh: with XAA the colors are correct. but accel is slow. xvideo shows wrong colorspace or so
timofonic: roh, here colors are wrong in certain way. Its quite difficult to explain for my limited english
timofonic: A part of the screen show colors correctly but refreshing is slow (60hz probably)
timofonic: Other part show scolors quite wrong and you can see weird horizontal lines
timofonic: And stuff there is darker
timofonic: Not sure how to explain, its one of the most weird things I did see in my life of using Linux :O
timofonic: I dont have a camera here...
timofonic: My english is inaccurate, sorry
timofonic: Using xorg-server 220.127.116.11-r3
roh: hm.. sorry.. have to go.. bbl
timofonic: ok :(
timofonic: Im not kidding, its quite weird but real
timofonic: 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
timofonic: I finally fixed it using this command: xrandr --output VGA-1 --mode 1280x1024
edgecase: how much info about LVDS port does radeon driver have? does the internal LVDS transmitter on mobility chips ( Radeon Mobility M7 LW [Radeon Mobility 7500] for example ) support 18 and 24bit, is that pin-strapped or BIOS/driver configured?
prahal: agd5f: did you had time to look at my hack to avoid restoring the memmap register twice ?
glisse: agd5f: as your memory is likely more fresh on the RS_IP_* stuff what is the link btw TEX_PTR or COL_PTR from what we got from VAP stage ?
glisse: agd5f: from quickly reviewing r300 code this number indicate which output of OUT_VTX_FMT we use as source
glisse: but in render code for second texture you set 2, while you only have 2 texture coordinate ouput active so 0 & 1
glisse: airlied: you might also have better memory on that stuff too :)
airlied: glisse: its to do with the input tot the frag program
airlied: glisse: not the output from the VAP I think
agd5f: prahal: yeah I saw it
glisse: airlied: RS_INST_ deal with the frag prog routing
airlied: glisse: okay let me have a proper look then :)
glisse: RS_IP deals with the input from earlier stage VAP or direct routing if no TCL
agd5f: glisse: it's the position in the output stream from the VAP.
glisse: airlied: i kept forgetting about this things and always waste time refinding how it works
glisse: agd5f: so if you have tex0, tex1 in OUT_VTX_FMT_0
glisse: they should be referenced as 0 & 1 in RS_IP right ?
agd5f: glisse: it's 2 because you have S and T (positions 0 and 1) from the previous texture
airlied: glisse: I think its more to do with PSC
airlied: but I'm barely awake yet..
agd5f: glisse: if you had more texture coordinates, you'd offset accordingly
glisse: agd5f: so if i set RS_IP_0 to use 4 coordinate then i have to set RS_IP_1 tex to 4 right ?
airlied: that sounds moe likt ie..
airlied: r500 is a lot different
airlied: well more flexible.
glisse: airlied: i don't think r500 is very different for this, been looking to that doc too
agd5f: yes, I think so. RS_TEX_PTR() is the offset into the rasterizer input stream
airlied: glisse: it doesn't have TEX_PTR on its own.
airlied: glisse: it has individiual ones per component
glisse: airlied: yup right
glisse: airlied: got to many pdf opened :)
agd5f: so you can set it to anything as long as it matches the ordering you want in the previous stage
agd5f: texture coordinates from the previous stage that is
edgecase: arlied, can you tell me anything about LVDS ports?
agd5f: glisse: you can overlap RS_TEX_PTR() if you want to share the same coordinates or pack coordinates
airlied: edgecase: you keep missing an i in my name so I don[t get highlighting :)
glisse: agd5f: i still think i need to do some test case because, its strange that you set 2 while in RS_IP_0 you output 4 components
airlied: edgecase: the driver can set the panel format.
airlied: edgecase: I'm not sure we ever do though.
agd5f: glisse: there are only 2 inputs from the previous stage
agd5f: S and T
edgecase: heh AIRlied, note to self. yeah when do you ever *need* to POST a mobility chipset?
glisse: agd5f: by previous stage you mean from VAP ?
agd5f: glisse: yes
edgecase: it's getting that in the LVDS info from BIOS?
airlied: edgecase: resume mostly.
airlied: edgecase: I'm not sure..
edgecase: (II) RADEON(0): Panel ID string: 1024x768 etc etc
airlied: edgecase: not sure the depth is in it thoguh
glisse: agd5f: but you program R300_VAP_PROG_STREAM_CNTL_EXT to output 4 component
edgecase: oh right resume
agd5f: edgecase: panel format is in the lvds info tables
edgecase: ok i'll look at the code, thanks
agd5f: glisse: you because if you don't it doesn't work ;)
agd5f: glisse: you set 2 text components in VAP_OUT_VTX_FMT_1
glisse: agd5f: okay so we should just pay attention to VAP_PROG_STREAM_CNTL data type
glisse: oh true
glisse: agd5f: now i understand once again this routing, i should write it down somewhere
airlied: glisse: yeah we've no idea why the PSC_EXT needs all 4 bits.
airlied: glisse: but stuff breaks badly without it
agd5f: glisse: VAP_PROG_STREAM_CNTL_* is what is important I think in this case
glisse: airlied: i think there is a stage with a z or w divide you cant control or somethings like that
agd5f: or rather the non-EXT regs
agd5f: glisse: at it to the wiki
prahal: gee got radeonfb+radeon dri s2ram working . . about my "patch" not much to keep but it pinpoint the issue , that we change the value of fb and agp location before calling restore thus we prevent it from seeing it should execute the "change" code . I though either the code to fix fb and agp location if changed could go in its own function (and get called from both Adjust and Restore though it looks a bit weird) or ... well I need idea
prahal: for other solution (it is tricky to Adjust change the locations then try to guess the old ones in Restore to apply the "change" code properly
agd5f: prahal: yeah, the drm should set the fb/agp_loc correctly, but we need to update the disp1/2/ovo bases
agd5f: I think the current code is fine as that's that the driver used to do anyway
prahal: ok I was trying to fix the weird screen that appears between vt switches by removing layers of calls as far as could be ... but this one was not enough to fix it anyway (I am pedantic about the UI looking good ...)
airlied: prahal: when the kernel gets a modesetting driver for rdeon, we can avoid lots of the problem states.
rx__: is exa more favorable than xaa for all radeon cards?
agd5f: rx__: at this point, yes
agd5f: airlied: http://www.botchco.com/alex/xorg/atomlidfix.diff might fix the lid issue...
airlied: agd5f: nice one.. seems to fix it
airlied: will make my boss happy :)
agd5f: airlied: excellent!
edgecase: interesting, a lot of LCD seem to be only 18bit color depth, i wonder if there's some color banding
edgecase: so the DDC, is there an i2c controller, or is it a bit-banging style on radeon?
airlied_: edgecase: bit banging..
airlied_: there are offload engines though
edgecase: just lacking driver support?
edgecase: it seems like there's a switch, that connects the i2c "controller" to various ports
edgecase: one at a time
airlied_: yeah pretty much driver support, i think some code in radeonhd might use them..
airlied_: not all the i2c'able lines are useable with offload engine
airlied_: in particular most of the GPIOs aren't..
edgecase: the bios tables seem to be the glue that shows how the board is wired
airlied_: on older radeons it was mostly guess work :), especially with LCD panels
edgecase: the more i get into radeon the more i appreciate the hardware
edgecase: the hardware is really good, seems that ATI's achilles heel has always been their drivers
edgecase: i mean the BIOS is smarter than Matrox of similar vintage, driving DVI at native resolution at bootup, s-video too
edgecase: i will say tho, the DDC stuff, it seems there's no interrupts, it's all polling, which isn't ideal for plug and play
airlied_: edgecase: what do you mean DDC interrupts? to detect you plugged in a monitor?
edgecase: yeah like load-detect
edgecase: i mean grandr is pretty good,
edgecase: but the ultimate would be, plug in something, grandr pops up a notification "would you like to enable DVI-0 ?"
airlied_: edgecase: we can do that for DVI monitors with interrupts
airlied_: edgecase: we just have to figure out the hot plug pin routing
airlied_: but really using hotplug as a notifier and then doing a DDC poll will mostly work
edgecase: pick a GPIO, any GPIO...
airlied_: but for VGA its messy as you need to poll or leave the DAC powered up, both of which suck for laptops
edgecase: well dvi is a start
edgecase: i'm not seeing anything that configures LVDS port, 18/24 bits, single/dual channel
airlied_: we probably haven't met a 24-bit lvds panel yet
edgecase: or the BIOS handles it? RADEONRestoreBIOSRegBlock() will that init a chip from power-on?
edgecase: it reminds me of the X300 bios decompile
airlied_: the BIOS might handle it, and I suppose we could just save/restore it from then on.
airlied_: also most likely atombios deals with it correctly and older cards didn't see 24-bit cards
edgecase: could be, this thinkpad's 2 panel options were both 18bit
edgecase: perhaps there are things in the LVDS table that bios uses, which radeon doesn't know about
airlied_: edgecase: for TMDS?
edgecase: not sure, radeon_output.c
airlied_: its a clock vs data timing selection
airlied_: some older monitors are non-coherent, most new monitors are coherent..
edgecase: duly noted
edgecase: looks like RMX could be used for DVI out
airlied_: edgecase: some monitors have to use it..
airlied_: edgecase: big 30" apples can only do two modes
edgecase: it's a hardware scaler, for lowres video for example
airlied_: for playing fullscreen games you really want it..
airlied_: I can't imagine many of them running native at 2560x1600
edgecase: what, 5fps should be enough for anyone :)
edgecase: starcraft heh