jcarlos: airlied: Does this post http://airlied.livejournal.com/63057.html something to do with my comments about kstars and EXA AccelMethod ?
glisse: airlied: i think the best is to use somethings like set/get domains
glisse: airlied: or somehow pass a domain along with the map
glisse: also for memory limit i think cs should report after each submission how much app can use
glisse: so when things get tight userspace might flush more often
glisse: don't know if the best solution is to flush often or to do big move and do many cmd
glisse: at least reporting next size would allow us to decide latter what is best way
airlied: glisse: it doesn't help avoid all the other issues though..
airlied: like fragmentation etc...
airlied: glisse: also passing a domain with map doesn't help, as really exaGetImage is a subcopy operation
airlied: ideally you could possibly copy into GTT from VRAM, and keep VRAM, and wait until the next op to decide which copy to keep.
airlied: jcarlos: nope... this is all to do with new kms drivers
jcarlos: airlied: Where can I read about those drivers ? And don't tell me "in the code" ... I'm a completely graphics newbie ... :-)
airlied: on my blog, shipping in F10 etc, but nothing too in-depth apart from me giving out
jcarlos: airlied: And the problem I reported yesterday in the radeon driver with EXA AccelMethod is not a problem in this new drivers ?
airlied: I've no idea, I haven't tested it, I have enough bugs to look at first :)
jcarlos: airlied: Last question: Will the kms drivers replace the current drivers ?
jcarlos: is reading about kms at phoronix site ...
MostAwesomeDude: jcarlos: KMS is a restructuring, but the current drivers will stay.
MostAwesomeDude: Basically, the radeon driver will do either KMS or classic modesetting.
MostAwesomeDude: Depends on what the kernel supports.
jcarlos: MostAwesomeDude: Yes, I reading about that, thanks ...
jcarlos: MostAwesomeDude: I have a radeon 9600 ... does it be supported ?
MostAwesomeDude: For modesetting, r100 through r600 are currently working IIRC. So yes.
jcarlos: MostAwesomeDude: What I need to test that drivers ? What kernel and driver version ?
MostAwesomeDude: Um, I'm not sure, actually. I know that both kernel and driver are in git repos somewhere.
airlied: its in F10, otherwise its a bit messy and the upstream repo diverged the API, and I haven't fixed it up yet.
adamk: airlied, Could this be the source of some of the modesetting + Xorg issues I'm having with my AGP card? "[drm] Forcing AGP to PCI mode"
airlied: adamk: AGP is a bit messy, does using radeon.agpmode=4 or 2 help?
airlied: I'm seeing some r500 on AGP issues reported.
adamk: airlied, If I don't set the agpmode, this is what I get:
airlied: with an agpmode it works better?
adamk: If I set it to 2, dmesg says that's not a valid option.
airlied: 4 or 8 might be the only valid ones.
airlied: for that AGP mode.
adamk: But, in that case, I get: http://184.108.40.206/radeonagpmode2.jpeg
adamk: I'll try 4 now.
airlied: the kernel will print unknown option
airlied: until the radeon driver loads
airlied: I think not using PCI mode on r500 is a good plan, need to figure out the AGP works on r500s....
adamk: Well, it did say that 4 and 8 were the only valid values, and it's coming from the driver.
adamk: Booting with 4 now.
adamk: radeon.agpmode=4 gives the same results as radeon.agpmode=2
adamk: Just without the warning about selecting an invalid mode.
airlied: what X server you on?
adamk: And, yeah, this is an x1900, so I can definitely confirm those issues that you had reported.
airlied: some of the EXA fixes in master are needed.
airlied: but I suspect I need to do more
adamk: 1.5.3. Specifically xorg-x11-server-Xorg-1.5.3-5.fc10
airlied: ah cool.. so it has the EXA fixes.
airlied: I'll have to disable PCI mode on r500 for AGP cards, but I'll have to work out wtf is going wrong with the rendering.
airlied: I think spstarr is seeing similiar on agp r300
airlied: spstarr_work: ^^
airlied: gotta zzz &
adamk: I do have a 9800 in another machine, and it works fine, so it doesn't seem to be all r300 and higher AGP cards.
MrCooper: adamk: AGP V3 only supports 4x and 8x
glisse: airlied: i was not implying that mmap stuff would help with fragmentation
glisse: just that it sounds better to let userspace choose what to do depending on bo domain
spstarr_work: - attempt to resolve DFS with a worse idea.
adamk_: If I need to use Mesa 7.2, with a KMS enabled DRM, is it normal that I have to disable KMS to get DRI to work properly?
telexicon: Are the specs for r100 available somewhere? or the 2d reg specs for r300?
ossman: agd5f, present and available for some stupid questions? :)
ossman: I'm trying to look at the vsync-issue
ossman: I guess others could answer the first one though...
ossman: how does register writes relate to stuff put on the ring?
ossman: the reason I'm asking is that the vsync waiting is done through OUTREG, but the triangles for the video is done through OUT_RING
ossman: nm, it seems it is done through OUT_RING_REG
ossman: the macro voodoo can be a bit hard to follow at times :)
ossman: agd5f, I cannot find the WAIT_UNTIL register in any of the docs. which one should it be in?
agd5f: ossman: hey
agd5f: it's all done through the ring
ossman: I updated the bugzilla entry
agd5f: the wait_until register basically stalls the command processor until certain contions are met
ossman: basically my chip does not seem to respect waiting for a falling edge, just a rising one
ossman: and I have no real idea on where to go from here :/
agd5f: could be. maybe only falling edge works
ossman: agd5f, the other way around :)
agd5f: right :)
ossman: but isn't rising edge the one at the end of the blanking?
ossman: why would anyone want to wait for that?
agd5f: ossman: it's not the blanking, it a particlar vertical line
ossman: what's the difference?
ossman: is probably missing some vital parts of the lingo
agd5f: ossman: you could pick any line. one in teh middle of the scan out
agd5f: like if your display is 1024x768, you have 768 active lines
ossman: but I see no possibility of picking a line?
ossman: and calling it "vertical" is very confusing. that's not how it scans :)
agd5f: ossman: VIVO_D1MODE_VLINE_START_END
agd5f: RADEON_CRTC_GUI_TRIG_VLINE on the older chips
ossman: this is a R500, so let's start with that :)
agd5f: D1MODE_VLINE_START_END in that case
ossman: judging from the code, this is set up through atombios somewhere during init?
agd5f: when the mode is set
ossman: the code wasn't completely obvious. what is it supposed to set as the trigger line?
agd5f: I don't remember, let me check the code
agd5f: actually I think it's a range
ossman: and I can't seen to find that reg in the docs either. just for your eyes? :)
agd5f: ok. it is a range. start is the start of the vline status, end is the end of the vline status and bit 31 will invert the inside outside logic
agd5f: ossman: I thought it was in some doc... maybe the r6xx ones? anyways all the bits are in the register header in my patch
ossman: ok. so this is purely an internal signal and not directly related to sync signals associated with each line?
ossman: and what is the non-inverted states? high when inside the range, or outside?
agd5f: yeah on when inside off when outside IIRC
ossman: that would mean we're doing things completely backwards right now :)
ossman: it would trigger on line 0, and start rendering just as the CRTC starts outputing the image
ossman: tries inverting it
ossman: hm.. no effect
agd5f: oops looks like we need to set bit 3 in the wait_until register as well
agd5f: er...hmmm. that just waitf for it to be on, not sure if that is independant of RE/FE bits
ossman: setting just RE "works"
ossman: i.e. it waits for some refresh related event
ossman: setting just FE or just bit 3 does nothing
agd5f: yeah, probably independant then
ossman: but I'll test some combination
ossman: the inversion bit had no effect oddly enough though
agd5f: yeah, that was about as far as I got. problem is, I have a hard time noticing tearing, so I'm not the best person to test this stuff :/
ossman: I'll happily hack away, just as long as I have someone feeding me some hw info :)
ossman: anyway, some test results:
ossman: non-inverted: wait for FE gets completely ignored
ossman: invert: FE gets respect iff bit 3 is set
ossman: but waiting for FE or RE gives the same tear in the last case
agd5f: it might be stalling on the RE/FE and on. what does "on" (bit 3) do by itself?
ossman: hang on
ossman: waits in the same spot
ossman: so RE and bit 3 seem to have the same effect, and FE still gets ignored :)
ossman: try playing that movie in fullscreen
ossman: it's great for tear debugging :)
ossman: (it's 8 seconds of alternating white and black frames at 25 fps)
agd5f: ossman: the other option is to change the start/end vlines and play with that if the invert stuff doesn't work or put the wait_until at the bottom of the pipe rather than the top
ossman: yeah, fiddling with the range was my next plan of attack
ossman: but I don't see how we can move the wait?
yangman: ossman: seizureiffic ;)
agd5f: well, I was thining right before the draw commands, but that gets trickier
agd5f: and you'll be stalling too much
ossman: yangman, a bit yeah. perhaps I should have added a disclaimer for epileptics...
ossman: I thought it was just before the triangle output right now?
ossman: perhaps you're talking about the EXA cases? :)
agd5f: yeah exa, sorry
ossman: has a very narrow interest in getting tear free video right now
ossman: agd5f, dare to guess when the r600 code will be released? :)
agd5f: ossman: soon I hope :)
ossman: soon as in "before christmas" or "hopefully during 2009"? :)
telexicon: are they going to release docs for r100/r200?
ossman: agd5f, hmm... I'm not getting any sensible behaviour out of that wait function. do you have any documented semantics that you are able to share?
agd5f: telexicon: maybe after r6xx. the problem with the old docs is we haven't been able to find editable copies so we can remove all the confidential warnings and such
agd5f: ossman: if I had them I would
ossman: I've changed the ranges back and forth, but I get no effect whatsoever
ossman: I don't suppose you can double check that you got the register offset right? :)
agd5f: ossman: yeah it's right
ossman: that would have been hoping for too much I suppose...
ossman: agd5f, is the legacy_crtc code completely wrong for an r500? I'd like to try and bypass atombios, in case there is some problem there
airlied: ossman: no you can't do that.
agd5f: ossman: yeah different display engine
ossman: agd5f, no mention of any restrictions on the size of the vline range?
agd5f: ossman: 14 bits 13:0, 29:16
ossman: but nothing like "Must be at least 10 lines" or something like that?
agd5f: nothing in the reg specs
agd5f: I haven't been able to find any documents on the vline stuff
ossman: are the internal registers of the chip globally reset at some point? i.e. if I remove the vline code and restart X, will it have some kind of default value?
agd5f: ossman: yeah, the driver saves and restores them if you switch vts or quit x
agd5f: at least in my patch
ossman: ok, so barring a crash the driver should have kept track of the original value?
agd5f: ossman: actually it looks like I only save the regs on the older chips
ossman: agd5f, can you share the descriptions in the register docs for those wait bits?
agd5f: ossman: yeah
ossman: hm... ok.. I guess this is some kind of progress. I managed to wedge the card
ossman: I take it there is no code to detect a wait that will never complete and somehow abort it? :)
agd5f: well, you could attempt to soft-reset the CP
MostAwesomeDude: Ideally, if you end up waiting several seconds, it'd be best to lock the card, soft reset it, unlock it. Unfortunately, you'd need to bring down X first.
ossman: my video knowledge is a bit rusty, but isn't there a couple of padding lines in addition to the lines that make up the actual image?
agd5f: yeah, the blanking area
ossman: how do those relate to the VLINE range?
agd5f: don't know :)
ossman: delightful :)
ossman: anyway, I'm consistently hanging my card with some ranges, so it seems to be paying some attention to what I put in there
agd5f: you could try padding the blanking sizes
agd5f: * with
ossman: since I seen to be hitting the case where VLINE never triggers, I thought I could see if I can expand it just enough to have a short burst
MostAwesomeDude: I still think page flipping is probably the best choice for this.
glisse: MostAwesomeDude: it's not possible
glisse: have to keep both buffer in sync
glisse: X is drawing stuff but also using the framebuffer as a reference content
glisse: what would be needed is a way to change X to ask to redraw for all changed area
MostAwesomeDude: And right now, we can't do that because Damage only marks one spot at a time?
airlied: really we should just make everyone use GL movie players :)
glisse: airlied: will work only for fullscreen case :)
airlied: glisse: who wants to watch movies in a window :)
glisse: youtube leecher :)
agd5f: why not just teach exa to be double buffered?
agd5f: use a blit to sync things up for sw access
agd5f: for hw we could use MRTs on newer hardware to update both buffers at the same time
ossman: airlied, gl doesn't vsync in current fedora, so no improvement there ;)
glisse: agd5f: i think it would be faster to be composited full time :)
agd5f: glisse: agreed :)
glisse: agd5f: maybe we should just forget about uncomposited case
agd5f: so dri2 really is the solution :)
glisse: dri2 can also cooks your meal
agd5f: glisse: yeah, we should forget about non-composite for a lot of things :)
agd5f: with 3D only, non-composite gets hard
glisse: yes we should bear that in mind
ossman: "do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly." <- known issue?
ossman: agd5f, I'm not able to make much sense out of this VLINE stuff. Any chance you can get more info from inside sources?
agd5f: ossman: I'll ask around
benh: agd5f / airlied: output probing is busted on my powerbook with intrepid
benh: it claims things are connected everywhere, they aren't
benh: and it sets a crap mode by default which isn't my panel native mode (panel is 1440x960 and it sets 1152x864 for no reason I can see)
benh: it's not even in the MetaModes list I give it
airlied: benh: MetaModes? do we still use that?
benh: airlied: no
airlied: benh: file a bug with a log, the wrong mode is most likely the server picking modes
benh: it is
benh: well,before I file a bug, I'm thinking about digging
airlied: and it picks the common mode for the output thatisn't connected.
benh: a bit
spstarr: looks at his disassembled room
airlied: so fix the output detection and it'll probably work fine.
benh: right though 1152x864 is a weird common mode for a CRT
benh: I need to dbl check, could be that it works on first server launch
benh: but is fucked on second
airlied: the log should say, Option "modedebug" "true" might help
airlied: but I supspect the load detect is the problem more than the modes
benh: I'll have a look later
benh: I suspect that too, though it used to work
benh: airlied: works at boot
benh: airlied: interesting ... will be fun to debug :-)
airlied: what GPU?
benh: (the shinnybook)