Radeon IRC Logs For 2008-12-03

mib_gxbfamnj: OK, so I have a mobility radeon hd 3600 – I thought I’d be able to get some kind of native support from my fedora machine for this card, but it seems I don’t get any of the nice eye-candy that I was expecting. Where do I start looking to ensure this card is configured correctly ?
hifi: HD 3600 sounds like R600
mib_gxbfamnj: I’v just upgraded to Fedora 10 running the latest kernel 2.6.27.5-117.fc10.x86_64
mib_gxbfamnj: OK, so, no native support yet ?
airlied: no native support et.
airlied: at least no accel et
mib_gxbfamnj: Actually, this is something that bothers me, why so many different names for the same card
airlied: ATI marketing like names.
mib_gxbfamnj: where do I find the definitive name ?
airlied: there are usually two names.
airlied: marketing name and engineering name
mib_gxbfamnj: lspci lists it as I described
hifi: http://dri.freedesktop.org/wiki/ATIRadeon there is a list of chips but I can’t find HD 3600
airlied: HD3600 is a marketing name, rv6xx is the engineering name
mib_gxbfamnj: 01:00.0 VGA compatible controller: ATI Technologies Inc Mobilitiy Radeon HD 3600 Series
mib_gxbfamnj: where would I see that rv number ?
mib_gxbfamnj: dmesg ?
hifi: http://xorg.freedesktop.org/wiki/RadeonFeature and theres a list of currently supported features for each chip
airlied: nowhere really, the are in the drivers.
mib_gxbfamnj: BTW, I also see this ATI device in lspci – 01:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 Series]
airlied: so its an rv635 then
mib_gxbfamnj: why does it show up as an adudio device ?
airlied: HDMI has audio
mib_gxbfamnj: Ah
mib_gxbfamnj: So, even though I don’t see any audio jack on the card, the new DVI style connector has audio pins ?
airlied: no pins, the audi is transmitted in the digital stream.
mib_gxbfamnj: ok
mib_gxbfamnj: So, after having read way more documentatation than is healthy, I’m more confused than ever. Which driver should I be using for this card ?
mib_gxbfamnj: It seems like I want Radeon HD
hifi: in either case you have no acceleration
airlied: doesn’t matter.
hifi: oh sorry, radeonhd has acceleration
airlied: no it does’t
hifi: from the RadeonFeature site it has basic 2D acceleration?
mib_gxbfamnj: That’s what I like to see, confusion in the ranks ?!?!
airlied: noton that card.
airlied: all radeonhd accel code is copied from radeon
hifi: shouldn’t the state be WIP rather than DONE if it’s not complete?
airlied: it has shadowfb which isn’t basic accel.
airlied: it no accel.
airlied: bad wording.
hifi: the row header shouldn’t be “Basic 2D Acceleration” then
hifi: XAA is the basic acceleration, EXA fast and ShadowFB is?
airlied: no XAA is the old accel,
airlied: I doubt we’ll ever do XAA for r600 unless Novell really want some work.
airlied: EXA is the newest accel arch which we are just getting stable now on everything else
mib_gxbfamnj: Isn’t this card an ‘atom bios’ card, ?
hifi: so whats with ShadowFB?
airlied: ShadowFB just does things in RAM and copies to VRAM
airlied: instead of having the cPU operate directly on VRAM which is slow
airlied: mib_gxbfamnj: atombios is nothgin to do with accel, it just sets up the outputs and card.
hifi: so, just “ShadowFB”, “Old 2D Acceleration (XAA)” and “2D Acceleration (EXA)”?
mib_gxbfamnj: oh, I thought it was a generic interface to the card
airlied: hifi: pretty much.
airlied: mib_gxbfamnj: only for init and setting modes and some other bits.
mib_gxbfamnj: Hmmm… Well, I know nothing about video programming. I never could get excited about that stuff. But, I would like to get the most out of my hardware. I feel like I’m always missing out on something.
hifi: airlied: I’m updating the RadeonFeature page to use those headings, any objections?
airlied: hifi: nope sounds good.
mib_gxbfamnj: Like, I finally played around with that desktop on a cube, then F9 was released, and I couldn’t do that any more (sob), and now it seems with even newer hardware, I’m still SOL
airlied: mib_gxbfamnj: the hope is some support for accel in a month or two, but its blocked on some internal AMD stuff.
mib_gxbfamnj: cool
hifi: airlied: uh, R500 has N/N which is described as “not supported by hardware” but RHD has it DONE
hifi: oh, sorry, my bad
hifi: N/N was not going to be implemented, and N/A was no harwdare support
airlied: its pointless having shadowfb on r500s since real accel exists.
airlied: its done no r600 radeon
airlied: on even
mib_gxbfamnj: And, what about the proprietary driver ?
airlied: we don’t keep track of that, it supports most things.
mib_gxbfamnj: ATI Catalyst™ 8.11 Proprietary Linux x86_64 – claims to support the Radeon HD 3600 card that I have
mib_gxbfamnj: So, would that give me most of the bells and whistles under F10 ?
mib_gxbfamnj: I thought they (AMD) were working directly with the OS community now, why do they bother with the proprietary drivers any more ?
airlied: not sure it works under F10 #ati might know.
mib_gxbfamnj: OK, so final question: ( for now 😛 ) Is it an RV635 or a Radeon 3600, or a Mobility Radeon HD 3600 ? It seems like as I look around for information, I see it referred to in so many different ways, that I can’t tell if I’m reading about the same thing or not
airlied: mib_gxbfamnj: they have customers for them.
mib_gxbfamnj: huh ?
airlied: HD3600 is the name usually seen or rv635
airlied: why they work on proprietary drivers
airlied: alsio the share the code with Windows which we can’t do for an open source driver.
mib_gxbfamnj: OK, that makes sense, I guess. Although I don’t know why the Windows driver couldn’t be OS as well
airlied: because you have to use Microsoft code in them.
airlied: also there is a lot of investment in the prop driver, hardly something you can convince anyone to abandon.
mib_gxbfamnj: you mean just calling into the Windows API would invalidate the OS status ? Hmm, I guess I need to re-read the GPL.
airlied: you have to link against DX10 stuff all over the place, not saying it can’t be done, its just not worth the investment
airlied: AMD have realised they need an open source driver to complement the closed source one, not to replace it
airlied: so thats what they are working towards.
ossman: airlied, still awake?
mib_gxbfamnj: Well, thanks for your time chaps.
mib_gxbfamnj: Time to get some work done
mib_gxbfamnj: ciao
ossman: agd5f perhaps?
airlied: ossman: ? not here for long
ossman: airlied, just a quick question
ossman: the bug in the r300 fragment program turned out to be that the macros in radeon_reg.h are a bit unsafe
airlied: which ones?
ossman: is it ok to solve this issue by fixing to macros and making it more difficult to engage in foot shooting?
airlied: yeah shouldn’t be a problem.
ossman: e.g. define R300_ALU_RGB_WMASK(x) (x << 23)
ossman: x should be (x) for safety
airlied: oh missing (x)
airlied: please fix them
ossman: ok, I’ll fix up a patch
MostAwesomeDude: Huh, so that was the bug…
MostAwesomeDude: Imagine that! Ha!
MostAwesomeDude: Oh man, that’s hilarious.
ossman: MostAwesomeDude, well, it was one of the bugs
ossman: there were more
ossman: but I’ll set up a fixed tree tonight
mogurakun: hi
mogurakun: anyone can explain why Xorg 1.5.3 is much slower than 1.4 at switching to VT & back ? is there something i can do about it ? on Radeon HD2600
ossman: was there any support for HD2600 at that time? if not, then it might be that the vesa calls are quicker
mogurakun: don’t know, but 1.4 was switching almost instantly
ossman: if you have an Xorg.0.log from 1.4, you should be able to tell if it used the radeon or vesa driver
glisse: mogurakun: i guess you updated driver along xorg update ?
mogurakun: glisse: iirc, yes, it’s 6.9.0
glisse: mogurakun: so it’s likely what ossman said
glisse: if you want faster switching provide patch
mogurakun: (unrelated) do i get it right, that kms is required for getting rid of suid on Xorg ?
glisse: not the only way but definitly the one we choose
mogurakun: ok
ossman: glisse, I’m a bit curious how you handle the security aspect of controlling the hardware from an unprivileged process
ossman: e.g. the DMA engine. how do you keep that safe without a lot of overhead?
glisse: ossman: see my modesetting-gem-WIP branch
ossman: on fdo?
glisse: you do check the cmd stream
glisse: yup fdo
ossman: doesn’t that take a lot of cycles to do?
glisse: that take cycles but there is no other way
ossman: well, putting more of the logic inside a kernel and having a more abstract interface is one way
ossman: although you have all the inherent downsides of a large kernel
glisse: ossman: that would me move mesa driver to kernel…
glisse: s/me/mean
mogurakun: lol
ossman: yes
ossman: but that’s how certain other OS:es solved the problem, right?
glisse: well you can go crossroad and comeup with somethings not as heavy as mesa
glisse: ossman: my guess is that closed source driver doesn’t check this
glisse: so that if you clever enough to figure out how to send cmd to the driver you should be able to dma anywhere on pci or pcie card
ossman: the old security by obscurity system that has worked oh so well 🙂
ossman: which repo is that branch in? you have a bunch
ossman: drm?
glisse: drm
glisse: http://cgit.freedesktop.org/~glisse/drm/log/?h=modesetting-gem-WIP
ossman: is WIP just “work in progress” or is it another X acronym I’ve managed to miss? 🙂
glisse: work in progress
MostAwesomeDude: So the reason that somebody couldn’t DMA the framebuffer even if they have access to the ioctl, is because GEM marks the framebuffer memory as belonging to the X process, right?
MostAwesomeDude: I just assumed it worked that way?
glisse: MostAwesomeDude: no
glisse: MostAwesomeDude: in today gem implementation you can dma to anythings which is mapped by the card
glisse: so you can dma to think which doesn’t belongs to you
MostAwesomeDude: So, if somebody’s got a password on the screen, and I wanted that password, I could just DMA the frontbuffer to a dump file?
glisse: being clever you can dma to gart table on pcie system
glisse: and the dma to anywhere in ram
MostAwesomeDude: So GEM only tracks whether or not memory *is* allocated, not *who* allocates it?
glisse: if password is clear test yes
glisse: text
glisse: it’s not gem faults
glisse: it’s command stream checking fault
MostAwesomeDude: Ah. So it’s up to the command checker, which is already there, to make sure that invalid DMA packets aren’t sent to the card?
glisse: well i wouldn’t say that we have a cmd checker today 🙂
MostAwesomeDude: :3
glisse: today we have cmd rewriter which rewrite bo offset
glisse: what’s in my WIP branch is a cmd checker
MostAwesomeDude: So how would we check commands? Do we know who owns which buffer? Do we make it so a certain permission is needed to blit to front?
glisse: we just check that any operation which acces memory use a bo, gem check for us that the app calling the ioctl got the right to use the bo
MostAwesomeDude: Ah.
glisse: and we check that app doesn’t do memory operation beyond bo size
MostAwesomeDude: So that protects against errant DMA. Could I still dump the screen using the MMIO?
ossman: will there be checks to handle attempts to wedge the card and/or machine?
glisse: MostAwesomeDude: we will block mmio from userspace in kms
glisse: ie userspace won’t be able to play with register anymore
glisse: ossman: i don’t think we will check this
glisse: too complex to check
glisse: instead we will fix userspace we control to do good things
MostAwesomeDude: Mm. That should be sufficient to keep me from getting my buddy’s password. :3
glisse: of course some one can create a program to crash your computer
ossman: glisse, ATI’s windows driver has some reset sequence when it detects that the card isn’t responding properly. any possibility of something like that as an “after the fact” kind of solution?
glisse: ossman: i have done heavy testing of such code with no success
glisse: though there is path i need to test again
ossman: k
MostAwesomeDude: ossman: It’s possible to soft reset and hard reset the GPU, but first we need to detect the hang, and then we have to have some kind of way to reset the userspace components.
MostAwesomeDude: Also the docs don’t quite match the HW. :3
glisse: MostAwesomeDude: in kms no need to reset userspace beside texture which we might loose 🙂
MostAwesomeDude: glisse: Can’t we just evict all BOs from the card and then reset the card, reset the mode, send BOs again?
MostAwesomeDude: Shouldn’t have to tear down GEM state, just resend all of it back to VRAM again.
glisse: MostAwesomeDude: when card is busted we might not be able to reach all card vram
arekm: if I would be crazy enough to try kms for r300 which repos do I need? 🙂
MostAwesomeDude: glisse: We wouldn’t have to write out to VRAM until we reset the card…
glisse: MostAwesomeDude: think 512M vram on 128M pci bar
MostAwesomeDude: Ooh. Hm.
MostAwesomeDude: Well, don’t we normally use DMA to get stuff past the aperture mark?
glisse: yup but busted card mean no dma 🙂
MostAwesomeDude: So lock card, reset it, and once it’s ready again, reset CP and then DMA everything back out.
MostAwesomeDude: And then unlock it and start sending BOs again?
glisse: MostAwesomeDude: during card reset we might stop vram
glisse: so we might loose all vram content
MostAwesomeDude: That’s not a bad price to pay, though.
MostAwesomeDude: I mean, before, wouldn’t we have had to take down X in order to do this?
glisse: but i don’t think we will loose vram
glisse: no when card is hang it’s too late
MostAwesomeDude: We might have to tell X to Damage the whole screen, or however that works…
glisse: if we could predict that next cmd will hang the card we wouldn’t be hanging 🙂
glisse: for X it’s okay but for opengl it’s not
glisse: there is no such things as please reupload texture
MostAwesomeDude: Well, I mean, isn’t this a worst-case scenario no matter what?
MostAwesomeDude: Graphics corruptions > hard-locked system.
glisse: yup i don’t care loosing texture and starting back the gpu
glisse: anyway we still have to find out how to consistently reset card
glisse: for that i think we need to assert all reset bits long enough and also disable mc to avoid any pci memory access fault
MostAwesomeDude: The docs have a pretty detailed reg read/write order to do it; does that not work?
glisse: well i tested several code from amd and none worked reliably
glisse: but i think i was just not doing everythings long enough
MostAwesomeDude: Hm.
glisse: reset might need few ms
MostAwesomeDude: Could be. No harm in it, I suppose.
glisse: and then we likely need to repost card and resetup everythings
MostAwesomeDude: 60fps gives us 14fps to drop one frame. :3
MostAwesomeDude: *14ms, even.
glisse: we don’t want to reset card every second 🙂
ossman: I don’t think we want to reset the card ever. but then there’s the harsh reality 😉
ossman: it would be a bit neat though if it was robust enough to handle a hang every second and still be useful
ejs1920: I’m seeing some rendering problems with latest xf86-video-ati git
ejs1920: according to git bisect the first bad commit was fc079c5267baf431bbecee7744e484783d393152
ejs1920: there were some horizontal lines under the text in window title bars, and one or two letters in gnome-terminal become messed up
ossman: that sounds familiar. wasn’t a bug like that solved a few months ago?
ejs1920: this is very recent, that commit was yesterday
ossman: might be the same bug that has reappeared though
ossman: I believe airlied solved the previous one.
ossman: http://airlied.livejournal.com/62489.html
ejs1920: I’m on Fedora 10 but kernel modesetting is disabled
ejs1920: radeon 9550 (RV350)
ejs1920: and, also, my system locked up on replacing radeon_drv.so with a different version
arekm: replacing like cp new.so radeon_drv.so?
ejs1920: yes!
arekm: don’t do that. do rm radeon_drv.so && cp new.so radeon_drv.so
arekm: (which requires X restart anyway)
ejs1920: now that I think about it, I think I’ve always used rm first before
ejs1920: I added it to bugs.freedesktop.org so it won’t get missed, bug #18864
scsiraider: airlied: any new branches to play with yet?
bobbens: next freaking video card i’m getting it fanless
bobbens: sick of fans dying on me
hifi: I’m sick of fanless video cards dying on me
agd5f: airlied, glisse: http://www.botchco.com/alex/xorg/use_ib_per_op.diff
agd5f: use an IB per op. I haven’t noticed any increase in CPU usage, granted it’s not using the new ioctls, but other than additional ioctl calls, I don’t see it adding any more overhead
glisse: agd5f: with new cs it will add overhead as we will recheck some common state btw op while if in same ib we would check them once
spstarr_work: looks if airlied made some AGP magic last night
agd5f: glisse: what about implementing contexts in sw? then you can assume the context is safe and avoid re-checking it
glisse: agd5f: we could do that
spstarr_work: http://airlied.livejournal.com/63368.html
spstarr_work: airlied: not yet 😉
spstarr_work: -134, -135
glisse: agd5f: this context things needs discussion 🙂
agd5f: glisse: yeah. all we basically need is regsiter structs and some ioctls (alloc/free/switch)
glisse: i don’t think we want register struct
glisse: i would rather got with a packetstream
agd5f: an ib?
glisse: s/got/go
agd5f: opk, yeah, that as my other thought
glisse: yup ib
glisse: sounds easier to extend and modify, we don’t fixes operations order …
agd5f: yeah, a state IB that the drm stores
agd5f: and reloads on context switch
glisse: cs will endup having only drawpacket 🙂
agd5f: 🙂
glisse: of course this depends on where we set the boundary btw what is context or not, or do we allow things to be in both place
glisse: agd5f: well very least for r3xx/r5xx we want what i put in the checker to be context only
glisse: module vaos
glisse: modulo vaos
ossman: agd5f, do you have a preferred format for commit messages?
bridgman: glisse/agd5f; for “what goes in context”, would that roughly match what Gallium accumulates in the state tracker ? I haven’t acdtually looked at Gallium code but I always assumed that it cached a set of state and flipped it into the GPU when needed rather than constantly poking registers with every GL call…
bridgman: only question about maintaining state in an IB is whether you want to update everything or simply diff the desired state with the last state you flipped in and build an IB for the differences…
spstarr_work: bridgman: I was @ the food court today 🙂
bridgman: spstarr; bad timing; I’m working from home today, 60km from food court 😉
bridgman: that’s why I can be on IRC…
spstarr_work: heh
spstarr_work: I wish I was working home
bridgman: I’m not so sure… I tend to do fun things at work and boring things from home
bridgman: maybe your work is different…
spstarr_work: i can work from home sometimes, but i usually do if its a snowday
bridgman: that’s what I did until I bought a snowblower, now I have no excuse 😉
spstarr_work: i live in a condo now, but i have no winter tires on yet ;p
agd5f: ossman: no preference
ossman: agd5f, ok
agd5f: bridgman: yeah I think so
ossman: agd5f, got time to look at some patches?
agd5f: ossman: sure
ossman: hang on and I’ll try to get something up then
glisse: bridgman: i think context is more about unsafe state
bridgman: unsafe ?
glisse: bridgman: anythings that change scissor, framebuffer, …
ossman: agd5f, http://git.infradead.org/users/drzeus/xf86-video-ati?a=shortlog;h=refs/heads/bicubic
glisse: bridgman: we have to check that client don’t take advantage of ths hw 🙂
ossman: agd5f, if it’s okay with MostAwesomeDude, then it should be ready for trunk
agd5f: ossman: cool
glisse: bridgman: i don’t think caching things like fog color, color, zclear … makes sense
bridgman: so if you have multiple apps interleaving commands, eg 2d accel and 3d, how do you manage that today ? Driver sends the whole state down every time ?
glisse: bridgman: today we have a big lock 🙂
glisse: ie you loose the big lock you have to resend the whole state
glisse: s/ie/if
bridgman: ooh, I bet that makes it go fast 😉
glisse: well starting from r3xx state is not the things that slow us the most
bridgman: so nobody would run, say, 2d accel and an opengl-based compositor at the same time
glisse: of course we don’t want to be stupid about it 🙂
bridgman: agreed, but it will be soon
bridgman: once other things get speeded up
agd5f: ossman: looks good.
glisse: well for instance X takes the lock and do stuff
bridgman: spstarr; I can’t use the winter tire excuse either : http://rides.webshots.com/photo/1168154469048161985hADDtH
ossman: agd5f, my patches are good to go, but I don’t know if MostAwesomeDude has any objections to merging his stuff
glisse: after a while if X want to send new cmd it checks that it stills own the lock
glisse: and if not reemit state
ossman: agd5f, and I don’t know who Maciej Cencora is
ossman: since I found the stuff in MostAwesomeDude’s repo, he should know though 🙂
agd5f: he did the initial port to r3xx
bridgman: glisse; definitely makes sense, just (a) wondering if that model still works now that we are more likely to have multiple apps interleaving commands and (b) guessing that Gallium does something similar anyways
glisse: bridgman: we want to get rid of the big lock 🙂
bridgman: agreed; so aren’t you going to want to do something like tracking big piles of state instead ? Seems like you only have two options : each app/driver tracks state in which case you send everything, or drm tracks state in which case you send diffs…
bridgman: again, if gallium isn’t doing something like this now (ie if gallium just does the lock thing today) then it’s probably premature worrying about this stuff
glisse: well i suggested context a while back but people didn’t found the idea appealing
bridgman: I thought you suggested hw context which was why I was against it 😉
glisse: i think what we want is to try to minimize the number of pipe flush
bridgman: hw context *switching*
bridgman: yep, that’s definitely higher priority
glisse: bridgman: oh now 1 or 2 year ago while doing kernel modesetting i asked what about doing context 🙂
glisse: s/now/no
airlied: context handling in the kernel gets ugly quick.
airlied: we shouldn’t do it unless we have some benchmarks showing how slow we are going.
glisse: airlied: i think it can be pretty simple
airlied: granted re-emitting all state is also probably going to be slow
glisse: like storing current context id
airlied: how we deal like meta states, like clear state is my worry.
glisse: and when queueing into ring just check if we need to append context or not
airlied: we emit a lot of state to do a clear op, then emit a lot of state to do the next op
airlied: its just how often the context gets updated.
agd5f: so have the driver define several sets and then switch between them.. it would avoid re-validating each time
airlied: do we send diffs to it or does the stream checked update it
airlied: so if CS sees a change to the state inline, it updates the stored state as well as the gpu?
glisse: i think context are usefull if we get a big scene to render and we have split ib because it reference too much texture of vertices
glisse: s/of/or
glisse: i don’t think small granylarities makes sense
glisse: anytime you change zbuffer/color you need a whole flush
bridgman: sorry to kick all this off guys; I just assumed that was how Gallium worked today ;(
glisse: anytime you change frag/vertex prog you also need to flush
glisse: bridgman: no worry, i said earlier that context needs discussion 🙂
airlied: glisse: yeah so pixmap rendering does a lot of flushing
airlied: but we have a lot of common state
airlied: so we change CB a lot but we don’t need to reemit all the invariant state
glisse: airlied: i am not convinced that context is the solution
airlied: neither am I, but I’m not sure what is, I think trying to fit as much as possible nito an IB is,
glisse: in the meantime if we do an ib per op overhead will grow with the full cmd checker
airlied: at least for the 3D driver.
airlied: for the 2D case I also think we need to get as much stuff in as possible
airlied: so I’m not totally happy with IB per op either, esp if we don’t have the lock + full command checker
ossman: airlied, you mentioned using cliprects on r200 as a replacement for scissoring. is there any existing use of it in the driver?
ossman: I looked at RADEONSetClippingRectangle, but it seems to be for the 2d engine
airlied: probably in the mesa driver
ossman: do you recall some define I can grep for?
airlied: actually r200 might have some scissors
airlied: there are some regs in r200_reg.h
airlied: agd5f: thats a wierd regression due to flushing more often,
airlied: goddamm rv50s.
airlied: rv350s even.
ossman: I’ll make an attempt. anyone with an r200 that can test it later?
glisse: airlied: i think you don’t flush exactly the same in CPFlush iirc
glisse: also we should really write to some sc reg or top reg before flush 🙂
airlied: ossman: you trying the big triangle thing?
airlied: glisse: true.
airlied: also not using CS might have an effect.
ossman: airlied, yup. a final cleanup before I submit a patch
ossman: it works fine on r300
spstarr_work: airlied: any stuff for me to test tonight?
airlied: spstarr_work: I have better AGP fxies but I haven’t pushed them et.
agd5f: airlied: I know. sucks
ossman: does r200 have any public docs?
airlied: ossman: nope other than the header files.
agd5f: ossman: not yet
ossman: too bad
spstarr_work: airlied: ok
spstarr_work: airlied: i can see you’re getting pretty pissed at the rv350 😉
ossman: do I need to add some code that restores 3d regs? or is that just for display setup stuff?
glisse: i am using low end rv350 to test stabilities….
spstarr_work: glisse: how much vram?
ossman: airlied, agd5f, do you guys have access to internal docs for the r200?
airlied: ossman: I have them, and I have an r200 to play with
glisse: spstarr_work: got several rv350
agd5f: ossman: yup
spstarr_work: glisse: with kms on?
spstarr_work: 🙂
glisse: spstarr_work: yup
spstarr_work: glisse: no instabilities?
spstarr_work: no corruption with AGP on?
ossman: airlied, I figured I’d take the same approach as for r300, where scissoring is always enabled, and users just tweak the rect
spstarr_work: glisse: http://www.sh0n.net/spstarr/agp-kms-corruption.ogg
spstarr_work: glisse: http://www.sh0n.net/spstarr/agp-corrupt2.ogg
glisse: spstarr_work: none that i can remember of but it’s a test machine so i don’t really use it, i mostly launch a bunch of apps to perform stabilities checking
spstarr_work: you dont even get instant corruption on load?
glisse: no
spstarr_work: or is this due to some patches in airlied’s bits?
glisse: don’t think so
glisse: my ddx is a bit different though
glisse: especialy as it reemit full state more often
spstarr_work: is yours ready to merge with airlieds stuff?
spstarr_work: or not yet
glisse: well it should rebase on airlied ddx with no problem
glisse: i rebased it few weeks ago and haven’t done modification since then
spstarr_work: but right now, you both can’t work from a same tree
spstarr_work: until the plumbing is done?
glisse: well my ddx is based on his only diff is that my ddx has dri2 bits and reemit full state everytime
glisse: also mine have more ifdef logics for not enabling kms is userbits are not their
spstarr_work: I don’t suppose we should just start moving to use DRI2 now in Fedora 11? I can switch to rawhide again 🙂
spstarr_work: and just leave F10 ddx alone more or less until backported
airlied: well F11 doesn’t have a DRI2 server in it yet
spstarr_work: oh
ossman: airlied, agd5f, can you check reg 0x1cd8 R200_RE_SCISSOR_TL_0 for coding?
ossman: I can’t find any code using it
airlied: top left scissor 0->10 X left, 16->26 Y TOP
ossman: thanks
agd5f: X 10:0, Y 26:16
agd5f: goes along with RE_SCISSOR_BR_0
agd5f: 0x26DC
ossman: same coding I assume?
agd5f: yup
agd5f: ossman: there are acutally 3 sets of scissors
ossman: yeah, the plan was to enable just the first one
agd5f: RE_AUX_SCISSOR_CNTL 0x26F0 controls them
glisse: spstarr_work: corruption only happens with kms ?
spstarr_work: glisse: yep
spstarr_work: I use AGP 4x with non-kms
glisse: and with agp disabled does kms works ?
agd5f: for scissor 0, bit 24 is inclusive/exclusive and bit 28 is scissor 0 enable
spstarr_work: glisse: it works with agp disabled as of airlied’s last changes
spstarr_work: exa had no corruption
spstarr_work: but enabling agp you see in those ogg videos
airlied: spstarr_work: my latest changes may help that, not sure.
spstarr_work: when you commit i’ll test & report
ossman: http://git.infradead.org/users/drzeus/xf86-video-ati?a=shortlog;h=refs/heads/vsync
ossman: airlied, agd5f, could one of you test that on r200 and see if the scissoring works?
airlied: ossman: I’ll try and get some time today, if I can.
ossman: great
agd5f: ossman: few minor nits: missing else in scissor setup, and we generally uses shifts for bit defines, e.g., (1 << 24). I’ll pop an r200 in later today and test it
ossman: agd5f, I just copied it from the mesa code, but I can tweak that
agd5f: ossman: also, did you make sure that the scissor is enabled?
ossman: agd5f, I think so. there were two regs that I tweaked in init3d
agd5f: could probably use the same triangle trick for exa composite, save a vertex
ossman: agd5f, oh, yeah… I didn’t fix the legacy crtc code
ossman: there was no INV define for that
ossman: do you have specs that can fill that gap?
agd5f: yup
ossman: please enlighten 🙂
agd5f: ossman: bit 15
ossman: thanks
ossman: ehm… it was already there… I wonder why I had trouble finding it earlier…
ossman: airlied, agd5f, I’ve updated the tree now with those fixes
ossman: I’ll fix up the bicubic code path tomorrow, then it should be done
agd5f: ossman: looks good
airlied: agd5f: oops we don’t apply atom quirks on the OBject table 🙁
agd5f: airlied: whoops
ossman: why are coords converted from ints to fixed point to float in the textured video code?
ossman: as opposed to directly from ints to float
agd5f: ossman: copy pasted from exa code
agd5f: could be removed
ossman: great. it would make my life simpler 🙂
ossman: agd5f, I’ve fixed the bicubic stuff now as well, so review and merge at will 🙂
agd5f: ossman: same trees?
ossman: yup
ossman: note that it contains your vsync patch
ossman: which also has some exa stuff
ossman: its up to you if that part is ready for trunk 🙂
agd5f: ossman: does it work for you? the vline stuff
ossman: yes, very nicely
agd5f: well cool
ossman: I haven’t tested the exa stuff really though
ossman: because my devel machine is my HTPC 🙂
ossman: so it’s just running mplayer basically
ossman: and the tearing comes back when the card is unable to keep up though. but that’s expected
ossman: it’s an on-board card, and I guess it doesn’t have the power to handle full hdtv properly
spstarr_work: goes home
agd5f: airlied: I fixed that corruption bug. seems we need to make sure the 3d state is updated if we are using a new IB
b00: hello !
mattmatteh: hi
mattmatteh: dont think i can help
mattmatteh: but ask here and wait
b00: I have this error in my xorg.log :
b00: (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/dri/r300_dri.so: undefined symbol: __driCreateNewScreen_20050727)
b00: anyone knows here what that CreateNewScreen symbol is responsible for ?
b00: is it not perhaps implemented in this version of the lib ?
b00: does it mean tha tI don’t have direct rendering with the driver ?
b00: glxinfo seems to stay I do, and , glxgears is bout x4 times faster now ..
airlied: b00: you need a newer X server most likely, if you tried to use a newer mesa.
b00: airlied, i have latest (for my distro) mesa
b00: i’ve rebuild both (x, mesa) yesterday
b00: I have nptl enabled for both
airlied: well that error means they are mismatch.
b00: airlied, they do ? ok
b00: airlied, my xorg probably is old(er)
airlied: for mesa 7.2 you need server 1.5
b00: yes,i have mesa 7.2
b00: airlied, ah, yes, my xorg is old
agd5f: ossman: r200 texvid works, but it screws up something such that rendering is busted after running a video
agd5f: probably need to reset the scissors
b00: btw,
b00: any issues with using the radeon driver and suspend ? (TuxOnIce)
b00: i got an impression my console got screwed, on last hibernate ..
b00: see only some messed up screen, and ont the usual traces
b00: (X session restores fine, still )
agd5f: YMMV, depends on the computer
agd5f: resetting the scissors fixes it
agd5f: ossman: also scaling to full screen doesn’t work
agd5f: probably hitting some limit
agd5f: we should be able to use rect lists on all chips rather than quad lists
agd5f: those might render as actual rect rather than as triangles
agd5f: ossman: also, the bicubic code needs to reset the shaders properly, as they get hosed after running video
damentz: hi agd5f, i replied to bug 13833 – the screen blooming still happens when mode changing
damentz: agd5f: after holding down the lid button for 2 seconds then releasing, the screen is properly displayed
benh: hrm weird
benh: so AIGLX loads and works fine
benh: compiz wobbles fine
benh: but GL apps I run in gnome get DRI with the Mesa SW rasterizer
benh: I wonder what I did wrong

Radeon IRC Logs For 2008-12-03

Rig Lab Hardware

You Might Also Like

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

RadeonHD.org | Radeon IRC Logs For 2008-4-07

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