terracon: spstarr: I think Fedora's kde is one of the best now. I was thinking of writing an article about it. See if I could get it on lxer. I have to look at opensuse again for their kde before I say Fedora's is 'the best'
airlied: vehemens: what output are you using?
airlied: DVI or HDMI or VGA?
terracon: kubuntu is really meh. Linux mint kde .. meh
vehemens: airlied: dvi driving a 1920x1200 monitor
spstarr: terracon: thats the goal :)
spstarr: but i stick to KDE trunk since i need to track 4.4 now
terracon: slackware kde . kinda meh'ish. It actually wasn't bad. Very stock though. I could live with it
airlied: vehemens: does it happen if you lower the resolution?
airlied: vehemens: also have you tried playing with the coherent mode on the xrandr
ssieb: vehemens: ah, when I tried to run it to my tv at 1080p, it flickered pretty badly. thought it was the cable or converters or not strong enough signal.
vehemens: hadn't cared all that much until i killed my r3xx card last night while switching them between machines
ssieb: at 1024x768, there was no flicker
ssieb: I now have a different card in there that works with the same cable/converter
terracon: Fedora's kde has went from bastard child to .. wow
terracon: what I didn't like about ubuntu was that if you wanted newer things it's always in a ppa never in the main repo. So you get all these ppa's in your sources.list. I don't really like that and they're all unsigned
vehemens: airlied: havn't played around with the resolution yet, but going from bios version 1603 to 2302 did make a difference.
airlied: wierd the bios shouldn't make a difference once X is started
ssieb: I guess I should go looking for a bios upgrade
ssieb: but I agree with airlied that's kind of wierd. does the video subsystem have its own bios?
terracon: atom bios?
airlied: yes but still it shouldn't really matter, unless it inits something different than before
vehemens: can't say it made a difference on both machines, but on the the 2nd i ran twm before and after the upgrade and the improvement was significant.
terracon: twm. sweet. xeyes
vehemens: went from ~1/4 second blanking every second to random horizontal lines every ~5 seconds.
DanaG: xeyes & xeyes & xeyes & xeyes & xeyes & xeyes & xeyes & xeyes &
DanaG: and then scatter them randomly.
MostAwesomeDude: airlied: New CS check and old CS check can't coexist. I'll port it when it hits Rawhide.
vehemens: xeyes was yesterdays glxgears
terracon: heh, true
ssieb: oh, so the fix wasn't complete? I'll stick with the new card then :-)
DanaG: now, what would the fgl_glxgears thingy (gears on a cube) be?
DanaG: xeyes with each pupil as another xeyes?
airlied: MostAwesomeDude: there is no old CS anymore
airlied: MostAwesomeDude: I'll be pushing it into rawhide soon
spstarr: don't let rawhide bite you
MostAwesomeDude: airlied: I'll do the fix later; trying to get my stupid shatter code to start.
vehemens: airlied: according to the server log, coherent mode is enabled.
airlied: vehemens: maybe try disabling it
airlied: I'm never sure which was it the good way )
vehemens: ah, the just change it approach :)
EruditeHermit: is fgl_glxgears available as open source?
vehemens: airlied: coherence didn't help, but changing the resolution did. what do think the problem is: a chip limitation, pll configuration, asus limitation, or something else?
MostAwesomeDude: EruditeHermit: It uses pbuffer, not fbo. :T Why not use fbo_cubegears or WTF it's called in progs/demos...
MostAwesomeDude: progs/demos/gearbox is the one I'm thinking of.
airlied: vehemens: it soujnds like a bandwidth problem in the memory controller
airlied: the dvi sin't getting enough memory ban dwidth
airlied: you can get fgl_glxgears to run fbo
airlied: with -fbo
EruditeHermit: but is it available for all?
EruditeHermit: i know its part of fglrx
MostAwesomeDude: What's the difference between fbo and pbuffer? Anything driver-specific?
MostAwesomeDude: feelin' too lazy to read GL specs
airlied: I got it from google codesearch :)
vehemens: airlied: i think you just told me my hw sucks, and i should get something better :]
airlied: vehemens: it can be fixed
airlied: we seem to have a lot of issues with 1920x1200 screens
airlied: picking a different PLL might help
airlied: alex generally knows more about this than me
EruditeHermit: airlied: you got the code for fgl_glxgears on codesearch?
MostAwesomeDude: Hm. Looks like pbuffers should totally be doable with Mesa, but unfortunately they only work with GLX, not the general GL core.
airlied: EruditeHermit: yes
EruditeHermit: what I never got is why pbuffer is supported in client and not server
vehemens: airlied: Clock: mode 65000, PLL 64990 PLL : refdiv 13, fbdiv 0x2C4(708), fracfbdiv 1, pdiv 12
EruditeHermit: i tried asking about this but just got confused more =p
MostAwesomeDude: Probably because the GLX in the server isn't quite un-bitrotted yet.
EruditeHermit: MostAwesomeDude: you said the gallium code was almost complete for first pass right?
EruditeHermit: just have to actually make it all work
MostAwesomeDude: EruditeHermit: "First pass?" You mean, non-FBO rendering?
EruditeHermit: I mean you've coded it all
EruditeHermit: but not all of it works
airlied: EruditeHermit: becase libGL can just pass it to the server
MostAwesomeDude: Yeah, it was definitely not done in one pass. :3
airlied: so the client "supports" it
MostAwesomeDude: But yeah, insofar as I'm not planning more big chunks of code to it for a bit, yeah.
EruditeHermit: what I don't get is why different drivers have different sets of server extensions
EruditeHermit: because not as simple as the driver being the client and the server being the server
EruditeHermit: the driver is the client and server
EruditeHermit: in weird ways
airlied: just because the server claims it support something, it is also sorta lying
airlied: since I think we say we support something but don't expose the visuals to actually use it
airlied: or fbconfigs
MostAwesomeDude: I don't think there's any actual, rigorous GLX protocol tests.
EruditeHermit: the problem is, certain programs query that list
EruditeHermit: and use it to determine whether they can work/run
EruditeHermit: and if that list is not up to date it causes problems
EruditeHermit: we just really need gallium and OGL 2.1 support =p
vehemens: airlied: is the issue related to phase noise due to the fractional divider?
fpoibaf: osiris_: I just file 3 new bugs against r300 driver:
ferret_: Heh, unkillable X. I had that.
aberres: agd5f: ok, thanks
ferret_: fpoibaf: are any of those open source?
ferret_: I'm not a developer but I can take a look when I get home
fpoibaf: sauerbraten and nexuiz are open source
fpoibaf: prey no
fpoibaf: (well the game data for sauerbraten is not free but the engine is under a zlib licence IIRC)
ferret_: That one doesn't look too hard to work it, if it happens at such a specific point.
aberres: ehem, maybe a stupid question, but in which comonent in bugzilla is the radeon driver hiding?
aberres: i guess mesa is just the 3d part
ferret_: Seems to be Driver/Radeon
aberres: ah, xorg/driver/radeon. sure :)
aberres: #22744 opened
phoenix64: "If OFF, the Setup Engine will bultiply the X, Y coordinates by 1/W0.," - bultiply ftw :D
MrCooper: airlied: looks like there's a problem with the libdrm_radeon space checking flushing itself - the flush may invalidate the BO passed in
EruditeHermit: MrCooper: hey
EruditeHermit: can what you just described cause problems with mesa?
EruditeHermit: in DRI1
MrCooper: no, it's a DRI2 specific issue
EruditeHermit: on a separate note
EruditeHermit: your last patch for synchronous debugging stopped the crash from occurring
EruditeHermit: so I wasn't able to get the logs
EruditeHermit: why would that be?
EruditeHermit: and does that give any clues?
MrCooper: not sure
MrCooper: it may still be that AGP just isn't stable in your setup, and making Composite operations synchronous just happens to avoid the problem
EruditeHermit: that sucks
zhasha: why is it that linux and agp appear to be mortal enemies?
MrCooper: AGP is just a horrible mess, proprietary drivers have tons of quirks to make it usable
zhasha: it doesn't look horrible though
glisse: zhasha: it's, braindead technology
zhasha: I don't see where the horrible mess comes into play. It's just a dedicated bus with a few enhancements over classic PCI
glisse: pretty much no manufacturer implement properly the AGP specifications
zhasha: oh, so it's another quirk table thing where the hardware devs have made seemingly retarded decisions, rendering their hardware completely unusable without a huge amount of luck?
MrCooper: pretty much
MrCooper: we can be glad it's on its way out
EruditeHermit: well still sucks for people with machines that use it
EruditeHermit: i.e. me
zhasha: I especially love quirks that manifest themselves as bugs only on certain days of the month and only if you're wearing a green tie and the moon is in the perfect position
EruditeHermit: oh I can reproduce it all the time
EruditeHermit: its just we can't reproduce it and get a log from it
zhasha: what's wrong with your machine?
AndrewR: hey, is this tri-viewport screenshot look normal? http://img406.imageshack.us/img406/8617/triviewportrv280dri2bug.jpg
zhasha: AndrewR: no..
AndrewR: zhasha, for some time mesa head is broken for non-composited case on rv280/dri2 ...
zhasha: is there an env to fall back to swrast?
zhasha: AndrewR: it looks semi-normal
zhasha: as if you have moved a window or two in front of it
AndrewR: http://img509.imageshack.us/img509/8617/triviewportrv280dri2bug.jpg - and this is with e16 composite manager active ....
EruditeHermit: gnight all
hifi: zhasha: LIBGL_ALWAYS_SOFTWARE=1
zhasha: hifi: thank you
AndrewR: if i move some other window on top of it - there might be slightly more correct image, but only once. Moving openGL window itself around the screen doesn't help. Resizing produces strange results.
AndrewR: should i add bug about it?
glisse: AndrewR: test with xserver from git before opening a bug
glisse: you might need to update ddx too
scarabeus: radeon_dri2.c: In function ‘radeon_dri2_create_buffer’:
scarabeus: radeon_dri2.c:171: error: ‘struct
scarabeus: i get this ^ right now when i try to compile from git?
scarabeus: what did i forget? :]
scarabeus: libdrm updated...
MrCooper: scarabeus: the driver needs to be adapted to some DRI2 changes in server-1.6-branch (at least it works for me with xserver master somehow...), you can look at what was done in xf86-video-intel
scarabeus: i have 126.96.36.1992
scarabeus: i will update :]
AndrewR: glisse, always on git master, see bug 22746
AndrewR: glisse, i'm just stupid, but i was unable to find where in radeon structs driDrawable w, h and other parameters are saved in r200 case ... there was intel i8xx viewport breackage some time ago, i looked at bug and debug patch in int, but ...radeon win :(
AndrewR: *in it
tsamolotoff: Hello to all again! Is there any worth of switching from 2.6.26 to 188.8.131.52 concerning radeon driver?
glisse: tsamolotoff: we try to improve things, so usualy it's good to upgrade
tsamolotoff: glisse: thanks.
tsamolotoff: It's just because I've read on phoronix, that overall performance degrades as the kernel's version ages... Or it was only for Ubuntu ? (I'm running Debian testing/squeeze with 1.6.99 X.org server)
glisse: agd5f: does MC_MISC_LAT_TIMER exist on r520 too ? i saw it only on rv515
glisse: agd5f: btw what to do for watermark, crtc bandwidth on rs600 ?
tsamolotoff: /msg nickserv identify e78s1t2
ArchType: Hello there.
ArchType: I haave dual head monitors. Primary is attached to teh notebook and extended via vga. Now. If I play game in full screen. How would I tell screen that it must on laptop monitor or on vga? And not on both.
ArchType: Any ideas?
tsamolotoff: It would anyway segfault or panic
agd5f: glisse: no only rs690/rs740 and rv515 have that reg
agd5f: glisse: I couldn't find info on rs600 bandwidth. although one could make educated guesses based on the bits in the integrated systems table
agd5f: vehemens: you might try Option "DisplayPriority" "HIGH"
agd5f: oga_: yes?
tsamolotoff: Pals, it's a really-really stupid question, but glxgears flickering while moving the window (KDE 4.3git, KWin) is normal?
agd5f: tsamolotoff: if you are running a compositer without dri2, then yes
agd5f: tsamolotoff: also, regarding the scaler, radeon supports center, aspect, and full, adjustable via xrandr attribute
tsamolotoff: agd5f: Can you elaborate on dri? I'm running kwin's compositer (not compiz)
tsamolotoff: Wow, what's a memory)
agd5f: tsamolotoff: any compositer
agd5f: dri2 is only available if you ahve kms (kernel modesetting) enabled
tsamolotoff: And if I'm running 184.108.40.206, can I enable it?
agd5f: tsamolotoff: nope. only on 2.6.31
agd5f: tsamolotoff: plus you need lots of other bits (updated ddx, libdrm, libdrm-radeon, mesa)
tsamolotoff: running X 1.6.99
agd5f: tsamolotoff: that xserver should be fine
tsamolotoff: You know, it would have been a way easier if I haven't just built beforementioned kernel... Maybe later, thanks for help
MrCooper: agd5f: btw, I just noticed that with KMS the cursor can't seem to move beyond the top of the CRTC
agd5f: MrCooper: you mean like hotspot offset?
MrCooper: if the hotspot isn't at the top of the cursor, the cursor stops at the top of the CRTC while the hotspot continues moving up
MrCooper: it's probably not handling 'negative' Y coordinate properly
MrCooper: seems fine horizontally though
MrCooper: hmm, the radeon DRM code looks fine though
phoenix64: MostAwesomeDude, ping
agd5f: MrCooper: ddx also writes RADEON_CUR_OFFSET in set cursor position
agd5f: cursor_base + yorigin * stride
MrCooper: ah right
agd5f: MrCooper: looks like CUR_HORZ_VERT_OFF may not be setup right
MrCooper: looks like the RADEON_CUR_OFFSET bit is probably needed?
agd5f: MrCooper: yes
tsamolotoff: agd5f: As for mplayer, what's vo is the best ?
agd5f: tsamolotoff: probably Xv
tsamolotoff: Ok, I'll try that
osiris_: nha: does this patch looks good to you? http://pastebin.com/m75b6a81c (relative addressing handling in nqssadce)
osiris_: it fixes last of the wine d3d9 test regressions
nha: couldn't there be more than one address register?
osiris_: at least ARB_vertex_program allows for only one
nha: it's the other way round: ARB_vertex_program *requires* at least one
osiris_: aah, right. but only X component is used
nha: but how are additional address registers stored in prog_instructions?
osiris_: hmm, mesa defines MAX_VERTEX_PROGRAM_ADDRESS_REGS as 1
osiris_: and MAX_PROGRAM_ADDRESS_REGS as 2
nha: I guess Mesa just doesn't support multiple address registers
osiris_: I just got an idea, about nqssadce.
nha: so it seems your patch is fine
osiris_: does it behave correctly when we have e.g. LIT instruction where components of source registers aren't mapped directly to components of output register
nha: at least that's one of the reasons why I advocate porting the shader compiler to gallium
nha: a significant amount of time has gone into ironing out bugs related to that kind of stuff
nha: oh wait!
nha: you mean in vertex programs, where we have dedicated LIT instructions
nha: hits head
nha: no, it's not handled yet, I believe
nha: because in fragment programs, we rewrite LIT with native instructions before nqssadce
osiris_: nha: DST instruction also have non-linear components mapping
osiris_: nha: which component of source registers holds the value used in scalar instructions?
glisse: osiris_: there is no rules for that iirc
glisse: hw require that you properly use mask to perform operation on selected component
osiris_: glisse: I know that ARB_vp spec doesn't describe it, but I'm sure mesa uses one dedicated component for this. r300-r500 hw uses W component for this
glisse: osiris_: i think higher level need to explicitly states which component to use in scalar operation
glisse: so mesa is just passing down the information
osiris_: glisse: yup, you're right.
agd5f: MrCooper: http://www.botchco.com/alex/xorg/0001-radeon-kms-fix-hotspot-handling-on-pre-avivo-chips.patch
tsamolotoff: Hmm, according to lspci, there's only 128M of VRAM onboard, however there's 256M on my M56...
agd5f: tsamolotoff: lspci just lists the size of the aperture
osiris_: nha: what about scalar instructions? does nqssadce handle it correctly?
agd5f: the aperture size does not equal the vram size
tsamolotoff: Then, how to obtain the true value?
nha: osiris_: it should
nha: osiris_: and I'm a bit fuzzy on the details; maybe mesa uses the .x component? Though in practice it might be the case that you just always get uniform swizzles
nha: i.e. xxxx, yyyy, zzzz, wwww
osiris_: nha: yes, we always get unfiorm swizzles
osiris_: for all scalar regs track_used_srcreg(s, inst, 0, 0x1) is called
osiris_: 0x1 means X component
osiris_: that doesn't look right to me
MrCooper: agd5f: where can I get the patch which introduces legacy_display_base_addr?
jcristau: MrCooper: looks like <firstname.lastname@example.org>
jcristau: Subject: [PATCH 2/2] drm/radeon/kms: set crtc and cursor offsets correctly on legacy chips.
MrCooper: ah indeed, thanks
nha: osiris_: why not?
nha: it's just a convention we adopt
nha: a scalar operation only sources a single float component
osiris_: nha: aah, right. it just always gets swizzle for first component.
_Groo_: hi/2 all
nha: it can sometimes be a bit confusing, since swizzles are kind of like permutations, and permutations aren't commutative ;)
_Groo_: airlied: ping
_Groo_: airlied: your latest fbo fixes, fixed kwin3d problem also :)
_Groo_: airlied: wow still doesnt run, but thats too much too soon :D
_Groo_: airlied: darn, googlearth still crashes a few moments after starting to draw the "world" :( anyway... the fixes are getting better and better :)
osiris_: nha: actually nqssadce works correctly for LIT and DST instructions - we use fixed mask to check sourced components for these insts instead of DstReg.WriteMask
agd5f: MrCooper: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-radeon-kms
osiris_: nha: I'm going to merge shaders_cleanup to master now
nha: osiris_: ah, maybe I was looking at the wrong branch
nha: anyway, go ahead with the merge
osiris_: yay, ut2004 is working again
osiris_: thanks airlied
glisse: btw why openarena is so slow ? stencil fallback ?
osiris_: glisse: it's fast for me with highest details and 2x aniso 1024x768 on rv535 (non kms)
glisse: will have to download the game again
glisse: it was slow as hell less then 2fps on any r3xx,r5xx hw
osiris_: maybe you had bloom effect enabled
osiris_: it's known to be sloow
glisse: bloom ?
osiris_: I think it needs FBOs to run at decent speed
glisse: it's a game option ?
osiris_: there's even a bug report for this
glisse: agd5f: is drm-radeon-kms branch working for you ?
agd5f: glisse: airlied's branch? I haven't tried it
osiris_: is KMS working with ddx from master branch?
agd5f: glisse: I've been tracking linus
agd5f: and cherrypicking bits from airlied
agd5f: not optimal, but all I have time for right now
glisse: hhhmmm so it's likely not my bw patch which breaks
KjetilK: Im installing my new HD 4770 :-)
KjetilK: question is, will this work with the drivers that are in Debian stable?
KjetilK: which is 6.9.0 it seems
agd5f: KjetilK: no. you'll need git master or 6.12-branch
KjetilK: agd5f, ok, thanks
KjetilK: anyone know of debs of it lying around?
agd5f: KjetilK: I think unstable has pacakges
KjetilK: agd5f, yup, it has, but it needs backporting
MostAwesomeDude: nha: Got your patch. If you don't mind, I'm going to split it into the various parts. Compile warning fixes, whitespace fixes, semantic improvements, and finally CS libdrm update. :3
nha: MostAwesomeDude: sure; it was fairly hacked together, since I was writing it while at the same time figuring out my way around the gallium code
MostAwesomeDude: nha: If we move over the r300 classic shader setup, I'd like to split it a bit. Some of the stuff really should be in aux/util or aux/tgsi.
nha: btw, I'm right now in the process of untangling the fragment program compiler stuff from mesa-specific things
MostAwesomeDude: (We'll be the first to actually have shader optimizations. :3)
nha: makes sense, I guess
nha: the big thing will be instruction formats
MostAwesomeDude: I think the only radeon-specific optimization is doing pairs of insts for frag shaders.
agd5f: nha: does r5xx use nqssadce yet or just r3xx?
MostAwesomeDude: All the other optimizations and rewrites can (and should IMO) operate on TGSI streams.
nha: I'm still unsure how to do the changeover in a not-extremely disruptive manner, but I'm convinced now that we should go with TGSI as the format
nha: I just haven't decided the order of refactoring yet
nha: agd5f: yes, even pre-osiris' changes it was used for r500 fragprogs
nha: agd5f: post-osiris' changes it is used for everything
MostAwesomeDude: Maybe just port over the core pairing code for TGSI->native first, then each optimization?
nha: MostAwesomeDude: yeah, I think that's how I'm going to do it
MostAwesomeDude: Shouldn't be terribly difficult. You largely have carte blanche here; I'll assist if needed but I've got other things on my plate.
nha: nah, I think I'll manage
nha: I'm going to do all of fragment programs first, and then all of vertex programs
MostAwesomeDude: Ah. Are there really any changes that need to be made to vert shaders, aside from the fact that some insts aren't in there yet?
nha: MostAwesomeDude: what do you mean?
nha: the situation is analogous to fragment programs, isn't it?
MostAwesomeDude: nha: Well, we don't pair vert shaders, right? I've got a basic one-to-one assembler written, it just doesn't have all the insts yet.
nha: ah okay
MostAwesomeDude: r300 frag shaders are the ones that are pretty much unwritten.
nha: well, we'll see
nha: maybe it's indeed reasonable to only share code for fragment programs
ArchType: I have a Dell inspiron with ati mobilitx x1400 http://ati.amd.com/products/MobilityRadeonx1400/index.html It has 128mb onboard. How can I figure it out if I can share another 128MB from my ram?
agd5f: ArchType: the drm will setup the gart properly already
ArchType: agd5f: drm?
nha: I haven't really looked into it
agd5f: ArchType: the radeon drm kernel module
ArchType: and what's the gart?
agd5f: ArchType: address remapping for gpu access to system memory
ArchType: ...because I'm a little sceptic I can't run HD movies... I tried to watch buck buck bunny 1080pi but my cpu goes like 110%
MostAwesomeDude: ArchType: You don't have to tell it anything special; the kernel will magically make things happen for memory management.
ArchType: MostAwesomeDude: it doesn't do it so awesome as I thought :)
ArchType: since I can't watch HD movies :)
otaylor: ArchType: that ahs nothign to do with available video memory
agd5f: ArchType: check your xorg log and make sure the dri is enabled
ArchType: agd5f: dri in xorg.conf?
ArchType: no It isn't
ArchType: my xorg is almost empty
agd5f: ArchType: no, check your log
agd5f: it's enabled by default unless there is a problem
_Groo_: agd5f: ArchType: xvinfo and glxinfo should be quicker
agd5f: yes, that would work too
agd5f: ArchType: if xvinfo shows no adapters then it's not enabled
ArchType: | grep dri nothing there
ArchType: Adaptor #0: "Radeon Textured Video"
agd5f: ArchType: you are all set then
agd5f: ArchType: all video decode is currently done in software
agd5f: only the rendering is accelerated
ArchType: agd5f: so I'm using shitty programs like smplayer or vlc?
agd5f: HD decode is pretty cpu intensive
agd5f: ArchType: doesn't matter what player you use
agd5f: there's no decode support yet
ArchType: on: model name : Genuine Intel(R) CPU T2250 @ 1.73GHz ?
ArchType: which is core duo..
ArchType: damn.. I dunno..
agd5f: ArchType: apparently the multi-threaded ffmpeg or something like that helps
ArchType: agd5f: because also I have artifacts in all divx/xvid movies, picture isn't crystal clear
ArchType: agd5f: multi-threaded ffmpeg is some sort of a codec'
agd5f: ArchType: probably a problem with the encoding or decoding
agd5f: ArchType: it's the deocing engine used by most players
KjetilK: if this works, it was very straightforward to backport the drivers with apt-build
ArchType: for output driver I have xv chosen
ArchType: What is this: Enable posprocessing by default?
ArchType: also those artifacts, annoying as little insects :P
ArchType: oh and... I think HD should run on my CPU just smoothly since on my brother's sempron 3000 2ghz works just fine
ArchType: if it's ffmpeg issue as some ppl claim, where can I get this ffmpeg thing to fix artifacts and maybe hopefully hd movies
agd5f: ArchType: if your bother is running windows, it's using the GPU to accelerate the decoding most likely
ArchType: agd5f: yes he is
agd5f: that hasn't been implemented yet in X
ArchType: agd5f: oh
ArchType: one thing at the time..
ArchType: I will live with xvid/divx till then, but do you have any idea how can I get rid of artifacts'
nha: MostAwesomeDude: see, this is exactly I don't like the TGSI stream format: radeon_program_pair.c maintains ready-queues of instructions (which insns are ready to be scheduled on RGB alu, Alpha alu, TEX unit), which requires many instructions to be decoded and "in-flight" at the same time
nha: How do you suggest I should handle this?
agd5f: ArchType: maybe a newer version of ffmpeg or whatever your movie player is using for decoding
EruditeHermit: nha: are you working on gallium?
MostAwesomeDude: nha: Couple different ways. You could try to pair greedily. Isn't there a light IR you were using during pairing?
nha: EruditeHermit: not yet, but I want to port the fragment program compiler to Gallium
agd5f: ArchType: what version of the driver are you using?
EruditeHermit: nha: thats awesome
nha: MostAwesomeDude: you mean, change the algorithm
MostAwesomeDude: nha: Yeah. I'm not sure TBH; I never really "got" the pairing code.
nha: somehow, the stream-based nature pushes you very strongly into stream-like algorithmic thinking; it narrows your view of the possibilities
nha: it also seems a bit ridiculous that we should continually destroy and create streams
nha: but whatever
ArchType: agd5f: xf86-video-ati-6.12.2-2
agd5f: ArchType: that should be fine
MostAwesomeDude: nha: Yeah, I really don't like TGSI, but I think that it could be worse.
ArchType: agd5f: ffmpeg 0.5-1
agd5f: ArchType: not real familiar with ffmpeg or movie players
ArchType: agd5f: what player do you use for your personal entertainment?
ArchType: on computer of caurse..
agd5f: ArchType: I don't generally watch movies on the computer, but for testing I have several apps installed
ArchType: agd5f: can you please tell me some, so we can compare
agd5f: ArchType: totem, mplayer
ArchType: agd5f: when u run with mplayer, what options do you add in a shell?
ArchType: by default, just mplayer movie.avi I have artifacts
agd5f: ArchType: none other than using Xv
agd5f: ArchType: if it only happens with certain formats, it's probably a bug in the decoder
agd5f: so ffmpeg or mplayer, etc.
ArchType: agd5f: not sure.. I'll test DVD files now
dmb: pings Sarvatt
ArchType: defenetelly better quality with DVDs...
ArchType: it must be some sort of bug
agd5f: ArchType: probably a bug in the xvid decoder then
EruditeHermit: agd5f: still working on r6xx 3D?
agd5f: EruditeHermit: yes
nha: osiris_: the ARL test of vertProg1 started to fail: http://people.freedesktop.org/~nh/piglit/results/R500/RV530200907132319/test_glean__vertProg1.html
nha: there are some other regressions, too: 00907132319/test_glean__vertProg1.html
nha: in particular, fbo and maskedClear started to fail recently
nha: I'm too battered to track it down right now, though
osiris_: nha: I'll check the ARL
nha: thank you
osiris_: nha: looks like the nqssadce ARL fix isn't that simple. now it removes all but one ARL insts
EruditeHermit: agd5f: getting any closer to being done figuring out how to fix the issues with it? or is it still unknown
agd5f: EruditeHermit: most of the code is already in place, if we can just sort out this buffer aging problem, most basic stuff just works
EruditeHermit: is buffer aging code different for each generation of card? I would have thought the logic behind it would be the same no matter what the card
agd5f: EruditeHermit: the code is mostly shared
EruditeHermit: its just not playing nice with r600?
moeSizlak: any open source support for HD 3200?
EruditeHermit: moeSizlak: yes
EruditeHermit: moeSizlak: what are you looking for?
moeSizlak: which driver?
EruditeHermit: radeon or radeonhd
moeSizlak: im looking for an alternative to fglrx
EruditeHermit: do you want 3D?
EruditeHermit: if so, fglrx is your only choice now
EruditeHermit: but as the topic suggests, you can get 2D desktop + video working with radeon
chizu: Hey, is there a way to disable just the audio flags portion of EDID?
chizu: I've got a TV hooked up over HDMI, but a GPU without audio. When I disable EDID support, audio works, but otherwise not.
chizu: With an nvidia card I dumped what the TV gave me and removed the audio flags, then passed an option to load the modified flags from disk.
chithead: does not sound like a clean solution, can't you set the default sound card in alsa config?
chizu: The problem is the TV has no option to switch audio input.
chizu: If the HDMI connection reports that it supports audio, it disabled the other audio inputs.
DanaG: That's a stupid TV.
DanaG: Call the manufacturer of the TV and bitch at them?
chizu: Yeah, all the recent Lg models do this.
biotube: sounds like a thorn in the side alright
biotube: laughs to self
chizu: Point being, it took a couple minutes to work around on nvidia drivers, seems like it should be easy here too.
chizu: Also, not sure why the driver tells the TV it can do audio, I'm pretty sure this laptop doesn't have audio over HDMI at all.
biotube: probably boilerplate code
chithead: there is the IgnoreEDID option but I am not sure if it fixes your problem
chizu: It does, except then I have to use modelines :(
chithead: also I think radeonhd supports hdmi audio, you may want to try that driver
EruditeHermit: moeSizlak: hey
EruditeHermit: did you figure out what you needed to?
DanaG: How do you make a dump of edid, anyway?
hax0r1337: X -logverbose 9 or something, it will be get logged into XOrg.0.log AFAIK
hax0r1337: hehe, this was random: https://docs.google.com/a/google.com/File?id=dd5s8qw6_26d689h7ds_b