Radeon IRC Logs For 2008-10-23

spstarr: airlied: i pasted above some tracebacks
spstarr: airlied: looks like using DDX w/ on 3d we get drmWrite waiting
EruditeHermit: spstarr: are you getting hard locks with radeon?
EruditeHermit: spstarr: r300
spstarr: not hard locks
spstarr: two kinds of busy waits
EruditeHermit: how did you debug them?
spstarr: two ways
spstarr: attach X to gdb remotely via an ssh session to machine
spstarr: when X appears to lock ssh into box and get a snapshot of the system processes running and kernel states… echo ‘t’ > /proc/sysrq-trigger
spstarr: dmesg > dump
EruditeHermit: ok
EruditeHermit: I think the problem may just be the patches that ubuntu used in the package version in Intrepid
EruditeHermit: I am using a git snapshot now and it isn’t locking
EruditeHermit: atleast it hasn’t yet
cxo: wtf happened to the site
EruditeHermit: which site?
cxo: the site, the x site, the git repos
cxo: it hasnt worked all day today
EruditeHermit: hmm
EruditeHermit: might have crashed
spstarr: ya
EruditeHermit: its happened before
cxo: someone should install linux or bsd on it
cxo: this is the 2nd time its down in hardly a few weeks
MostAwesomeDude: airlied:
MostAwesomeDude: Evening.
MostAwesomeDude: Hmm, maybe sleep is a good idea.
MostAwesomeDude: Anyway, yeah, I kinda doubt that this is going to be in any way reliable when multiple apps are running.
MostAwesomeDude: Good news is, can’t really hang the card.
EruditeHermit: MAD: what are you working on?
MostAwesomeDude: EruditeHermit: Occlusion queries.
MostAwesomeDude: Oh, also, I have no idea how well running multiple queries will work.
MostAwesomeDude: In theory, we should *always* have the results of an OQ ready sometime after EndQuery and before IsQueryAvailable.
MostAwesomeDude: At any rate, is r300Flush() then begin_cmd()/e32() the correct way?
EruditeHermit: MAD: is this OGL2.0 stuff?
airlied: you probably need to use a state atom..
MostAwesomeDude: airlied: I was thinking about that, but the problem is that I have to write to a handful of registers repeatedly.
MostAwesomeDude: Should I write SU_PIPE_DEST, ZB_ZPASS_ADDR, then flush, then repeat?
airlied: thats a bit nasty 🙂
airlied: do you need to wait after you write them?
airlied: or can you just write them in a row..
MostAwesomeDude: Well, how would I do that with state atoms?
MostAwesomeDude: Have one atom for each register pipe?
MrCooper: MostAwesomeDude: have you looked at how the intel driver does it?
airlied: you can just setup the atom with a number of register writes in it.
MostAwesomeDude: Hmm.
MostAwesomeDude: I’m not sure how I’d get them to alternate. I guess my atom-fu is weak.
MostAwesomeDude: Hm. The Intel driver goes one step further and supports ARB_query_object.
MostAwesomeDude: Okay, so I looked at both tdfx, and intel.
MostAwesomeDude: Intel’s got a linked list of queries. I guess that the chipset doesn’t return queries in predictable time?
MostAwesomeDude: Tdfx locks hardware, pokes a couple registers, then unlocks.
MostAwesomeDude: We want to flush, so the query’s complete, then poke ZPASS_ADDR.
airlied: we don’t do poking 🙂
MostAwesomeDude: This is where it gets iffy. Since ZPASS_ADDR would be written to by both pixel pipes, we want to only enable pipe 0, then dump, then enable pipe 1, then dump, then enable both again.
airlied: I don’t see the problem with emitting a state atom with SU_REG_DEST/ZPASS_ADDR pairs in it
MostAwesomeDude: airlied: I just don’t know how to do it. :c
MostAwesomeDude: I am bad with atoms.
MostAwesomeDude: Okay, so I’m chillin’ inside r300_context.h and lookin’ at the atoms. How would I make an atom that emits to two addresses in a row? Are there any like that already?
airlied: lots of them
airlied: lemme go find one.
airlied: have a look at the R500_FP_CMD
airlied: it does cmdpacket0 to a few addresse
MostAwesomeDude: So, cmdpacket0, data, cmdpacket0, data? And just mark it dirty, flush?
MostAwesomeDude: Is there a way to keep it from being emitted at the beginning, with all the rest of the dirty state?
airlied: MostAwesomeDude: good question.
airlied: maybe a state object isn’t what you need 🙂
MostAwesomeDude: Also…the docs say “an address in main memory,” does that mean I should be passing pointers into VRAM, or into, well, system RAM?
airlied: MostAwesomeDude: you’ll need to have the kernel supply the pointer
MostAwesomeDude: Hmm. Sounds fun.
MostAwesomeDude: Especially since I’ll need two such pointers.
airlied: we already have the read_rptr stuff in the kernel.
airlied: it takes a page
airlied: we only use a bit of it so far
MostAwesomeDude: Sounds good.
MostAwesomeDude: I really can’t think of any better way to do this than to flush, emit out the handful of pointers and pipe selects, and then just go back to normal.
airlied: you want an atomic way to emit all the values and give them back to userspace
MostAwesomeDude: Well, it would be enough to just write to those registers, five in a row, and then go back to business as usual.
airlied: you can use the big lock for it for now I suppose
MostAwesomeDude: The only catch is, *gotta* flush before doing that, because if we don’t, I’m fairly certain we’ll get incorrect sample counts.
MostAwesomeDude: So, expensive no matter what.
MostAwesomeDude: The big lock…that’s the UN/LOCK_HW one, right?
airlied: yup..
MostAwesomeDude: That one’s always awesome. It’s all, “I’m lockin’ yer card!”
MostAwesomeDude: Okay, so I’ve got most of the Frankenquery rigged up.
MostAwesomeDude: The only thing missing, are the two pointers that we’re gonna read from.
MostAwesomeDude: Also I suppose I should figure out how to save them, so that we can read from them later, after writing them.
MrCooper: beware that we aren’t always using the status page for writeback stuff because it isn’t reliable with some AGP bridges, so glisse suggested writing to VRAM instead
MrCooper: (although we could probably make writeback reliable everywhere by putting the status page in normal PCI space rather than in the GART aperture)
MostAwesomeDude: I don’t know anything about that. All I know is that Frankenquery thirsts for blood. And sample counts.
MostAwesomeDude: Okay, so. This read_rptr thingy. How do I use it? I’m not seeing anything in Mesa for it…
MostAwesomeDude: Is this a GEM thing?
MostAwesomeDude: Alright. I need to do the sleeps now. But, all that I need now (I think) is info on how to get two pointers that I can read and write to, and that I can pass into the card.
airlied: otaylor: not sure I’ve fixed the hang yet, I found some other issues though, off for a couple of days will hopefully get to it next week.
glisse: hhhmm there could be several query concurently ?
glisse: i didn’t get that from the spec
glisse: anyway occlusion query are lot easier to do with a memory manager
glisse: MAD|sleepin: also you need to disable COLOR & Z writing when doing so at lest this is my understanding that occlusion query doesn’t write to color buffer
glisse: maybe i should read the spec again 🙂
glisse: also i don’t see a QUERY_OBJECT ext
glisse: ah no it’s up to the program to choose to write to z or color buffer
glisse: MAD|sleepin: for multiple query simply write different addr
spstarr_work: hello
spstarr_work: glisse: are we able to convert the r300d driver to DRI2 or not yet?
Phoxis: hello, i wanted to know that is there any recent major performance updates in the new ATI driver for integrated cards i have Biostar TA690G motherboard, with ATI Radeon Xpress 1250 integrated graphics
Phoxis: i am using Fedora 8 x86_64 (AMD Athlon64 X2 4400+)
spstarr_work: oh he built another DDX snapshot package
glisse: spstarr_work: i have been doing dri2 yesterday
spstarr_work: glisse: any stuff for testing in git?
glisse: now i am fixing mesa to stop assuming sarea exist
glisse: once i get software working i will push it to fdo
glisse: but today and tomorrow i will be busy with other stuff
spstarr_work: even SW is fine
spstarr_work: i will test if you think it is usable
spstarr_work: glisse: will this is be in git master or a branch? for mesa?
spstarr_work: do i need a newer drm kernel module or it has all the bits?
spstarr_work: im using rawhide so it’s the latest drm bits that i know of
glisse: you need kernel modesetting
spstarr_work: got that
spstarr_work: so then just a new build of mesa?
glisse: and i will push them in my own fdo repository in a branch
glisse: no you also need my branch of the ddx
spstarr_work: do you have airlieds bits for kms in the ddx?
spstarr_work: otherwise i will pull your branch the try to add in patches for ddx
glisse: spstarr_work: yup there is airlied bits in it
glisse: maybe not the lastest one
spstarr_work: he has some new fixes in cvs fedora
spstarr_work: http://koji.fedoraproject.org/koji/buildinfo?buildID=67196
spstarr_work: memory allocation fixes
glisse: proliferation of branch are nightmare
glisse: especialy nowadays in this big move
spstarr_work: glisse: i noticed 🙂
spstarr_work: glisse: but massive upheavals are necessary
spstarr_work: we must stabilize the graphics stack, if DRI2 gets us there a little more then so be it
spstarr_work: DRI2 will help solve some of my issues with running out of VRAM
glisse: dri2 will make things worse in that aspect
paxcoder: glisse: are you talking about Mesa dri?
paxcoder: *just got here
spstarr_work: glisse: worse? its bad now 🙁
spstarr_work: glisse: with 64MB of VRAM things get quite slow unless i can use the GART but right now its not using it in DRI1(?)
glisse: spstarr_work: well dri2 use private backbuffer instead of shared one
glisse: so you need a backbuffer for each gl app
glisse: of course all this backbuffer are not necessarily in ram
glisse: paxcoder: dri2
spstarr_work: glisse: hmmm t
glisse: but in the end dri2 + memory should perform a lot better than today setup
spstarr_work: yea
glisse: just need to be clever about memory migration
glisse: which will likely need works
glisse: s/memory/memory manager
paxcoder: glisse, yeah. when you said dri2, I assumed dri2. Funny how I still asked a question. hmmm
terracon: updated rawhide bits. When I run glxgears , instant lockup .. sigh
terracon: 10-28 final development freeze for fedora 10
terracon: I don’t think kms will be ready
otaylor: terracon: r300?
glisse: what is the release schedule of fedora10 ?
otaylor: glisse: http://fedoraproject.org/wiki/Releases/10/Schedule
otaylor: glisse: I’m sure we’ll be putting X fixes in past “final development freeze”
glisse: sadly X is still second citizen in OSW
spstarr_work: it shouldn’t be
glisse: understaffed
spstarr_work: in fact, if X is got problems I would block Fedora 10 and any future versions 😛
otaylor: spstarr_work: well, there are going to be *problems*
spstarr_work: yes
spstarr_work: otaylor: would you happen to know what would stop GNU make from launching parallel builds?
spstarr_work: broken GNU libc? 🙂
otaylor: spstarr_work: tha’ts pretty much inevitable :-), but clearly crashing on common hardware is a problem, and would be a blocker (though turning off kms for certain cards would probably be the solution to the blocker rather than slipping the date)
spstarr_work: when I do make -j5 on a quad it only spawns one
otaylor: spstarr_work: well, it’s all about the structure of your makefile
spstarr_work: airlied mentioned he could disable kms for r3xx if we have too many issues
spstarr_work: otaylor: GNU coreutils , mysql.. tried them both
spstarr_work: nothing seems to enable parallel
otaylor: spstarr_work: not really an expert in the area, I’m afraid
xnguard: spstarr_work: I’ve seen some Makefiles and configure processes explicitly override -jX with -j1. coreutils seems unlikely, though.
spstarr_work: xnguard: yeah, but i doubt overclocking a CPU would stop make from using multiple cores..
xnguard: spstarr_work: …this just started happening after you applied an overclock?
spstarr_work: looks to be…
xnguard: spstarr_work: I’m not sure it’s even *possible* to detect an overclock from inside Linux, or possibly even Windows. Or at least it would be extremely complex, without something highly explicit to talk to, like the ABIT uGuru modules.
spstarr_work: right
spstarr_work: so then im puzzled why make -j5 only spawns one thread
spstarr_work: nothing in aliases set
xnguard: spstarr_work: If parallel make suddenly works again after you back off your overclock, my first guess would be that you’re running into temperature problems or somesuch. Got powertop installed to look at that?
spstarr_work: im watching the sensors
xnguard: Intel or AMD?
spstarr_work: Intel
spstarr_work: the box is cool
spstarr_work: 34-38C right now even
spstarr_work: 46
spstarr_work: 50
xnguard: Intel keeps their power-related secret sauce… pretty secret. But I think you’d have to hit at least a core (pun unintended) temperature of 65-70C to kick off thermal throttling.
otaylor: spstarr_desk: make -j5 doesn’t know or care how many cores yo uhave
spstarr_work: xnguard: I *do* have that enabled in bios
otaylor: spstarr_desk: that’s why you have to say ‘5’
spstarr_work: xnguard: but the threshold lm sensors says is 85 hot, 100C critical
spstarr_work: 5/
spstarr_work: even if i try make -j3
xnguard: spstarr_work: I’m not aware of a way to disable CPU-level thermal throttling at all, ever. Intel wouldn’t be very popular if they let you override that and cook your cores.
spstarr_work: even -j3 isn’t spawning cores
spstarr_work: its only on 1 core
otaylor: spstarr_work: I’d read through the make info pages … you may have the wrong expectations about what make -j should be doing
spstarr_work: otaylor: its supposed to spawn 5 make processes if i use -j5
spstarr_work: parallel
xnguard: spstarr_work: How much overclock are you squeezing, here? And are you messing with voltages or non-core-clock oscillators to get it?
otaylor: it’s not that simple
spstarr_work: xnguard: i have 2.4->3.0Ghz with proper bios
spstarr_work: xnguard: although /proc/cpuinfo shows 1.6Ghz per core
spstarr_work: upgrading rawhide anyway…
xnguard: spstarr_work: I don’t know what “proper BIOS” means in this case. Did you have to increase the speed of anything besides the CPU clock? IIRC, at least on Intel platforms, you still have to increase your FSB speed to get a CPU clock increase.
spstarr_work: maybe bug in kernel causing bad scheduling who knows..
spstarr_work: i did
spstarr_work: the memory is 800Mhz but you drop it to 667Mhz so that when the FSB is raised it goes to 802Mhz
spstarr_work: PCIE is 100Mhz
spstarr_work: FSB 333Mhz from 266
xnguard: spstarr_work: My best guess is that you’ve managed to destabilize something in the process of overclocking. Your memory, your memory controller, or something else. I’d back it off before something worse happens. Or start increasing system voltages to try and compensate for the increased clock.
spstarr_work: xnguard: its done by the bios if it detects something is bad it would shut off
xnguard: spstarr_work: I wouldn’t trust the BIOS to do spit, honestly, no matter how much money you may have paid for the board. And from what I’ve seen, things the “BIOS” is supposed to handle are actually taken care of by Windows helper apps making BIOS calls.
spstarr_work: nonetheless, i will bring it back to original speeds if this rawhide update doesnt fix it
spstarr_work: for all I know it could be a broken GNU libc update 😉
xnguard: spstarr_work: If I were you, I’d hope that the update wasn’t broken by the overclock. 🙂
spstarr_work: na
spstarr_work: yum update -y
spstarr_work: just packages not BIOS update 🙂
otaylor: spstarr_work: the assumption that the operation of make -j has anything to do with your overclocking is highly dubious… I think you are just grasping at straws
spstarr_work: otaylor: yep
spstarr_work: otaylor: but i should have seen more than one cc spawned
spstarr_work: box is rebooting
spstarr_work: assuming it didn’t panic on shutdown 🙂
kdekorte: spstarr_work: I use MAKEFLAGS=-j 4 on my Q6600 and compiling mplayer uses up all the cores to compile…
spstarr_work: kdekorte: i have a Q6600
kdekorte: I can compile mplayer after a dist clean in < 2 mins
spstarr_work: kdekorte: i will try this tonight
kdekorte: with my old machine it was about 7-8 mins
spstarr_work: hmm, it wont come back up heh
spstarr_work: that’s rawhide
spstarr_work: hmm the box is up
spstarr_work: but i cant ping it and mii-tool shows the interface is alive
spstarr_work: im curious to see why when i get home now 😉
terracon: otaylor: R350 . so yes
otaylor: terracon: airlied was relatively positive about fixing some more of the issues though he’s gone for a few days
spstarr_work: otaylor: he made some progress last night
spstarr_work: er his day
otaylor: spstarr_work: yeah, but there are still major issues
spstarr_work: otaylor: i hit 2 different busy wait paths
spstarr_work: one with DRI used, one with just DDX
otaylor: spstarr_work: yeah, ounds about right
spstarr_work: those and another is if you restart X with GNOME it will crash
spstarr_work: when compiz is on
spstarr_work: or kwin composite
MostAwesomeDude: Okay, so I’ve got most of the stuff set up. How do I do this read_rptr stuff? Is it an ioctl? I’m not finding anything in either DRM or Mesa trees…
glisse: MostAwesomeDude: this is the cp rptr
glisse: in radeon_cp.c
glisse: dev_priv->ring_rptr->offset
glisse: basicly use addr after that one
glisse: but you got a limited amount of them
MostAwesomeDude: glisse: What’s the safest way to do that, and how do I get it from kernel space to Mesa?
glisse: airlied: am i blind or is their no gem bufmgr in your fedora branch of mesa ?
glisse: you won’t get it to mesa
glisse: its kernel only
glisse: well not safe neither good to get it to mesa
glisse: you need to manage this in the atom stuff
glisse: see how memory manager can help in such case ? 😉
glisse: world will be brighter with it
MostAwesomeDude: glisse: Indeed. :3
MostAwesomeDude: Yeah, I was thinking, I need to malloc two 32-bit ints of card space, and use those, and free them when I get done.
glisse: MostAwesomeDude: well in memory manager world i would allocate a page and manage it from userspace
MostAwesomeDude: If that’s the preferred way, then sure.
glisse: if you run out of memory userspace would be able to allocate one more page
glisse: MostAwesomeDude: it’s just sounds crazy to allocate a dword only 🙂
MostAwesomeDude: One page, I think, would be a *lot* of queries worth. Shouldn’t be problems.
glisse: memory fragmentation and all this kind of things
glisse: MostAwesomeDude: never assume their won’t be more query than that 🙂
MostAwesomeDude: glisse: Yeah. I agree. I was merely stating what I need.
glisse: i am sure one guy out there is doing hundred of them
glisse: 🙂
MostAwesomeDude: But because we have to flush the card in between, he’s not going to be able to run more than two at a time. When queries become ready, we deallocate the pointers used.
spstarr_work: glisse: atom == atomic?
glisse: MostAwesomeDude: you don’t need to flush
glisse: spstarr_work: no
glisse: spstarr_work: not in this context
spstarr_work: i see
glisse: welcome to GPU land ! 😉
spstarr_work: shakes fist
MostAwesomeDude: glisse: Gotta flush before changing the pipes and sending the addresses.
glisse: no need to
glisse: MostAwesomeDude: on begin query if no query is already running 0 the counter
glisse: on end query write an addr
MostAwesomeDude: Well, right now, we’re not using atoms to change the pipes. airlied and I were looking at this, and for now, we’re using the big lock and raw writes. It might be possible to atomize it…
glisse: then pull the addr
glisse: MostAwesomeDude: you can do this in kernel land
glisse: not in mesa
glisse: well at least if kernel land know the number of pipes
MostAwesomeDude: glisse: ioctl-assisted query?
glisse: MostAwesomeDude: no you do an atom like the cliprect one for instance
glisse: you can just pass the number of pipe then kernel land build the cmd stream which does write one different addr to each pipe
glisse: kernel also would handle the addr so i will record the number of concurrent query
glisse: and kernel will pull query end
glisse: then i think you need an ioctl to get result
glisse: but i would strongly vote against this
glisse: as we could do it without this burden with memory manager
glisse: and without adding ioctl while i strongly want to remove all of them :o)
glisse: maybe you can add get query result to getparam ioctl
MostAwesomeDude: Hm.
glisse: this way no need to implement poll from kernel land
MostAwesomeDude: Yeah, sounds like moar plumbing’s needed.
glisse: s/from/in
MostAwesomeDude: Okay, so there’s CheckQuery, which just checks to see if it’s done, and WaitQuery, which is supposed to poll for it.
glisse: MostAwesomeDude: yup, did i already said that this would be a lot easier with mm ? 😉
MostAwesomeDude: Mesa should be able to poll if we don’t provide WaitQuery.
glisse: MostAwesomeDude: make getparam return 0xFFFFFFFFFFFF if no query are done yet
glisse: or a valid number of the first query which is done
MostAwesomeDude: Oh, and r300->radeon.radeonScreen->num_gb_pipes is the number of pipes, visible in Mesa. :3
glisse: hhhmm maybe you need query id
glisse: MostAwesomeDude: you can pass number of pipe through atom which is then used by the kernel
MostAwesomeDude: Nah, each callback gets a gl_query_object, which has a unique ID.
glisse: MostAwesomeDude: so kernel land would be a bit harder to do you need to store in kernel addr corresponding to query id
MostAwesomeDude: Right.
glisse: and then in getparam you need to supply id
glisse: then kernel look at the id addr
MostAwesomeDude: Yeah.
glisse: don’t forget to set addr to 0xfffffffff on query begin
MostAwesomeDude: Either a table in kernel land, or a table in Mesa. Intel does it by wrapping gl_query_obj, but that’s kinda hackish IMO.
glisse: also if query is inside another query you need to wait for previous query to end and substract the number of previous
MostAwesomeDude: Can’t nest queries.
MostAwesomeDude: Illegal according to spec.
glisse: oh so you have begin(query)end(query)
glisse: and never begin(queryid1)begin(queryid2)… ?
MostAwesomeDude: Right.
MostAwesomeDude: BeginQuery(), draw stuffs, EndQuery(), and then retrieve it later.
glisse: ok then simple table do the trick and writing 0 to zpass_Data on begin query each time
MostAwesomeDude: Yep.
glisse: airlied: okay so i think it’s time to revist a bit cs 🙂
glisse: basicly my chunk thing : chunk with a table of relocation, chunk with cmd stream and nop3 packet indicating and offset in the reloc chunk table
glisse: so no complex list walking in the kernel we can simply copy in one shot from userspace
glisse: do reloc and if fail return, if successfull then parse cmdstream
glisse: hhhmmm in fact parsing cmd stream might be done first so we don’t do reloc for nothings
otaylor: glisse: I think airlied may be gone until monday or so
glisse: otaylor: then i got time to do the code 🙂
otaylor: tries to figure out how r300_texsubimage is apparently writing random data
glisse: otaylor: this is what we call a feature…
otaylor: glisse: you driver hackers….
otaylor: glisse: is r300 using memory manage buffers for textures at the moment, or is it just faking it?
glisse: faking
otaylor: glisse: so it just statically allocates pieces of vram for each texture or something?
glisse: big pool of vram which is then managed
glisse: ie allocated on startup and then managed by the drm more or less
otaylor: glisse: that makes it harder to understand what is going wrong here … subimage doesn’t *do* anything,really just writes the data into vram
glisse: yup
glisse: otaylor: what is wrong actualy ?
otaylor: glisse: basically i have an array of perfectly good data (verified manually) I call glTextSubimage2D with it, and the texture is apparently updated to have junk instead of the data I passed in
otaylor: I probably need to actually look at the vram after the data is written since it *is* mapped
otaylor: (this is far from a clean test case …trying to get metacity-clutter working,and there’ some reasonable chance it’s just a clutter bug)
glisse: otaylor: well worth looking at vram, i don’t remember callpath for TextSubImage2D somethings might be wrong their
glisse: though we would had bug report since long time if so
MostAwesomeDude: Hmm. Guess it’s finally time to suck it up and get a GEM kernel.
airlied: glisse: no GEM bufmgr for mesa yet..
glisse: airlied: well i am doing a modified bufmgr with a modified cs
airlied: why don’t you emit an irq after the query? and wait for it?
glisse: airlied: won’t work zpass_addr are written when pipe is flush/idle
glisse: well when all previous rendering is done
airlied: don’t they stall the pipeline?
glisse: i am not exactly sure but if not then we need to insert flush (pipe) btw query
airlied: I don’t think so…
glisse: airlied: no
airlied: just change pipe and emit new one.
airlied: the docs mention they stall
glisse: i think we are not talking about the same problem 🙂
airlied: glisse: I still have issues with inline relocs…
glisse: my understanding is :
airlied: I’m not sure they save us anything due to having to pre-scan to find illegal domain interactions.
glisse: write zpass_data to 0, dorendering, write zpass_addr with different addr to all pipe, reenable all pipe, flush pipe
glisse: airlied: with the chunk thing you got only one entry per bo
glisse: 2 entry for same bo being illegal
airlied: ah I re-read what you said.
airlied: so how are we going to build it in userspace? i.e. grow the chunks..
glisse: yup
glisse: easy in userspace realloc should be fine, as it will start with a page
glisse: and i don’t think we will have more than one page for normal use case
glisse: i got the header if you want
glisse: doing the c file right now 🙂
airlied: I should check the size a lot of IBs are bigger than one page.
glisse: for the reloc table i mean
glisse: but for the packet chunk i am sure it will be bigger than one page
glisse: as one page is mostly what default state take
airlied: of so the interface will take num chunks and pointers to each.
airlied: like writev
glisse: no
glisse: chunk header is: chunksize,chunktype,then chunkdata
airlied: so how are you going to give them to the kernel linearly?
airlied: memcpy relocs onto end of cmdbuf?
glisse: so in kernel we only get numchunk,size
glisse: and the copy size/4 dword from userspace
otaylor: (btw, the TexSubImage problem was a clutter bugin the end)
glisse: i think its easier to have one big copy from userspace in the kernel rather than several
glisse: also then we only have to alloc one bigbuffer in kernel to copy from userspace
airlied: glisse: it doesn’t matter if we copy stuff around in userspace or the kernel
airlied: it still costs the same…
airlied: doing something like readv/writev might save a bit.
glisse: airlied: well in all case we have to copy in kernel space so while we are parsing packet we know userspace isn’t doing bad things
airlied: but if you have to copy the relocs onto the end of the IBs to submit it to the kernel
airlied: you are getting an extra copy that really you could avoid..
airlied: granted its only a page.
glisse: airlied: well i am doing an helper things that allow you to both in the samebuffer so no copy
glisse: basicly i start with a page big relocchunk, followed by ibchunk (one which will grow)
glisse: and with bit of logic it could alloc default ib size big enough
airlied: we always alloc 64k now, as long as we don’t copy it all to the kernel it should b e fine.
glisse: airlied: this is where the chunksize info at top of chunk helps
glisse: before submitting you add all chunksize
glisse: and tell kernel the result so kernel only copy necessary size
airlied: glisse: sounds good to me :), I’m off for a long weekend 🙂
glisse: airlied: well i should have time to do this during this next few days 🙂
glisse: i will see if this looks good or not
airlied: glisse: http://people.freedesktop.org/~airlied/r300-bufmgr-new-cs.patch
airlied: contains some hacks to the bufmgr to try and move the fake bufmgr to new CS style
airlied: I was going to finish that and then add GEM .
airlied: I’ve also done the aperture sizing stuff in mesa/-ati, however the GEM one is really dumb..
glisse: airlied: well i am wondering how we should report to userspace how much memory it can use
glisse: through some ioctl or others ways
airlied: glisse: yup an ioctl and maybe a reply to cs submit
glisse: to tell new limit ?
airlied: so we can fill in a new value after every CS.
glisse: maybe the driver can do an empty cs to the value
glisse: so no new ioctl
glisse: i like lowering the number of ioctl this is my aim in life 😉
airlied: well I have an mm info ioctl.
airlied: we could just add initial size to that.
airlied: or use a getparam.
glisse: yup i have seen the mm info, i am not sure this is usefull
glisse: sounds like we should have a sysfs
glisse: i am also thinking that we should do a sysfs for debugging
glisse: like a file which dumps number of fifo and card status reg
glisse: so we can have a generic informations gathering
airlied: no sysfs for normal use.
airlied: debugging is fine.
airlied: but one value per file kinda sucks…
airlied: we might just use debugfs.
glisse: hhhm never looked at debugfs 🙂
glisse: i was looking for a filesys a bit like /pro
glisse: i was looking for a filesys a bit like /proc
glisse: where we can stuff several things in a file
airlied: we need some way to tell X what RAM it is allocating from
airlied: so it can size the buffers.
glisse: so yes we need a way to report some memory informations
airlied: we also need to solve the hidden VRAM 🙂
glisse: well i see no problem their 🙂
glisse: it’s normal things we need to migrate on map
glisse: i think this all what we need to do and also maybe some cleverness in the allocator based on hint from userspace
glisse: so we allocate barely never mapped buffer their
airlied: we have to also deal with the cursor maps and possibly overlay ones needing to be in a restricted address space
glisse: we have limit for cursor ?
airlied: yup, number of bits on r300..
agd5f: airlied: we could avoid the cursor issues if we allocate the cursor as part of the scanout buffer
agd5f: since the cursor offset is based on the display_base
glisse: agd5f: sounds like the way to go 🙂
glisse: adding one page to scanoutbuffer should be enough maybe
agd5f: for overlay, we can just set the ov0_base to where-ever we’ve allocated the memory and adjust the offsets
agd5f: yeah 4k for each cursor
spstarr_desk: airlied_away: enjoy your time off 😉
edt: The amd 790GX has a ati radeon igp 3300hd. Anyone know what ati chip is used eg. R6xx?
mattmatteh: edt, i thought i found by googling that is r7xx
edt: mattmatteh might be but ref have seen refer to the amd chipset not the ati varient – other HD3xxx(s) use R6xx gpu, suspect this one does too..
mattmatteh: ref ?
mattmatteh: refer ?
mattmatteh: edt, how about what cxo said ?
spstarr_desk: has a 3650 HD its an r6xx
mattmatteh: rs790 ?
edt: mattmatteh lshw reports rs790 as the host bridge.
edt: lshw actually reports rs780
terracon: spstarr: do you use gdm or kdm?
spstarr: kdm but i can switch to gdm on notice
terracon: so your kdm appears if you use kms?
spstarr: ya
spstarr: i can log in too
terracon: what R*** ?
terracon: with R350 kdm with kms enabled. X/kdm don’t appear
spstarr: rv350 mobile
terracon: I’m not sure if the machine hangs or I can ssh in. I’ll have to see if I can ssh in
spstarr: what xorg.conf
spstarr: pastebin plz
terracon: no xorg.conf
spstarr: hmmm
spstarr: what kernel
spstarr: what version
spstarr: what ddx version
spstarr: what version of libdrm
spstarr: what version of mesa
terracon: whatever is in rawhide : ) I update everyday and it’s been like this for awhile now
spstarr: well, -31 for ddx?
spstarr: -13 for mesa?
terracon: yes, yes
spstarr: at least -30 + for kernel?
spstarr: how much ram on video card
spstarr: laptop?
terracon: 39 for kernel
spstarr: same for me on all of it
terracon: desktop and 256 meg on card
spstarr: ok so its a different one
terracon: wait or is it 128. hmm can’t remember
terracon: does it say somewhere in xorg.log how much vid card ram
terracon: must be 128 megs on the card
terracon: mesa -13 , ddx -30
terracon: testing -31, back in a sec
terracon: I just tried -31 ddx and it does the same thing
terracon: and If I choose kde from gdm . The login starts but stops , no kde
spstarr: :/
terracon: I can ssh into the machine though
spstarr: ok
spstarr: can you do two things
spstarr: su to root
terracon: and than …
spstarr: echo ‘t’ > /proc/sysrq-trigger
terracon: and what will that do
spstarr: echo the running system state to dmesg
spstarr: then dmesg > dump and pastebin
spstarr: the drm parts
terracon: I’ll do this tomorrow I’m fading . zzzzz

Radeon IRC Logs For 2008-10-23

Rig Lab Hardware

You Might Also Like

RadeonHD.org | Radeon IRC Logs For 2008-3-02

RadeonHD.org | Radeon IRC Logs For 2008-12-13

RadeonHD.org | Radeon IRC Logs For 2008-11-23