airlied: http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=r300-exa-experiment
airlied: contains my state emission playground.
airlied: it doesn't deal with other 3D contexts too well, like Xv or 3D apps.
airlied: but it gives an improvment on my rv515 (goes from 444000 to 460000)
airlied: but rv370 is still stucl
airlied: stuck evden
airlied: I wonder how r4xx family goes.
Magnade: airlied: something else clogging the pipe then?
airlied: Magnade: not sure, its very unusual, its as if the chip is crap :), but I know its not :)
Magnade: airlied: perhaps that shader reprogramming is more painful than you thought?
airlied: I suppose we could write a GL equivalent of what x11perf does and see what happen.
airlied: Magnade: my experiment doesn't reprogram the shader unless its chanfed.
airlied: changed.
airlied: or at least its not meant to.
Magnade: airlied: i guess then it leads to the question of is it changing more than one thinks?
airlied: Magnade: not from the dumping the state it doesn't looke like it
airlied: Magnade: and on r500 it got faster
airlied: just not r300
moondrake: airlied: maybe only r500 with many pipes (like yours)
airlied: moondrake: I've tried on my crappy rv515 and my good firegl
moondrake: a, excuses, both improve?
agd5f: airlied: maybe all the wait_untils?
airlied: yes both improve about the same.
airlied: agd5f: yeah I'm trying to remove those.
airlied: agd5f: I've removed one in composite.
airlied: and it hasn't hlep
Magnade: could the shader program itself be the issue?
airlied: Magnade: maybe but its like 3 instructions.
airlied: agd5f: maybe all the SWITCH_TO_2D/_3D stuff
agd5f: and the VAP flush probably doesn't help
airlied: agd5f: that isn't in th fast path.
airlied: agd5f: should only happen on init 3d
agd5f: airlied: yeah, but maybe init3d gets called more than it needs to
o_sleep: airlied: Heh, I also tried reoducing the state emissions, with equally negative results
airlied: agd5f: not in my tests.
airlied: o_sleep: the results on other chips are good :)
o_sleep: airlied: might be the CB flush
Terman: when running head of the git tree for radeon, I get the following messa when running glxinfo with LIBGL_DEBUG=verbose: unknown chip id 0x7145, can't guess.
Terman: this seems to be a mesa issue. which version of mesa do i need?
airlied: Terman: yeah no 3D support yet
agd5f: some of the CB registers aren't pipelined which can cause a stall
airlied: Terman: unless gears is all you want.
airlied: agd5f: I've optimused those out as well.
o_sleep: airlied: I have a half written test exa patch that should allow batching at least the glyphs in a single Glyphs() request together, which should reveal whether that is the case
o_sleep: (you can't just remove the CB flush, locks things up)
Terman: airlied: I don't really need 3D at all - it's more like playing with developemnt heads ;-)
Terman: airlied: radeon has all I need for everyday usage
airlied: o_sleep: yeah maybe uploading them all at once might help also
airlied: okay removing the switch to 2d in upload didn't help
o_sleep: airlied: the slowness occurs when nothing is getting uploaded at all
o_sleep: airlied: In my test it was all in video memory all the time
o_sleep: airlied: at least as far as I could tell ... pretty much a pure sequence of Composite of pixmaps already in video memory : draw glyphs onto temporary mask, draw temporary mask onto pixmap, repeat.
o_sleep: And as slow as heck. So, I'm suspecting the CB flush after every glyph out of lack of any other candidates, once I removed the duplicate state emission to no significant improvement
airlied: o_sleep: I've makde the post CP just a cache flush
airlied: instead of a free + wait
airlied: and it still doesn't help.
airlied: making it do nothing of course is failure..
airlied: I wonder can I move the fluhs to prepare access
airlied: I might try that
roh: hm.. compiĂling drm and xorg head again.
roh: has anything changes about that xaa-bugs on m56?
agd5f: roh: what xaa bugs?
roh: greenish picture
roh: fonts barely readable
roh: i pasted a url somebody elsen dropped with a screenshot. same here
agd5f: xaa or exa?
roh: XAA works but seems not really accel.
roh: EXA give that greenish one
roh: sorry.. i must have confused these 2 before
roh: bbiam. need to reboot for drm and fresh x11 drivers
airlied: hmm gdm dies on only flushing in switch to 2d/3d
airlied: agd5f: might be worth trying to find more info on dstcache flushing rules
agd5f: airlied: yup. I'll see what I can dig up
roh: drm: Unknown symbol clflush
roh: mmmh.. does that not exist in older kernelsĂź
roh: 2.6.22-14-generic here.. compiles fine. warns about it
airlied: damn flushing on CBoffset changes only also hangs gdm
roh: what does clflush do? and where should that symbol come from?
roh: hm.. adding an ifdef (like in i915_buffer.c around line 262) at the start of drm_ttm.c helps
agd5f: airlied: I found some things
agd5f: there is a penalty for things that require fb reads
agd5f: like blending
agd5f: flushing the cache before enabling these operations removes the penalty
agd5f: also, turning off blending when not needed will help. probably makes sense for textured video among other things
agd5f: also flushing the tx cache is a big penalty
agd5f: also, there's a penalty for re-using tx regs that are in the pipeline. better to use the an LRU scheme with the tx regs
roh: *grmbl* no..still doesnt work
roh: and crashes when one presses 1 in mplayer (changes the xv-params
roh: so exa -> still broken on T60p thinkpads for me
roh: funny thing.. the colors for the ui are wrong, for xv theyre correct
roh: http://yamato.hyte.de/tmp/xorg/
roh: screenshots and logs
roh: eh. one log. with exa
agd5f: I think I figured out some of the VAP problems on r5xx. VAP_INDEX_OFFSET needs to be expliticly programmed or the VAP will not function correctly.
natergator: roh: i had the same bug
natergator: roh: im going to link you to my bug report
roh: ok. will leave the log and screenshots there will fixed ;)
natergator: roh: see here http://bugs.freedesktop.org/show_bug.cgi?id=15225
roh: i use 24bit color there in my config
airlied: agd5f: so we shgould round robin the texture regs.
roh: natergator which do you use?
natergator: roh: 24 bit color as well
airlied: I tired removing TX_INVALTAGS to see what effect and it again it didn't seem to get much faster.
agd5f: airlied: according to some optimization tips I found
airlied: granted the render ing was all wrong.
natergator: roh: i guess I shouldn't say _the same_ bug, but very similar looking. also xv on my setup was displaying correctly
roh: natergator upped the config
airlied: agd5f: VAP might explain tcl gears being busted altright
airlied: maybe we need some better test.
agd5f: airlied: and tcl exa/textured video problems
natergator: roh: do you have a bugzilla account? you should comment on that bug report so that we can track that it's not simply faulty hardware
airlied: a test that just uses two textures repeating might be useful.
roh: natergator nope.
airlied: so we don't hit the texture flush
natergator: ok, i'll post a link to that directory index
airlied: roh: is that the X1300 t60p?
roh: airlied i think its a x1400
roh: (--) Chipset ATI Mobility FireGL V5250 found
roh: whatever that means *sigh*
airlied: roh: wierd I've got the same machine here.. and it works fin e:)
airlied: roh: you must not have a drm loaded or something
natergator: roh: what distro, processor, card are you using and how recent are your driver builds? did you say it was a lenovo t60?
roh: airlied i builĂt trunk drm and the ati driver
roh: natergator yes. lenovo t60p
natergator: ok
airlied: I'm typing this on my t60p now with ati + exa enabled
airlied: it all lookms fine to me
roh: type 8714-J3G
roh: with xaa i sometimes have a bit of 'dirt' on the mousecursor, besides that its fine
roh: airlied does it also crash the x11 when using mplayer -vo xv and pressing '1' ?
natergator: roh: thanks
roh: natergater its ubuntu gutsy (will up to hardy soon) with the tormod xorg packages, but i built and installed the git stuff over it
airlied: roh: what does pressing 1 do? nothing happens here.. movie keeps playing
roh: airlied crashes the whole xserver
roh: don't have a log.. gdm killed it
airlied: the .old log should be there
natergator: roh: i just ran "mplayer -vo xv:port=74 somevideo.avi", started playing and hit 1... nothing happens?
moondrake: roh: any reason for using depth 16?
roh: natergator interresting
roh: moondrake i use 24
natergator: ah. it seems it changes the contrast
natergator: if i dont run it through the texturedvideo adapter
moondrake: that log i see says 16..or am i missing up people now...
moondrake: *mixing
roh: ah.. no.. yes 16bit.
roh: seem to have changed that while running without accel. on 2 big screens it really makes a difference
moondrake: i guess: try 24
roh: will do soon. need to work for a bit now ;)
roh: still its a bug when one works and the other doesnt
moondrake: yes, but it would at least point to what is wrong. And since you have a color issue it is something i would suspect.
MrCooper: airlied: the text slowness could be due to reloading the shader and/or flushing the 3D cache for each operation?
airlied: MrCooper: my test branch doesn't reload the shader.
airlied: and also I've done a test that just flushes instead of frees/waits
MrCooper: and it's faster on your RV370?
airlied: MrCooper: surprisingly no :)
MrCooper: I played with the cache flushed but could only get it to lock up :}
airlied: I was trying to find somewhere else to flush it.
airlied: but failed also.
airlied: I thought on COLOROFFSET change or SWITCH_TO_2D
MrCooper: I tried the latter
airlied: MrCooper: http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=r300-exa-experiment
airlied: is where I got (doesn't handle the 3D or Xv cases)
airlied: the r500 does get faster with it.
airlied: but r300 not muhc.
airlied: the INVALTAGS and maybe trying to find the flushing rules
airlied: but changing texture stuff would probably mean changing other things..
MrCooper: airlied: bummer, but good work
airlied: MrCooper: I think need to make an r300_demo type test or some small GL app
airlied: I wonder how the radeon would deal with using the fb as a texture instead of doing the blending.
airlied: thats what Intel does..
airlied: MrCooper: wierd I'm seeing a lot of UploadToScreen that seem to maybe be unnecessary
airlied: MrCooper: I'm testing using a simple app from otaylor that should only upload once at startup.
MrCooper: possibly for the constant colour
airlied: it appears to be doing it every operation
airlied: oh maybe..
MrCooper: would be interesting to know what it is
airlied: its width 7 height 8
MrCooper: maybe it's the intermediate pixmap used by miGlyphs for accumulating glyphs
MrCooper: I think that could use some optimizations that used to be in exaGlyphs
MrCooper: like in this case I don't think it'll accumulate more than one glyph anyway :)
MrCooper: even so though, the UploadToScreen shouldn't really be necessary - does Option "EXAOptimizeMigration" avoid it?
airlied: damn need to rebuild too many machines all with varying Fedora rawhides.
glisse: airlied, agd5f: according to my understanding of unpipelined reg stall mean that the pipe stop processing any new stuff until its empty
glisse: so anywrite to an unpipelined register is costly
glisse: we should make a list of this register
glisse: for new drm i think i will cache such register and avoid writing to them if its in the same state as before
MrCooper: glisse: is this about RB3D_DSTCACHE_CNTL?
glisse: MrCooper: not only its about all unpipelined register
glisse: you got to go through the doc to make a list of them
glisse: the stall is explained in r5xx doc and i discussed a bit with John about it
MrCooper: glisse: that one should be pipelined without DC_FREE and DC_FINISH, which airlied tried
MrCooper: and you obviously can't cache writes to that register ;)
glisse: MrCooper: i won't cache this one but color buffer offset for instance
glisse: there is obviously some register that can't be cache :)
MrCooper: glisse: airlied also tried caching coloroffset and -pitch and it didn't seem to help much
glisse: MrCooper: did he try to avoid reusing same tx reg and invalidate tx ?
MrCooper: not sure
glisse: this also stall the us pipe if we do it for each glyph we loose
MrCooper: we probably do :)
glisse: also we should cache pixmap as we likely often reuse same texture
MrCooper: so we should use all tx regs round robin?
glisse: so no need to reuse it
glisse: MrCooper: yes but before make sure you are not reusing same texture as before
glisse: in fact the round robin should check if texture is not already present in one the reg
glisse: before using a new one
MrCooper: what if the pixmap contents changed since last time?
glisse: as long as it's at the same address it fine
glisse: well we don't have proper sync mechanism for that in current radeon anyway
glisse: at least i don't think
glisse: MrCooper: can't exa tell us when we done rendering to a pixmap so we flush at this time ?
MrCooper: glisse: it doesn't have a better concept for that than the *Done driver hooks
glisse: suck a bit
glisse: a lot
glisse: X miss a high level rendering scheduler
glisse: we can't make proper assumption at this level to when flush or not
glisse: gona go eat something bbl
Revellion: afternoon
eboettcher: wg 2
eboettcher: crappy wireless keyboard :/
peterz: doesn't see the use of these wireless input devices
peterz: all they ever do is run out of batteries
TobiasTheCommie: peterz: true
eboettcher: glisse: right now I have until noon to prepare my final gsoc proposal and while I eat my breakfast I thought I'd ask about some thoughts you have on timetables.
olegfink: hi
eboettcher: GSOC has its deadlines, so whatever I propose will be ongoing througout August.
olegfink: I think I've accidentally found a 100% reproducible deadlock for my R370
eboettcher: but I was wondering if there's say someone working on a TTM memory manager for Radeon, and if so, do they know when they expect to have something working?
olegfink: is it of any interest?
eboettcher: olegfink: anything similar in the bug tracker?
olegfink: bah! bug tracker.
olegfink: didn't even know it exists. sorry.
glisse: eboettcher: i am working on ttm
glisse: eboettcher: hopefully i will show glxgears this week or next week for xdc
glisse: eboettcher: the frag prog compiler optimization sound like a good topic which should fit in the timetable
eboettcher: glisse: unfortunetly I have not looked into that well enough to write a detailed proposal
glisse: but its also because i am interested in it that i say this is a good topic ;)
eboettcher: I started reading into the r500 acceleration doc etc
eboettcher: I have some time right now to look
MrCooper: glisse: not sure it's worth messing with LLVM outside of Gallium though
glisse: eboettcher: url i did give has all core information needed to understand what need to be done on r3xx hw to optimize fragshader
eboettcher: I've looked at the fragment shaders a bit in the past, but not in the context of gallium
MrCooper: at the very least you might want to talk to zackr about it first
glisse: MrCooper: just easier to compare human made optimization on few patological program if llvm outside gallium but this could be done inside
eboettcher: I do have a strong interest in r500 and beyond, but I think starting with r300 may be a good idea.
glisse: eboettcher: well r300 is a lot easier to optimize, in r500 you have many room for shader trick & optimization
eboettcher: glisse: well I have a stack of r{3,4}xx cards to test stuff on, all of them AGP
olegfink: eboettcher: hmmm, not at the first glance. Someone with better expertise might look. Was hacking compiz a bit and got a few lines which cause a deadlock.
eboettcher: my desktop's board as of tuesday is PCI-E so I can only use that r500 on my desktop
glisse: eboettcher: there is r4xx pcie but they likely hard to find now
eboettcher: the only other r300 is in my laptop -- xpress200m
Oleander: can aynone help me woth osx86 problem with video card
eboettcher: glisse: I have a friend with one -- I'm sure he'd be down with a r500 for r400 trade :P
eboettcher: has anyone messed with crossfire and the like?
glisse: no, we don't have much info on crossfire
eboettcher: I'll have a board that will let me do so -- AMD790FX chipset (found it for $100 USD :)
glisse: really we should focus on single card and just make sure we don't do assumption preventing us to latter generalize to multigpu
olegfink: http://gitweb.compiz-fusion.org/?p=fusion/plugins/widget;a=blob;f=widget.c#l265 <-- this if-else block reliably causes it
eboettcher: well after the summer I may mess with that
olegfink: err, else-if
eboettcher: glisse: I really don't know what will happen with crossfire -- I hear crossfire X allows cards of different generations to be mixed
eboettcher: which sounds like driver hell to me
glisse: eboettcher: not really i think it allmost endup of having a scheduler to dispatch draw on each gpu
ghepeu: eboettcher, you can find r300 pci-e cards for ~30€
glisse: moreover with newer chip all gpu core unit are the same
eboettcher: well what about say fragment shader features that exist on say an r700 but not an r600?
eboettcher: will that just exclude the r600 from rendering those fragments?
glisse: eboettcher: do you have an example in mind ?
glisse: eboettcher: i don't think there is much difference btw unit, likely only the texture unit and other setup unit are different
glisse: but not the shader unit
eboettcher: well I'm going to check out gallium right now
eboettcher: I have until 45 minutes from now to do so when I must get some serious work done on the proposal before asking for feedback
edgecase: eboettcher, pci-e r300 are cheap
edgecase: in north america, tigerdirect.com/.ca has x600 pci-e for $15
edgecase: rv370 IIRC
eboettcher: well if James will lend me his x800 XT then I'll gladly go for the free one :P
eboettcher: (I'm sure he will -- but it will take two weeks to pry it out of his machine because he doesn't want to turn it off)
edgecase: if you are able to fix things for r300 3d, i have about 20 x300's here...
edgecase: local surplus outlet, $0.50 each
edgecase: what continent, i'll mail you one
eboettcher: does anyone have anything to say about the state of dynamic clocks on rs400? this xpress200m generates a lot of heat on my laptop but I don't know if I should enable it given the other issues with this chipset I've had.
glisse: edgecase: you got pcie card ?
edgecase: yeah dozens of them
edgecase: low profile brackets mostly
edgecase: i think x300 was the first pci-e right?
glisse: well i am interested i don't have r3xx or r4xx pcie anymore :( a broken motherboard fried them
edgecase: d'oh
glisse: yes x300 was first
edgecase: well it's in my best interest to have radeons in the hands of developers
eboettcher: glisse: I've had trouble with my aging r300 cards :/
edgecase: eboettcher, if you're not using your AGP radeons...
MrCooper: I thought R420/X800 was the first PCIe card...
eboettcher: like an X800GTO AGP I have will do some very weird stuff after about 20 minutes.
edgecase: can you post a photo of the card? might be bad capacitors
edgecase: i reparied a GF Ti4200 last week like that
eboettcher: edgecase: let me get some rechargable batteries and I'll take photos of all my cards
edgecase: cool
glisse: MrCooper: you mean chronogicaly ?
glisse: :)
eboettcher: edgecase: I can't get that done until next weekend
MrCooper: glisse: yes, first as in 'first' ;)
eboettcher: these next two weeks are _BUSY_ for me :)
glisse: MrCooper: ;p
glisse: MrCooper: likely x800 was, highend always first
eboettcher: (strangly I consider the last two weeks of the semester when I have exams as a break)
glisse: x300 is the lowest pcie card
edgecase: eboettcher, i'm happy to get x300's to people, and if you have some weak and/or unused cards, you can send them to me
edgecase: glisse, yes, lowest, that's right, i didn't know about chronology
eboettcher: I have a collection of some really old cards :)
eboettcher: I have this one ISA video card with co-ax output that's about .3m long ;P
edgecase: eboettcher, i already have a lot of early pci stuff, missing r300s
edgecase: is that an ATI?
eboettcher: no
edgecase: I don't have any VGA wonders
eboettcher: my favorite old card I have is this Heath voice synthesizer
eboettcher: does anyone know of some sort of PCI-ISA bus adaptor I can use to mess with that thing again?
edgecase: get a PII mobo
eboettcher: I hope I can recover the asm of the old drivers -- stored on 5" floppies that are over two decades old :/
ghepeu: The oldest card I have is a Rage II+. I had a S3 Trio and a Trident VGA but they disappeared sometime in the last five years
eboettcher: I have a couple of older nv cards around, but the oldest ATI series card I have is a 128MB Radeon 9000
edgecase: the 9000, it has DVI-out?
eboettcher: (which I'll use to make sure I don't break r200 when looking for common code/updating)
eboettcher: edgecase: yep
ghepeu: then I have a Radeon 9000 Mobile in a laptop with a broken display, and a Radeon 7500 agp. My Radeon 8500 ceased to work misteriously and I trashed it 3 years ago
eboettcher: strangly it's one of the most reliable cards I've ever owned
eboettcher: but this r500 I have.. the stock cooling solution must go
eboettcher: do damn loud, yet it runs so hot
eboettcher: does anyone have any suggestions for cooling solutions? I was going to look at whatever asus, thermaltake, etc had for aroun d$20
eboettcher: USD
ghepeu: eboettcher, at the end of 2006 I bought a X550 silent because I was fed up with fan noise
ghepeu: on my secondary pc I'm using the Rage II+ because it doesn't need a fan
edgecase: ghepeu, rage II+ AGP?
ghepeu: PCI
edgecase: that won't do 3d
ghepeu: AGP didn't exist at the time
edgecase: board has agp slot?
ghepeu: I read something about a drm module for mach64 cards, but I don't need 3d on that machine
edgecase: local shop has *mountains* of radeon 7000 agp dual VGA out
edgecase: dell OEM card with EDD connector/fanout cables
edgecase: i've used mach64 3d, it runs glxgears ok
ghepeu: edgecase, it's a "silent" machine connected to a TV
ghepeu: until last year it was a pity to setup tv-out on radeon card
edgecase: the radeon 7000/7500 had no fans
edgecase: yeah tv-out working well now
ghepeu: with a mach64 you just need to start the machine with the TV connected
ghepeu: 7500 has a fan
ghepeu: pretty noisy fan, I must say
edgecase: oh? i find radeons work well with tv-out, dvi-out etc
edgecase: these 7500 have only a passive heatsink
edgecase: maybe you want one to develop r100 on ?
ghepeu: now they work well, but the tv-out support went in last summer, iirc
edgecase: oh in Xorg yes
edgecase: card's bios amazed me, tv-out for bios setup screen. i have component adapter in the mail, i bet that *just works* too
arekm: tv-out doesn't work well ;P I'll catch what's wrong today
edgecase: well i have some tearing, looks like sync problem
ghepeu: me? I'm not a developer, never had the time to seriously learn C
ghepeu: maybe when I'll graduate
edgecase: ghepeu, well tester then?
ghepeu: when I have time (read: when I'm procrastinating instead of working on my thesis)
edgecase: there is seriously a mountain of cards, hundreds of 7000/7500. i bought all the other kinds already :)
edgecase: ghepeu, ok well i'm interested in keeping mach64 from bitrotting too, i have 25+ server boards with Rage XL to keep going
ghepeu: the mach64 is actively developed
edgecase: ic. i have a few bugs queued up :)
ghepeu: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-mach64.git;a=shortlog
eboettcher: glisse: the swizzle has me mixed up but I'm sure I can straiten it out one of these hours today with a piece of paper and pencil
glisse: eboettcher: well you first need to understand swizzle in gl spec then i think my example is selfspeaking
glisse: :)
glisse: basicly card can't handle all swizzle natively
glisse: so some swizzle are emulated through inserting new instruction
glisse: which is costly
glisse: we would better reorganize shader code to use native swizzling
eboettcher: glisse: well I have a very short period of time here to get an idea of the whole scope of what I'll be doing with the shaders if I put it in my proposal
glisse: can't the proposal be a bit evasive on technical detail
eboettcher: so I'm wondering if I should add stuff like implementing say smooth lines or anything of that sort
eboettcher: glisse: I could, but there's a limited number of slots that xorg will get... and I'm trying to shoot for one
glisse: well adding feature like smoothline would be a good way to get started with the hw
glisse: plua you can add the google map run slowly on opensource driver because smooth line ain't implemented
glisse: i am sure this could help having gsoc :)
eboettcher: well it's the xorg people evaluating these, not google :)
glisse: specify on r300 hw
eboettcher: AFAIK, google only cares about eligability.
eboettcher: idge*
glisse: i am really ignorant of gsoc process :)
eboettcher: well I'm writing my proposal from other guidelines, but I hope I can get some feedback before the day is out
eboettcher: by noon I should submit it, and hopefully any requests for revisions can come before 5pm EST, I have until 8 or 9 to get the final version done
eboettcher: but I have work, class, lab today filling all of my time from noon to 8:30, spare a hour at 5:30 :/
glisse: gonna go will be back latter
spstarr_work: hmmm
spstarr_work: wonders why KDE 4's kwin when it uses composite is not smooth vs compiz use
eboettcher: glisse: as I read into gallium more I think I like it, and I'm glad I will start learning about it so early in development.
glisse: eboettcher: yeah gallium is a lot more clean & beautifull
eboettcher: glisse: I still will be proposing mesa/dri gsoc stuff, but I think I'll contribute to gallium where I can so that I learn about it
eboettcher: perhaps by the end of summer I can move my focus there
glisse: eboettcher: of course, i think that stating that you generaly want to improve r300 driver should be enough to justify working on gallium when its a bit more ready
eboettcher: if I had the time and skills right now I'd propose working on an r300 backend
eboettcher: well I have the time, but I can't gauge my skills
eboettcher: I'd rather propose something I know I can get done then come up with something I may fall short on
glisse: eboettcher: yes better in the frame of gsoc
eboettcher: I should mention my intentions for the future in my gsoc app I think
eboettcher: glisse: as part of my cleanup should I try to unify r200/r300/radeon?
glisse: eboettcher: useless now
eboettcher: why so
glisse: r200/radeon unification might make sense when a adding ttm
glisse: but r300 will stay separate in gallium
glisse: it just that it will be too much work for very low income
eboettcher: I see
eboettcher: so I'll look into unifying r200/radeon but I will separate common code from all three.
eboettcher: glisse: should I separate common code between r200, radeon, and r300?
glisse: eboettcher: well for now i would left aside all this consideration about unification
glisse: i think right time will be once we kill r300 mesa driver and start moving r100 & r200 to ttm
eboettcher: well it may help to move r100&200 to ttm if I unify those
arekm: glisse: is r300 for gallium even started?
glisse: arekm: kind off
eboettcher: for r300 it would be cleanups and feature implementations (color logic ops, smooth lines, etc)
arekm: git url? ;-)
glisse: arekm: i am not saying that thi is tomorrow
glisse: arekm: should be in private repo on fdo
glisse: mesa is still one the things for which i got several clone so maybe not
eboettcher: glisse: well then here's what I propose: I unify r200 & radeon, clean up the unifed radeon & r300, update r300 from changed r200 files, implement smooth lines, color logic ops, anisotropic filerting, GL_ATI_separate_stencil, and look into stuff like FSAA.
arekm: maybe accelerated stuff for screen sizes > 2048x2048 (or whatever the limit is in r300) in multimonitor randr setup? ;)
eboettcher: arekm: I thought r300 supported 4096x4096 render target
glisse: eboettcher: r300 shoundn't rely on any r200 files
eboettcher: (well I know the hardware -- do we in software?)
eboettcher: glisse: well some of the r300 files were based on r200 files that changed and I think I should look into if any of those changes are relevant
glisse: arekm: this is a complex task
glisse: eboettcher: well you know when you write a driver you often copy and existing one and start from it, end result is often far away from the starting point
glisse: so i wouldn't bother
glisse: r300 need cleanup in itself
arekm: eboettcher: 4096x4096 only from r500
eboettcher: glisse: should I ignore src/mesa/drivers/dri/{radeon,r200} alltogether?
arekm: then maybe tv-out detection improvements? actually I don't know whether hardware is crappy in detecting things or these are purely driver fault
glisse: eboettcher: only radeon_ might have things used
eboettcher: glisse: aside from possibly unifying them
glisse: eboettcher: don't follow you their
glisse: eboettcher: in r30 directory r200 file shouldnt be use
glisse: in r300 directory radeon file are partialy used
glisse: unification would only be btw r200 & radeon directory
eboettcher: glisse: indeed
eboettcher: but if I unified r200 and radeon then r300 would be using stuff related to r200 (but comming from radeon, not r200)
glisse: r300 shouldn't use anythings from r200 but longtime i havent looked at driver
eboettcher: glisse: r300 doesn't use anything from r200
arekm: who has old r200/r300 register docs? :) I wonder what's meaning of BIOS_4_SCRATCH bits
eboettcher: glisse: but there were changes to some of the r300 files copied from the r200 source at first. I will check if any of those changes are relevant.
arekm: or TV_MASTER_CNTL
arekm: one of these registers is probably guilty of breaking tv-out after suspend/resume cycle (https://bugs.freedesktop.org/attachment.cgi?id=15573)
glisse: eboettcher: that was my point earlier, things have diverged too much to bother to refind similitude btw the 2
glisse: easier to clean each one in their own
eboettcher: ok, then cando
arekm: ha!
arekm: radeontool regset TV_MASTER_CNTL 0x0000060b puts tv-out into working state
eboettcher: I'm going to look into what's up with the s-video on my xpress200m not working
eboettcher: (using proprietary drivers it fails to work as well)
natergator: roh: wondering if you still had that color issue at 24 bit depth
agd5f: eboettcher: problem with XPRESS chips is the ref clk. it's 14 Mhz and the tv code is hardcoded to 27 Mhz
eboettcher: agd5f: hm... I don't think I can do anything with that for now. I want to focus on learning about the 3d side of things so that I may be of more use to gallium after gsoc
agd5f: yeah
eboettcher: I think cleaning up the r300 code may help with my quest quite a bit, but right now I wonder if I should add r200/r100 unification to my proposal
arekm: agd5f: could you make a quick look at https://bugs.freedesktop.org/attachment.cgi?id=15573 and tell me which of these +- could be tv-out related (tested BIOS_4_SCRATCH, DAC_CNTL and TV_MASTER_CNTL so far but tv-out isn't correctly brought to life)
agd5f: both worthy tasks
eboettcher: agd5f: well in terms of r300 I'm proposing cleanup and implementing features like smooth lines, color logic ops, etc
eboettcher: the cleanup is my focus but I do want to spend time looking at the shaders
agd5f: arekm: bios scratch 4 is fine. that shouldn't affect hw state anyway. it's just to keep bios and driver in sync. bits are defined in radeon_reg.h
arekm: agd5f: well, something else makes difference since I already did regset on that register (to the value from tv-out "working" state)
arekm: could x600 be fried by playing with "radeontool regset" anyway? (this is notebook so replacing graphics chip would be hard 8)
eboettcher: ><
agd5f: arekm: and dac_cntl doesn't look relevant
rx__: it can be fried if you mess with the clocks right?
arekm: btw. by not working state I mean xrandr not being able to detect tv resolutions
agd5f: arekm: tv_master_cntl is definitely related
arekm: tried tv_master_cntl, too
agd5f: arekm: is it that tv out doesn't work at all or just load detect is broken?
arekm: agd5f: fresh laptop boot, start x, xrandr --output S-video --set load_detection 1, xrandr --output S-video --auto - tv resolutions are nicely logged into Xorg.0.log
agd5f: arekm: I suspect there is a particular process for initing the tv out cell that's not happening on resume. does posting the card during resume help?
arekm: suspend (to ram), resume, randr --output S-video --set load_detection 1, xrandr --output S-video --auto - no resolutions found
arekm: reboot and everything starts working again
agd5f: arekm: but does tv out work if you add the mode manually and force it on?
agd5f: arekm: for load detection, I suspect a gpio register is to blame
arekm: agd5f: didn't try. I'll test but first I'll find out how to add mode
arekm: + reboot
agd5f: arekm: I'm guessing the 0x1ac/0x1a8/0x1b0 GPIO regs affect the tv load detection
eboettcher: agd5f: I'm going to be documenting registers, updating their names in the source, but would it help to add more detailed notes to the wiki as I learn more about them? (IE: make an r300registers doc)
agd5f: eboettcher: even better to add notes to the source
arekm: agd5f: which register is that?
arekm: ok, I see
agd5f: arekm: I don't recall the names. check radeon_reg.h
eboettcher: agd5f: I'd leave short info in the source, but would detailed info be necessary there? I'll be gathering that information for my own sake, I'm just wondering if I should publish it.
arekm: agd5f: (II) RADEON(0): EDID for output S-video
arekm: agd5f: why it even tried edid on s-video? I remember someone saying that edid is not supported on s-video
agd5f: arekm: it isn't supported
agd5f: it doesn't try on s-video
arekm: hm, so what that message is trying to tell me?
agd5f: eboettcher: the more documentation the better :)
agd5f: arekm: the driver used to try to print out the edid for all outputs for informational purposes. I think it only does if it finds one now
edgecase: glisse, for your pci-e cards, what bracket do you need, low profile or standard?
glisse: edgecase: well one low profile and one standard would be nice
edgecase: these cards are all low profile, i'd have to steal a bracket from something else,
edgecase: also, they are mostly LFH-59 connectors
glisse: then just low profile
edgecase: do you have a Y-cable already?
edgecase: i have 2 that are S-video + DVI-I but i wanted to save those
glisse: i should have enough connectors now :)
eboettcher: diff r{300,adeon}/radeon_screen.c... they're identical
MrCooper: eboettcher: yes, the former is a symlink to the latter :)
MrCooper: eboettcher: only works with preprocessor magic though
eboettcher: indeed
eboettcher: there are other files like radeon_span.c where the differences are somewhere around 4 lines
eboettcher: r300/radeon_span.c needs r300_state.h, r300_ioctl.h while radeon/radeon_span.c needs radeon_state.h, radeon_tex.h, and radeon_context.h
eboettcher: other than that there are no differences
eboettcher: there are differences in the structs but I could look into preprocessor magic there as well
eboettcher: ifdef
Goga777: will be in April the new spec's opening from AMD/ATI ?
arekm: agd5f: hmm
arekm: agd5f: driver doesn't see bits set in RADEON_TV_DAC_CNTL
arekm: agd5f: http://pld.pastebin.com/f346d3cc7 and I'm getting not detected code path
arekm: agd5f: if I understand this code correctly then hardware is supposed to set this bit
agd5f: arekm: yes
eboettcher: agd5f: DRI/Mesa is in the title of my proposal but should I add anything else to see that it's directed to the right place?
agd5f: eboettcher: I think that should do it. although I've never submitted a gosc proposal so...
eboettcher: well I submit to xorg, but I don't know who's doing the administration for xorg gsoc
eboettcher: (via the dashboard on google's site)
eboettcher: I know xorg will be allocated a number of slots based on how many people apply for them, but beyond that I don't know how xorg plans to distribute those to sub-projects.
arekm: I guess that without docs it will be hard to fix tv-out here. I have no idea what I could try
arekm: probably "asking" procedure isn't fully correct
Revellion: otaylor: hmm upgraded pixman and xorg-server
Revellion: took some time
Revellion: but nope results are fairly equal :S
otaylor: Revellion: Sorry, I think we didn't convey the information to you properly
Revellion: otaylor: hmm?
otaylor: Revellion: After debugging some, agd5f realized what you are seeing is a bug in the DownloadFromScreen code
Revellion: aaah
Revellion: oh nvm. i now remember it in the channel
otaylor: Revellion: basically downloading tiny textures is not reliable. And that's a radeon thing not an X server thing.
otaylor: Revellion: Well, you have a nice shiny new server now :-)
Revellion: mhm, hardware specifics :\
Revellion: otaylor: true ;)
Revellion: nice side-effect
Revellion: got some nifty stuff with it
Revellion: though DRI2 / Mesa caused me some grief initially :P
Revellion: inspired me to possibly become a package maintainer for git builds in ArchLinux of Xorg
Revellion: xorg-server / pixman / a few video/input drivers mostly. not all video/input drivers. too much effort :D
Revellion: could help those brave people who dare to step into latest and greatest.
Revellion: oh well, i'm gonna ignore the elephant in the living room for now. the glitches are not visually appealing for sure but they dont inhibit functionality XD
otaylor: Revellion:I'd suggest not turning on AccelDFS
Revellion: otaylor: i'd have to explicitly disable it, it's default apparently on PCI
otaylor: Revellion: yeah
Revellion: though disabling AccelDFS do come with a performance penalty most likely i reckon..
edgecase: glisse, so you are OK with low profile card, with LFH-59?
glisse: edgecase: yup
glisse: eboettcher: i would advice to not do fsaa
glisse: i am not sure but i think you need a bigger buffer and without memory management any solution will need hack in major component other than mesa
airlied: I suspect for r100/r200 TTM you'd want to wait for gallium r300 winsys
airlied: and reuse it as much as possible.
glisse: airlied: btw i got exa working if i got time i do dri2 tomorrow, gears after tomorrow and doom3 after after tomorrow ;)
airlied: glisse: you shuold video tape yourself and sell a how to write device drivers video ;-P
rx__: i'd be interested in that
rx__: :)
rx__: actually i'd be more interested in a vid on graphics card terminology and structure
glisse: i already got most of the piece, winsys, dri, ... it just a matter of bringing same together and polishing things
agd5f: if anyone wants to test powerplay support, I have a rough cut here: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=agd-powerplay
mattst88: all R500s support PowerPlay?
agd5f: mattst88: I think so
mattst88: If all goes well on my end, I'll get you some feedback from my DEC Alpha/R500 system :)
airlied: all mobile ones..
airlied: my desktop ones don't seem to have tables.. at least rv515 didn't
agd5f: my rv30 did, but only 1 power state
mattst88: I've got an RV516 (X1550)
mattst88: nevertheless, it should be interesting to test with an alpha box, no?
TobiasTheCommie: what is powerplay?
agd5f: mattst88: try the driver. it'll print out the tables
agd5f: if there are any
agd5f: TobiasTheCommie: power saving stuff
TobiasTheCommie: ah, oki
TobiasTheCommie: ah, wel,l got an rv530 here (x1600), but currently using the closed source driver as pal tv-out is broken in the radeon driver... but if you find you need it, pop me a pm, i'll give it a swing
rx__: http://websupport.sk/~stanojr/projects/atipower/
rx__: this guy had powerplay on a desktop part
rx__: (if i'm reading correctly)
agd5f: you can adjust the mclk and sclk to whatever you want, but YMMV...
rx__: oh
rx__: very nice
rx__: sets them both to 0
rx__: how is the pll calculation done?
rx__: oh.. looks like atombios handles it
TobiasTheCommie: airlied: as far as i can see only the radeon hd 3800 has powerplay(that and, of course, the mobility versions)
agd5f: TobiasTheCommie: all of my cards have tables, just tht most of the desktop cards only have 1 state
TobiasTheCommie: and isn't that state "fully powered on"?
agd5f: TobiasTheCommie: yup
TobiasTheCommie: *sigh*
TobiasTheCommie: :)
agd5f: TobiasTheCommie: some also have overlock modes
TobiasTheCommie: i'm glad that hardware producers have finally started to implement the power saving on desktop products.. but it has taken too god damn long
TobiasTheCommie: i wanted it 3 years ago
agd5f: TobiasTheCommie: the basic stuff generally works in desktop cards already, it's just not explicitly listed in the tables
TobiasTheCommie: agd5f: more like, my core2duo will only clock down to, i think, 1.2ghz, instead of the 300 i believe the mobility version does...
TobiasTheCommie: agd5f: so, it should be able to get it working for the r5xx/6xx series desktop versions?
rx__: it looks like it just calls a script with the desired clock speed as an arg
TobiasTheCommie: hm
TobiasTheCommie: that's positive
agd5f: TobiasTheCommie: it will print out what power modes are officially supported. if you choose to, you can make your own, but YMMV
TobiasTheCommie: nice..
TobiasTheCommie: :)
rx__: is the interface going into randr anytime soon?
agd5f: don't blame me if you overclock your chip and fry it :)
agd5f: rx__: randr 1.3
agd5f: gpu objects
TobiasTheCommie: agd5f: my intention was to underclock it
TobiasTheCommie: though, ehm, on second thought, that might not be an issue for me anymore.. since i'm now running xbmc-linux, which uses the gpu quite a lot.
rx__: are gpu objects already implemented?
rx__: or is it still in discussion
TobiasTheCommie: till now i've mostly just done 2d stuff.. not even compiz... so... i really have no need to run it at fullspeed
TobiasTheCommie: or rather had
rx__: bookmarks the cgit url for later :)
rx__: thanks agd5f :)
rx__: does this do voltage scaling?
agd5f: rx__: not yet. I haven't sorted that out
TobiasTheCommie: i wish i knew more about hardware, and hardware coding...
rx__: don't we all :)
TobiasTheCommie: so i could fix my own damn bugs..
TobiasTheCommie: yeah, everyone in the entire world wishes that i, TobiasTheCommie, knew more about hardware and hardware coding
rx__: yes we do ;)
TobiasTheCommie: no, i don't have an inflated sense of my place in this world
TobiasTheCommie: MostAwesomeDude: that's got to be misrepresentation
MostAwesomeDude: TobiasTheCommie: Eh? What's up?
MostAwesomeDude: Oh, my handle? Comes from Bill&Ted. "Most awesome, dude! Party on!"
TobiasTheCommie: :)
TobiasTheCommie: hehe
MostAwesomeDude: Be right back; testing suspend.
eboettcher: glisse: I just got back from work :/
eboettcher: I guess I can look into it, perhaps something may change between now and July.
natergator: agd5f: is there anything i can do about my Xorg logs being filled with thousands of lines of "enable montype 3"
agd5f: natergator: probably xine or some desktop thing forcing the display on at a regular interval
natergator: agd5f: it sleeps after 5 minutes though?
natergator: (and i dont use xine)
agd5f: natergator: you can comment out the line that prints it in legacy_output.c
natergator: agd5f: is it indicative of anything i should be investigating, or just comment out the line and forget about it
agd5f: natergator: that just means the output was turned on.
natergator: agd5f: ok, thanks
GerbilSoft: probably isn't related to a recent driver update, but who knows
GerbilSoft: i tried to connect a VGA monitor to my T60p just now, and it seems that the HSync and VSync lines aren't showing any signal
GerbilSoft: DDC works, and the RGB lines are working right