dmb_: agd5f, yup, tried the patch
dmb_: agd5f, not sure if that invalid frequency with setting the register meant anything
agd5f: dmb_: restart X so that you haven't touched any regs, then try: avivotool regset 0x7ed8 0x10100041
dmb-eeepc: agd5f: nothing
agd5f: dmb-eeepc: ok. can you try the suggestion I just posted on the bug?
dmb-eeepc: ok trying
dmb-eeepc: agd5f: should i reset xorg after each set?
agd5f: dmb-eeepc: nope. just try them one after another in the same X session
agd5f: they are actually related, so you need to try all of them
dmb-eeepc: ok, i think avivotool regset 0x7ec4 0x00824002
dmb-eeepc: fixes it
dmb-eeepc: let me try from scratch to make sure
dmb-eeepc: agd5f: yup, thats it
agd5f: dmb-eeepc: ok, good. progress at least.
dmb-eeepc: agd5f: whats that register do, its not in radeon_reg.h
agd5f: 7ec0- 7ecc are macro controls for the digital transmitter
agd5f: I'm not entirely sure. I'll have to ask the hw guys
dmb-eeepc: ok, i'll post that on the bug report then
agd5f: dmb-eeepc: thanks
zcrayfish: Off hand, does anyone know what the first number in ConnectorTable does?
dmb-eeepc: yeah, according to rs780 doc, it "Sets driving strength for lane 2" :)
agd5f: dmb-eeepc: the field in question is actually "reserved bits connected to PHY"
agd5f: which is pretty vague
agd5f: zcrayfish: ddc line, dac type, tmds type, connector type
zcrayfish: agd5f: thanks.
agd5f: zcrayfish: that option is only relevant on r1xx-r4xx chips
zcrayfish: any good way to guess the ddc line if it is not being detected correctly?
zcrayfish: Got a rv280.
agd5f: zcrayfish: what's the problem?
zcrayfish: X isnt getting the EDID for some reason.
agd5f: zcrayfish: and the monitor has one?
agd5f: dvi or vga?
zcrayfish: the system is an eMac... openfirmware, can't remember where I got the EDID from last time
agd5f: zcrayfish: ok
agd5f: I added support for the eMac last year. update your driver
zcrayfish: haha, I must have missed it
zcrayfish: Does MacModel have to be explicitly set with the newer version?
agd5f: zcrayfish: I don't think so, let me check
agd5f: should be detected
ossman: is it possible to tell Mesa to print whenever it chooses a software fallback and why?
ossman: would like to take the reactive approach to development
happycube: _groo_ - my t60 came back from hibernate just fine
taiu: sent some fixes for r600 to 7_6 branch these allow sauerbraten to start with shaders enabled at least
taiu: ahh, the clutter-gst fosfor bug for kdekorte also
ajavid: how does one turn on vblank in radeon driver on debian lenny xorg 7.3
ajavid: please advise, I tried to google a lot but i didn't find the exact option for it
ajavid: I tried man radeon, /vblank and got nothing
R1ck: hi guys, I'm trying to force the DVI-0 output to enable but it's not working, I do it with "Option "Enable" "true"" but the log tells me "(EE) RADEON(0): Output DVI-0 enabled but has no modes after xf86InitialConfiguration"
R1ck: so I added a ModeLine and do PreferredMode "ModeLineID" but it seems to just ignore it
R1ck: the card is a ATI Technologies Inc RS400 [Radeon Xpress 200]
slavka: hello all!
ni1s: hi all, i'm getting weird artifacs on the 3d models in a game(freespace 2), bits of the model shoot of into infinity, other than that things run smooth, is this something on my part or a bug?
ni1s: its like the polygons dont render where they are supposed too
marvin24: how stable is gallium on r300, e.g. does it make sense to report a bug?
dileX: marvin24: which r300g are you using? xorg/st? dri/st? dri/st on softpipe? etc.
marvin24: dileX: I think dri/st with rs690
marvin24: most apps crash in r300_vs_tab_routes
macmaN6789: hows everyone
hnsr: terrible :(
macmaN6789: i am sort of tearing my hair out with radeon git on a 200m
macmaN6789: it refuses to send correct output to VGA-0
macmaN6789: instead it just clones the laptop display with the laptop display resolution
macmaN6789: it cares about no amount of xrandr-ing
macmaN6789: with --right-of and --crtc etc
macmaN6789: at the same time, when x11vnc myself into the machine, i see the correct picture in the framebuffer
macmaN6789: with two screens showing what they should
macmaN6789: but the user behind the laptop does not see the right-of screen
macmaN6789: this started when i moved to KMS
macmaN6789: and had to upgrade most of the underlying shiznit to HEADs
macmaN6789: no errors no nothing in xorg.log, everything seems normal, except we are just not setting crtc 1 right and we dont want to hibernate anymore
macmaN6789: and 3D is horribly broken too
macmaN6789: aside from that, its cool
macmaN6789: i see no similar bugs in bugzilla
macmaN6789: should i file a new one or any other suggestions
glisse: macmaN6789: there is open bug at bugzilla.redhat.com
glisse: for similar bugs
macmaN6789: Xorg.0.log -> http://pastebin.ca/1637098 looks all ok doesn it
adamk_: Nothing bad jumps out at me in there.
macmaN6789: i agree. how do i debug what happens when i do something to VGA-0 with xrandr
macmaN6789: would strace help?
macmaN6789: somewhere something does not do its job
macmaN6789: i cannot do modeset=0 either, that's an Xorg blackscreen
macmaN6789: wonder if this is kernel related
macmaN6789: googling "r300 radeon kms" gives some patches for initing r300 and rs480
macmaN6789: 2.6.31 ebuild is from 29. sept, these patches are 30. sept
twoerner: airlied: ping
macmaN6789: switched back to 2.6.28-r10 and 6.12.4
macmaN6789: works fine
macmaN6789: i guess i'll wait for tuxonice-sources-2.6.32 before trying again
glisse: twoerner: consider timezone
twoerner: glisse: jup, forgot about that
rnoland: sigh, this committing to 7_6_branch then waiting around for a merge to master is a pain....
happycube: marvin24 - rs690 has no vertex shader, and r300g isn't recognizing that for some reason
happycube: i just tried it last night on my rv515... the vertex code isn't really working on that either ;)
happycube: (although i'm going to try to debug it this week(end) and get some more redbook demos working)
rnoland: nice... i was trying to understand the r700_assembler.c well enough to add ARL support....
agd5f: rnoland: the merge to master is trivial, however, it seems openarena is busted after the merge. I'm hoping make clean will fix it
rnoland: agd5f: hrm... yes... i've done a local merge... i'm thinking of just cleaning up my branches so i can just commit the merges upstream...
rnoland: it's really frustrating that people on master aren't getting fixes/brokenness, but 7.6 is..
rnoland: i do have commit rights... i just don't trust my skills in mesa to commit new stuff without review....
agd5f: well, master gets them eventually
agd5f: someone just has to merge it periodically
rnoland: it's the eventually part that i find frustrating....
rnoland: i've got a kernel build running now... but i'll test the merged driver in a few minutes as well.
agd5f: actually, I think I may be using an old kernel
agd5f: with a broken drm
rnoland: agd5f: were are we with interrupts, btw?
rnoland: i also had someone asking me about evergreen a day or so ago....
rnoland: agd5f: i would happily test your interrupt code... ;)
agd5f: yup that was it
rnoland: i think i'm done with zfs boot for the moment, so....
alpha_one_x86: Hello, I have a ATI Radeon HD 5750 and I'm under linux. Do you see the problem? Have you solution for my? (fglrx not work too)
biotube: alpha_one_x86: what problem?
agd5f: rnoland: well, still only partially working. I suppose I should try and get a broken patch out for people to look at
alpha_one_x86: ATI Radeon HD 5750 is not supported by any drivers (not 2D)
biotube: you should be able to use the vesa driver
biotube: if nothing else
alpha_one_x86: I'm in dual screen, the vesa driver not provide it
rnoland: alpha_one_x86: it's coming... just not there yet.
agd5f: the handler currently oops for some reason, and sw interrupts seem to hang the CP. but vblanks and other display related stuff works, other than the oops
rnoland: agd5f: hrm....
agd5f: alpha_one_x86: I think you should be able to use fglrx in the meantime
rnoland: agd5f: ok... well i'd like to see it.
rnoland: oh, hanging the cp could be a problem....
alpha_one_x86: fglrx show: unsupported hardware in red, and inly my first screen is activated
rnoland: the panic I could maybe deal with though.
alpha_one_x86: At which date do you thinks r8xx work on 2d? 1 week? 1 month? 1 year?
agd5f: alpha_one_x86: hw is arriving early next week and and I have modesetting half-written already
agd5f: not sure about accel yet
alpha_one_x86: Then the drivers work with r8xx in 2d (without acceleration) with dual screen in few time? (<2week)
agd5f: alpha_one_x86: hopefully. we'll see howthings go once I have the hw
ky0j1n: Hello, I have a mobility ati radeon hd2600 and I'm just wondering can i use the FOSS drivers for 3D games or not? thanks
adamk_: ky0j1n, Yes, you can. But you need to compile various parts from source.
adamk_: ky0j1n, No distribution currently ships with 3D enabled for that card in the open source drivers.
ky0j1n: but what about fedora 12 beta?
adamk_: I *think* it's enabled, but not 100% certain of that.
adamk_: I believe the mesa driver is included but KMS isn't.
adamk_: Or maybe it's the other way around.
ky0j1n: ok thanks for the help
MostAwesomeDude: F12 should have the KMS but not the Mesa.
adamk_: Ahhh, so I did have it backwards.
adamk_: It shouldn't be hard to compile the mesa driver, though.
adamk_: F12 must have a new enough drm, libdrm, and ddx, so that's the only other component that would be needed.
rillian: ./configure: line 12446: syntax error near unexpected token `XINERAMA,'
rillian: ./configure: line 12446: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)'
rillian: I'm guessing yum-builddep didn't work
ky0j1n: seems that KMS doesn't work on my graphics card yet :'( the screen freezing after few second after login
MUEP_: ky0j1n: F12 has hardware opengl support for it
rillian: any suggestions where to find the correct m4 file?
MUEP_: ky0j1n: but currently the beta seems to require disabling KMS to avoid freezes
adamk_: rillian, I believe you need a newer version of the xorg macros.
rillian: yes, that
MUEP_: ky0j1n: at least for my HD3650, F12 offers enough acceleration to play xmoto, warzone2100 and neverball
rillian: maybe I should just upgrade to f12; was hoping to wait until it was stable though; this is in theory a production machine
MostAwesomeDude: Wait. Seriously.
adamk_: This is all development code still.
MUEP_: try a live image! :-)
MUEP_: after booting a F12 beta live image, su -c 'yum install
rillian: I have one of those, but that's as bad as being offline as far production duties go.
rillian: I suppose running the xserver out of git might hurt with that too, but at least I'll notice and reboot :)
rillian: anyway, I want to test agd5f's power management, which I don't think is on by default in the live cd
ky0j1n: MUEP_ i tried to booting with radeon.modeset=0 but after 10 minutes of updating my system suddenly freezed
MUEP_: ky0j1n: did that option actually disable KMS?
MUEP_: I've been using the nomodeset option
ky0j1n: MUEP_ sure
agd5f: I'm not sure the fedora kernels have the latest drm bits yet. they also have aspm enabled with causes problems with some cards. you might try disabling that
ky0j1n: sorry, but what is that "aspm" mean? :)
agd5f: ky0j1n: active state power management boot with aspm=0 IIRC
rillian: ky0j1n: PCIE power management protocol
dileX: MUEP_: I heard its capslock-day today (on another channel)
rillian: well, XINERAMA isn't in the macros repository
osiris_: MostAwesomeDude: can you pastebin latest version of your HWTCL fast-path patch?
MostAwesomeDude: osiris_: Sure. It's still not done, but sure.
spstarr: drm-next is awfully quiet :-)
spstarr: same for mesa r6xx :)
spstarr: looks at agd5f's side branches
dileX: spstarr: dri-devel ML
spstarr: dileX: looking
spstarr: oh nice
spstarr: lots of work in background
osiris_: MostAwesomeDude: I'm ok with WIP version
MostAwesomeDude: osiris_: Alright. Note that I just committed about half of it.
MostAwesomeDude: Oh, I need to push. One second.
spstarr: airlied: why not give agd5f access to your git tree to commit directly?
spstarr: or he can
agd5f: spstarr: you can grab my patches from the mailing list
MostAwesomeDude: osiris_: Pushed.
spstarr: about to
osiris_: MostAwesomeDude: thanks
MostAwesomeDude: osiris_: The stash of uncommitted changes is http://paste.pocoo.org/show/146457/
osiris_: MostAwesomeDude: here's my proposal for draw-less rendering http://pastebin.com/m57fc7fb8 basically I want it to directly parse the pipe_vertex_buffer and pipe_vertex_element arrays. will use auxiliary/translate module for converting vertex data/indices if necessary
MostAwesomeDude: osiris_: Agreed, although we shouldn't need translate.
osiris_: MostAwesomeDude: so state tracker will never feed us with vertex data in format that we cannot handle?
MostAwesomeDude: osiris_: Oh, sure, eventually, e.g. doubles.
MostAwesomeDude: But for now we'll only be seeing floats and 4ub, so shouldn't be too tough.
osiris_: MostAwesomeDude: it depends on the app
MostAwesomeDude: osiris_: Sure, and at that point, we'll do translate.
MostAwesomeDude: But I'd much rather have this working first.
osiris_: MostAwesomeDude: ok
MostAwesomeDude: I agree with you on directly parsing the vertex_elements.
osiris_: MostAwesomeDude: ok, I will continue working on it
MostAwesomeDude: osiris_: Alright. I'm going to see if I can figure out a good way to get the vertex_buffer/vertex_element parsing correct.
ossman: MostAwesomeDude, ping
MostAwesomeDude: ossman: Pong.
ossman: MostAwesomeDude, is there a way to get Mesa to tell you when it uses a software fallback?
ossman: I though I'd start throwing stuff at the r600 dri driver and fixing stuff as it pops up
MostAwesomeDude: I honestly am not sure.
MostAwesomeDude: I never was well-acquainted with Mesa's fallback system.
agd5f: ossman: r600 doesn't handle fallbacks too well at the moment, it will more likely fail to render rather than fallback
agd5f: ossman: low hanging r600 fruit would be filling in missing opcodes,
agd5f: switching verex fetch to use fetch shaders
agd5f: and using semantic ids for component routing
ossman: agd5f, I got xbmc to run on it, but it was slow as hell. so I figured I could start scratching my particular itch by fixing the operations xbmc throws at mesa
agd5f: ossman: not too familiar with xbmc.
agd5f: ossman: osiris_ and nha might know more about the fallback handling
ossman: agd5f, but for reference, fallbacks are handled in the drivers, not by giving some capability flags to mesa?
agd5f: ossman: yes
ossman: that should make things easier to follow
osiris_: ossman: is the r600 driver using tnl module for rendering?
ossman: osiris_, I have no idea. I'm just getting started with this :)
agd5f: osiris_: we switched over to draw_prims
osiris_: agd5f: aha, where's the code?
agd5f: osiris_: although it could use a cleanup. the old tnl path is still there for some cass
osiris_: agd5f: yeah, it looks like when you fallback to software rendering you're still trying to render with hw tcl
osiris_: agd5f: and I believe you should go right away for software rasterizer
osiris_: so just remove the _r700_tcl_stage and _r700_render_stage (and code used there) and that should be all
spstarr: ossman: I bash the r6xx with secondlife
ossman: odd.. xbmc runs just fine on the new machine I set up...
spstarr: but it seems VBOs seem broken in Mesa 7.7-dev...
spstarr: for intel/radeon
ossman: hmm... maybe not. It's eating 60% cpu...
_Groo_: hi/2 all
_Groo_: agd5f: ping
_Groo_: airlied: ping
agd5f: _Groo_: pong
_Groo_: agd5f: hey alex
MostAwesomeDude: agd5f: How would I render to z24s8?
MostAwesomeDude: Or is it just not a valid renderbuffer?
PsyMan`: it's fine
PsyMan`: if supported
MostAwesomeDude: PsyMan`: I'm talking about low-level renderbuffer targets.
MostAwesomeDude: e.g. rendering to depth texture.
agd5f: MostAwesomeDude: not sure
_Groo_: agd5f: could you take a look at 23715? ill be right back
PsyMan`: isn't that even supported on ogl?
MostAwesomeDude: agd5f: Alright, thanks. Time to ask the wider crowd.
PsyMan`: i mean, isn't there fbo instead?
MostAwesomeDude: Actually, no. I just won't.
MostAwesomeDude: PsyMan`: Depth textures aren't color textures.
ossman: from the software rasteriser
ossman: I'm guessing something is broken :)
agd5f: ossman: looks like bug 24281
ossman: agd5f, looks very similar indeed
ossman: agd5f, the referenced commit is for gallium though
agd5f: ossman: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_6_branch&id=869e20bcb7db9c6540eb6b538104303df738d302
ossman: agd5f, but this is software rendering
agd5f: ossman: ah, ok
agd5f: nevermind then :)
ossman: or maybe not
ossman: I did LIBGL_ALWAYS_INDIRECT=1, but with AIGLX I guess that gets accelerated as well, just via X11?
airlied: MostAwesomeDude: on r500 I think there is a z24s8 texture format that isn't in the docs
MostAwesomeDude: airlied: How would that be swizzled? x00w?
MostAwesomeDude: Also there *is* a W24_FP format that corresponds to z24s8.
MostAwesomeDude: I'm mostly just annoyed/concerned that Gallium was written for s8z24 chipsets.
ajami: I am trying a game out, and this keeps appearing in the console: Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
ajami: Anything I can do about it?
ajami: git mesa, git drm, fedora 12 kernel (kms enabled), rv610
MostAwesomeDude: It's not a problem; it's just printing out the return value it's sending back to your game.
MostAwesomeDude: ('Cause most engines don't do glGetError() after every call.)
MostAwesomeDude: If you're feeling adventurous, you could delve into the engine's code and see why it's doing that; it may depend on the GL_INVALID_ENUM value as part of its setup.
MostAwesomeDude: Even though that's wrong and stupid, it's *very* common practice.
ajami: How about something like this: Mesa: User error: GL_INVALID_OPERATION in glEnd
ajami: Maybe using an nv extension?
MostAwesomeDude: Ah, that's not good news.
ajami: For the driver or for the game?
MostAwesomeDude: Well, the engine author messed up and put something bad in a glBegin/glEnd pair. Probably will lead to unexpected results.
MostAwesomeDude: The driver doesn't care; when you see these messages from Mesa, it means that Mesa's just ignoring whatever caused the error.
airlied: MostAwesomeDude: I think W24 corresponds to Z24
airlied: hmm maybe I misread it earlier
airlied: my rv530 reg files don't have it, my main desktop machine is offline
_Groo_: hey airlied
_Groo_: airlied: something is wrong with no-tcl implementation in radeon/mesa, see bug 24281
MostAwesomeDude: airlied: It was in either r5xx or r3xx registers, can't remember. But it should work on all chipsets.
PsyMan`: w is the w buffer
PsyMan`: z is the z buffer
_Groo_: airlied: GE cant zoom, the images get all garbled up, the usual evil rs485.. and both my cores go up to 100%, which mean softpipe, right?
ossman: agd5f, , mesa HEAD doesn't have the bug, so it was probably the bug you were referring to. Thanks
agd5f: ossman: cool
Pulsewidth: I'm using a 120Hz monitor with the "radeon" driver. I can set 120Hz mode with xrandr, and Xorg.0.log shows 120Hz support, but my xorg.conf modeline is ignored and 60Hz mode is used instead
Pulsewidth: /var/log/Xorg.0.log: http://pastebin.com/m32059036
Pulsewidth: xorg.conf: http://pastebin.com/m235eb380
osiris_: MostAwesomeDude: hmm, for rendering to depth buffer I would setup US_W_FMT properly and use a fragment shader that just writes depth component
MostAwesomeDude: osiris_: Well, that's what normally happens during depth write.
MostAwesomeDude: The thing is, what happens if they want to use a depth buffer for colorbuf and also a depth buffer for depthbuf?
MostAwesomeDude: You've gotta trust the state tracker a bit.
Pulsewidth: Ah, I think I figured it out
osiris_: MostAwesomeDude: hmm, we could check the fp whether it doesn't write to color buffer and discard it .. or unset all render targets in US_ALU_RGB_ADDR[0-63]
Pulsewidth: I thought the problem was a mismatch between Modeline "1680x1050_120.00" and Modes "1680x1050", but I corrected it and X still defaults to 60Hz mode
MostAwesomeDude: osiris_: Or we could just not allow depth textures to be used as colorbufs. :3
_Groo_: agd5f: did you had the time to take a look at the bug?
agd5f: _Groo_: not at the moment
_Groo_: agd5f: are there any driconf settings i could try to ease GE?
agd5f: _Groo_: I'm not sure what the problem is off hand
_Groo_: agd5f: the bug 24281 ilustrated it easily, even has screenshots lol
_Groo_: agd5f: basically GE doesnt update the maps when it starts to zoom
_Groo_: agd5f: it mingles every single map refresh making it a macarronic mess out of it
osiris_: MostAwesomeDude: I should have VBOs working this weekend. implementing it in gallium infrastructure is a real pleasure :)
MostAwesomeDude: osiris_: Alrighty. Hopefully the little cleanups I'm doing here and there make it easier.
osiris_: next on my todo list would be RS setup and OQ
MostAwesomeDude: RS setup was already double-checked by airlied.
MostAwesomeDude: OQ is there, just not quite working for some reason.
airlied: I blamed OQ fail on rendering not working ;-)
osiris_: MostAwesomeDude: I'd be really happy if you could take a look at the textures. e.g. progs/tests/texobj isn't working
Pulsewidth: Can I used directfb and Xorg radeon at the same time?
MostAwesomeDude: I'm gonna go with "no."
Pulsewidth: I'm looking for some way to run emulators with vsync as the timing source
Pulsewidth: I used to use Nvidia with nonfree drivers, and I've use OpenGL + vsync
Pulsewidth: But opengl isn't ready for RS780 yet
MostAwesomeDude: Use fglrx or wait for vsync support to be released.
zhasha: what's the big deal with vsync anyway?
russell_h: is there a known issue with colored lines appearing at the top of the screen and/or weird blocky stripes appearing near the bottom with xv playback?
Pulsewidth: zhasha: old consoles were designed around TVs for timing purposes
Pulsewidth: It's impossible to get perfect scrolling if you use any other timing source
Pulsewidth: Additionally, I have a 120Hz LCD, so I can modify emulators for blank frame insertion, halving the sample and hold blur
zhasha: I'm wondering why it's so hard to get it right
Pulsewidth: I just double buffering, and a swap buffers call that blocks until the buffers actually swap on vsync
MostAwesomeDude: We usually do vsync with IRQs.
Pulsewidth: Ideally I'd like movie players to use vsync as timing source too
MostAwesomeDude: Er, no.
Pulsewidth: Maybe I can hack mplayer for it eventually
MostAwesomeDude: No, no, please no.
Pulsewidth: The sound should be resampled to match the video if the frame rate isn't perfectly in sync
Pulsewidth: That way I can get perfect 5:5 pulldown for 24fps movies and 4:4 for 30fps
MostAwesomeDude: Go talk to the mplayer people sometime. AV sync should not be done that way.
Pulsewidth: AFAIK there's no other way to get guaranteed zero judder
MostAwesomeDude: You're assuming that vsync never hiccups.
Pulsewidth: It didn't with nvidia drivers + opengl + low latency configured kernel
MostAwesomeDude: You're also assuming that on-the-fly sample conversion for sound is always accelerated, and that there's no variable latency in the sound driver.
MostAwesomeDude: And you're also only talking about one video acceleration scheme, ignoring the other dozen drivers mplayer has.
Pulsewidth: If there's some way to detect clock drift in the audio, it should be possible to write some smart frequency domain timestretcher to resync it without changing the speed (transparently adding or skipping audio)
Pulsewidth: You can't just change the resampling rate on the fly because even extremely subtle pitch changes are audible
Pulsewidth: But adding or skipping audio is much more transparent than adding or skipping video, because the audio isn't divided into frames
MostAwesomeDude: If you want a perfect reproduction, go to Blockbuster, rent the DVD, and use a tabletop DVD player.
Pulsewidth: So AFAIK all media players get the timing source backwards
MostAwesomeDude: And then all you'll need are the Monster cables for your speakers.
MostAwesomeDude: Also audio *is* done in frames.
Pulsewidth: Yeah, but you can buffer it and process it in samples
Pulsewidth: Video playback doesn't need low latency
Pulsewidth: I bet there's some way to get audio and video running on the same clock with expensive hardware
zhasha: again, why is it so hard to get vsync right?
MostAwesomeDude: It's not. Tell the card to send you an IRQ on the next vblank, then draw when you get the IRQ.
MostAwesomeDude: Very easy.
zhasha: isn't it just a matter of not drawing shit to the monitor until the monitor is ready?
zhasha: okay then, why don't we have vsync working?
MostAwesomeDude: Well, if you're talking about the actual CRTC, then that's different.
MostAwesomeDude: That's the PLLs and all the modesetting gear, and that all works.
MostAwesomeDude: What's missing for r600 is how to get the IRQs turned on.
zhasha: my r500 doesn't have working vsync
MostAwesomeDude: It should; my r400's vsync works fine when enabled.
zhasha: how do I enable it then?
MostAwesomeDude: It's part of the GLX code.
zhasha: MostAwesomeDude: when I have compositing on at least, it doesn't work
_Groo_: ge is still incredibly slow..
_Groo_: one of the rendering glitches as to do with s3tc aparently
spstarr: VBOs seem to be working in today's mesa build
spstarr: ERROR: mapBuffer: glMapBuffer returned NULL (no vertex data)
spstarr: SL crashed ;/
spstarr: 2009-10-23T01:56:20Z INFO: mapBuffer: vertex buffer size: (num verts : num indices) = 1496 : 4995
spstarr: 2009-10-23T01:56:20Z INFO: mapBuffer: GL_ARRAY_BUFFER_ARB size is 59840
spstarr: 2009-10-23T01:56:20Z llrender/llvertexbuffer.cpp(821) : error
spstarr: 2009-10-23T01:56:20Z ERROR: mapBuffer: glMapBuffer returned NULL (no vertex data)
spstarr: the GPU is hot
spstarr: but as long as protects itself from overheating
edt: what does VBO stand for?
spstarr: Vertex Buffer Object
happycube: odd - my t60 (rv515)'s kms comes out of hibernate but not sleep
happycube: interesting... r300g only draws one of the spheres in prog/redbook/planet
happycube: (if you comment one out, the other'll draw)
happycube: softpipe works and the gallium traces match
happycube: is new at gallium debugging
happycube: how can i get debug output from r300g itself?
MostAwesomeDude: RADEON_DEBUG=help will list the debug flags.