Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-01

Search This Log:


MostAwesomeDude: eosie: We're trying to be honest now WRT pipe caps, so please don't commit fake enables. :T
MostAwesomeDude: Since we only support rects and POT, why not just stash the PIPE_TEXTURE type in struct r300_texture?
eosie: MostAwesomeDude: well, as you wish
eosie: MostAwesomeDude: i don't know what you mean, the PIPE_TEXTURE type is in r300_texture::tex::target
MostAwesomeDude: eosie: I mean, I agree with you as far as testing, but it'd be a lot better to make mesa st lie for us and then fix it if it doesn't work on glean/piglit tests.
MostAwesomeDude: eosie: I mean that if we don't lie on PIPE_CAP_NPOT, we shouldn't ever get asked to handle NPOT PIPE_TEXTURE_2D.
eosie: MostAwesomeDude: but what if we get texture rectangle? that's also represented as PIPE_TEXTURE_2D, as far as I know
MostAwesomeDude: eosie: PIPE_GEOM_RECT or whatever it is, lemme find it.
MostAwesomeDude: PIPE_TEXTURE_GEOM_NON_SQUARE should be for rectangles. I'm going to ask for a clarification; frankly I'm tired of having so many undoc'd flags.
eosie: MostAwesomeDude: NON_SQUARE is also a confusing naming, 512x256 is a non-square but safely lies within the definition of POT
MostAwesomeDude: Hm.
MostAwesomeDude: This is going to require more thought, and possibly some more API definition.
eosie: MostAwesomeDude: concerning NPOTs, I agree with you, honestly I kinda expected the patch to get refused
SimplePPC1: hi
zhasha: SimplePPC1: hello
zhasha: MostAwesomeDude, eosie: what did I miss?
zhasha: oh and I only committed that patch because it's the only missing piece in GL 2.1 support, which. Failing a few new piglit tests but gaining access to a ton more concerning features we already have is worth it in my opinion
eosie: zhasha: yes, it is
zhasha: eosie: can you work magic on mipmaps? :P
eosie: zhasha: if you want mipmaps working, i have an ugly workaround
zhasha: oh? do tell
zhasha: I can't even figure out what's wrong
eosie: zhasha: but it definitely cannot be committed
zhasha: that bad huh :P
zhasha: well, can you at least tell me what's wrong?
eosie: zhasha: first the workaround - just enable generating mipmaps in software, somewhere in auxiliary/util/u_gen_mipmaps.c is a condition that checks whether it can do gen-mipmaps in hw
zhasha: that only narrows it down to what I already know
eosie: zhasha: i think the problem is that we need render-to-mipmap functionality, right now we can render to the first mipmap only
zhasha: so where exactly do you suspect the problem is?
zhasha: because I looked at the trace, looked through everything at frankly, it all looks good
zhasha: and*
eosie: zhasha: emit_fb_state doesn't take the mipmap number into account i.e. it sets the coloroffset at the beginning of buffer backing the whole texture
eosie: zhasha: in the loop going through colorbuffers, surf->offset contains the correct offset to the given mipmap, but if I use it in OUT_CS_RELOC(buffer, surf->offset...), it doesn't work, so there must be something else we've missed
zhasha: I see... I've been looking up and down that function and never noticed that...
eosie: in fact, it dumps CS in cases when it did not
zhasha: airlied: any ideas?
zhasha: eosie: wait, it's supposed to be tex->offset + surf->offset
eosie: zhasha: that's already added in
eosie: zhasha: wrong, surf->offset is actually equal to the appropriate tex->offset[i]
eosie: for 2D textures
zhasha: I see...
zhasha: eosie: unsigned offset; /**< offset from start of buffer, in bytes */
dileX: zhasha eosie: thats my openarena.log with r300g dri/st. maybe it has some hints you can dig into.
zhasha: dileX: huh?
eosie: zhasha: is this pipe_surface?
zhasha: eosie: yes
eosie: zhasha: i think that's correct, isn't it? or what are you getting at?
zhasha: nevermind
zhasha: eosie: this is interesting:
zhasha: I added a debug_printf inside emit_fb_state, which prints the pitch of the surface cbuf: level 0 = 608
zhasha: that's a NPOT texture
eosie: zhasha: i guess that's the colorbuffer of the window
zhasha: hmm.. could be. anyway I have the color thing working in mipmap_limits
eosie: zhasha: but the color-thing mipmaps are not generated by mesa
zhasha: err, it seems that was working before, but I seem to have provoked some sort of half correct behavior in the mipmap generation
zhasha: looks like it's always getting the 1x1 pix mipmap correct
zhasha: MostAwesomeDude: currently, what happens if the st binds a fragment program, then binds another?
glisse: airlied: sadly it seems that the ttm fix for agp just postpone the bug :(
zhasha: MostAwesomeDude / eosie: ping?
eosie: pong
zhasha: eosie: I don't know if this means anything, but if I set format0 to have 0 mipmap levels, all mipmap levels are drawn with the texture from the first level
zhasha: basically I was just poking holes in everything because I was very much lost, but the only sensible idea I have is that somehow the sampler is the cause of bad mipmaps
eosie: zhasha: sampling a mipmapped texture works fine, in my opinion
spreeuw: getting weird crashes in the simplest programs now
ossman: glisse, ping
spreeuw: think i'm downgrading my xorg to 1.6 generation again
spreeuw: this sooks
zhasha: eosie: the offset by the way, should be set in the 2nd argument to OUT_CS_RELOC
zhasha: eosie: http://imagebin.org/70035 have a look at this and tell me what you see
eosie: zhasha: i know, but i haven't done so yet because it makes fbo-genmipmaps dump the CS
glisse: ossman: pong
zhasha: eosie: mipmap_limits/mipmap_view works fine with it
ossman: glisse, do you know why the r700 assembler splits up operations into one "math" operation and a "MOV"?
eosie: zhasha: yeah, it might have been somethin else
ossman: glisse, Looking at the docs, it seems like it can be done with a single instruction group
eosie: zhasha: i see garbage
eosie: *i can see
zhasha: eosie: notice that there are 2 pixels that are consistently scaled up
eosie: good catch
eosie: zhasha: it's one pixel, the texture is stretched
zhasha: alright
glisse: ossman: got a pointer where they do that ?
ossman: glisse, look a the function assemble_math_function(). It's called from several places
ossman: e.g. EX2
ossman: glisse, the way I understand things, ALU.Trans can write to all elements at once. So the MOV wouldn't even be needed for distributing the result...
ossman: perhaps there is some restriction I'm overlooking?
zhasha: eosie: what do you think could cause that behavior?
glisse: let me check the doc
ossman: glisse, it says "and [ALU.Trans] can replicate the result across all four elements of a destination vector."
eosie: zhasha: i have no idea
ossman: bottom of page 39
glisse: ossman: alu trans can write to only one chanel
glisse: my guess is that gl opcode require result to be in all chanel
ossman: I see
ossman: yes, it does
glisse: would need to check the arb spec to be sure
ossman: it does, I've checked :)
eosie: zhasha: do you which piece of code sets the number of pixels a GPU computes?
glisse: note that this could be optimized out with a proper compiler
eosie: zhasha: do you know which...
ossman: glisse, so I'd like to file a bug report against the docs then for confusing wording :)
glisse: ossman: can you point to the page number and pdf which was confusing you ?
ossman: glisse, bottom of page 39, r600isa.pdf
ossman: the image on page 48 is also not completely in sync with what the text says. As long as you're taking notes ;)
glisse: ossman: r600 seems to be able to do that
ossman: but not r700?
zhasha: eosie: I'd assume you're talking about the texture pitch?
ootput: hi guys. any of you using x11-overlay ebuilds for gentoo? Would it be okay if I used the -9999 packages for mesa, libdrm and xf86-driver-ati, but with vanilla-sources kernel?
ootput: will I be missing out on much by not using the next-drm tree?
adamk_: ootput, Depends on the video card you haven.
adamk_: have, even.
ootput: (also, would zen-sources be an option?)
eosie: zhasha: whatever, but the pitch is the width, where do we set the height?
ootput: adamk_: hey. It's an 48xx series card
zhasha: eosie: for the sampler?
eosie: eosie: in emit_fb_state
adamk_: ootput, Then you probably need drm-next. The 3D support for that GPU is quite new.
zhasha: hmm... that is a good question
ootput: adamk_: do you use gentoo as well?
adamk_: ootput, Nope.
ootput: I heard about zen-sources (git) pulling from drm-next. Is that true?
ootput: oh okay
adamk_: No idea.
chithead: zen-sources pulls from everywhere, including nouveau, drm-next, reiser4 and whatnot
ootput: oh cool
ossman: glisse, I have another question for you, if you have time. Does mesa always swizzle scalar input so that it is in .x?
zhasha: eosie: but do we actually need to set the height?
eosie: zhasha: no idea, maybe we need to just allocate enough pixel tiles for shaders
eosie: zhasha: just guessing
zhasha: eosie: I'm assuming fb config works as it's technically what allows us to render anything
zhasha: according to trace, the st binds a set of shaders, gets the surface, binds the fb state and sampler, then renders a textured quad
zhasha: somewhere in there, it goes haywire
glisse: ossman: i think it's a requirement of arb shader
ossman: glisse, scalars seems to be a special case in ARB programs. from what I can tell, you always need to explicitly specify which element is to be used
ossman: so any implicit "x is the scalar" seems to be a mesa thing
glisse: ossman: maybe you can test to replicate all output on r700
glisse: i think it should work
glisse: oh now in fact it can't
ossman: you're not exactly helping in getting rid of my confusion here :)
glisse: the opcode instruction doesn't have any field to tell you to replicate write
zhasha: eosie: could this have any relation to the bug that causes misrenderings like with progs/tests/texobj ?
glisse: i guess we need to ask AMD to clarify this
eosie: zhasha: possibly
ossman: glisse, it's probably just a poor choice of words and what was meant was that ALU.Trans can write to _any_ element, not _all_
glisse: yeah likely that
glisse: at least according to opcode format it can't replicate
ossman: glisse, hang on... you sure? the write mask is four bits
ossman: glisse, hmm... I overlooked DST_ELEM
ossman: those two regs seem a bit redundant though
glisse: which 2 regs ?
ossman: glisse, DST_ELEM is two bits and says which elem to write to, and WRITE_MASK is four bits (one for each channel I'd assume)
ossman: glisse, NM, I'm not reading things properly
ossman: it was bit 4, not 4 bits :)
wirry: what version of xorg-server do i need for 3d on r7xx?
chithead: wirry: xorg-server version is mostly irrelevant
chithead: wirry: you need kernel 2.6.32-rc1 (or drm-next) and mesa from git master
wirry: ok
logari81: I ve tried to build drm-modules according to
logari81: https://launchpad.net/~xorg-edgers/+archive/radeon
logari81: on 2.6.32-rc1, and it fails. The corresponding log can be found here
logari81: http://pastebin.ca/1651526
logari81: any tip?
biotube: use the modules included with the kernel
logari81: biotube: with 2.6.32-rc1 and mesa.. etc. from xorg-edgers on karmic, Xserver doesn't start at all
osiris_: MostAwesomeDude: I think flush is missing in r300_set_sampler_textures. let's say we have following operations: glBindTexture(tex0), glBegin/glEnd, glBindTexture(tex1), glBegin/glEnd, glFlush (that's the case for mesa/progs/tests/texobj). I'm not sure why but the object drawn with first glBegin/glEnd operation is using second texture, and the second object is lacking of any textures. adding a flush in the r300_set_sampler_textures fixes the
osiris_: problem
twnqx: didn't someone recently say the "interlaced modes recognized with half the true height" bug is gone?
twnqx: well, it kind of is.
twnqx: it now detects no modes at all...
agd5f: twnqx: it's an xserver edid parsing problem
twnqx: oh well
twnqx: DisplayPort-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
twnqx: 1920x1080_24.00 23.9*
twnqx: at least one can be suggestive ;)
wirry: im stuck with a little problem here (gentoo 2.6.32-rc5-git5, hd4850) when using kms...it works fine, but with kms enabled i cant start X - the screen gets blank and i have to reset the machine...with kms disabled X starts and 3d works (only tried glxgears so far)
twnqx: same here :]
twnqx: except 2.6.31.5-00228-g0ac9a1d and Mobility Radeon HD 3650
agd5f: try drm-next. I'm not sure linus has the latest fixes from airlied yet: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-next
twnqx: well, X starts, but eats 100% after even just issueing xdpyinfo
agd5f: twnqx: 2.6.31 doesn't support kms on r6xx+. you need 2.6.32 or airlied's drm-next
twnqx: that's 2.6.31 + git as per link in topic
twnqx: and kms works, given that i have 100+ lines in textmode :]
agd5f: twnqx: di you build the ddx with kms support?
twnqx: the ddx? :X
chithead: xf86-video-ati, needs to be built after libdrm with --enable-radeon-experimental-api
agd5f: twnqx: xf86-video-ati
twnqx: it switches the mode on, and entrance even gets a picture on the screen before it happens
twnqx: hm, it's build with --enable-dri --enable-kms --enable-shave
agd5f: twnqx: check your xorg log
twnqx: mh
twnqx: i need a second comp to log in and kill X then :P
agd5f: or just check you log after you reboot
wirry: after reboot the log is empty i guess
agd5f: don't start X when you reboot
twnqx: not if i disable automatic X startup
wirry: i had the same problem here, but luckily i have a second pc
twnqx: also, i don't have to reboot, kill -9 X works
soreau: The last log is sometimes saved with .old appended
twnqx: rmmod radeon; modprobe radeon modeset=1 will do, right?
chithead: if I mess with X, I put "chvt 1" in a cron job first
wirry: nah...both were empty after reboot...dunno why
twnqx: when exactly do i need to rebuild libdrm?
chithead: just make sure it has --enable-radeon-experimental-api enabled. and ddx, x server and mesa should be built against the same libdrm version
dmb: do they even sell any displayport monitors?
twnqx: sure, but i just use a displayport->hdmi adaptor
dmb: is displayport supposed to be for computer monitors or tvs?
twnqx: both i guess
chithead: displayport is designed to replace all other digital connectors
dmb: chithead, video connectors?
twnqx: hdmi, DVI
chithead: hdmi, dvi, lvds
twnqx: is lvds even a connector?
dmb: oh
dmb: yes
dmb: it is
twnqx: i doubt they will use a full DP connector inside a laptop :P
dmb: laptops
obiwane: hello
chithead: they won't solder the cable to the laptop mobo/display either, so some kind of connector will be used
twnqx: yeah, but not DP, too big & too expensive
obiwane: i have a problem with my radeon 9200
twnqx: internal connectors also don't need the robustness
obiwane: i need help
chithead: obiwane: nobody can help you until you say what the problem is
twnqx: anyway, my earlier questions stands: rmmod radeon; modprobe radeon modeset=1 will do, right?
obiwane: i use ubuntu 9.10
obiwane: chithead: ok
chithead: twnqx: if radeon drm is built as module, yes
obiwane: when i play openarena the game lag a lot
twnqx: suspend (more precisely, resume) fails if i don't :X
twnqx: so, brb
boris64: Hey folks, does anybody else get those errors in dmesg (->http://pastebin.ca/1651663) whith the newest kernel/ddx/mesa git stuff?
obiwane: the game lag also in the menu
chithead: obiwane: "check glxinfo | grep -i render" if you use hardware or software rendering
obiwane: the rendering is active and i have 600 with glxgears
chithead: boris64: maybe you are missing the radeon firmware, see the channel topic
chithead: obiwane: glxgears fps is not meaningful in any way
obiwane: direct rendering: Yes
obiwane: OpenGL renderer string: Software Rasterizer
chithead: so you are using software rendering for opengl
boris64: chithead: firmware is built in the kernel, render and 3d seems to work ok with my r770
obiwane: yes
chithead: boris64: hm, no idea then
chithead: obiwane: verify that your user has enough privileges to access /dev/dri/* (may need to be in video group for that)
chithead: obiwane: also check Xorg.0.log for dri related errors
obiwane: ok
obiwane: groups
obiwane: lucas adm dialout cdrom plugdev lpadmin admin sambashare
obiwane: not video
chithead: "gpasswd -a user group" and relogin
obiwane: cool
chithead: may or may not fix the problem
obiwane: ok
obiwane: not fixed
chithead: still software rasterizer in glxinfo?
obiwane: rasteried? what mean?
obiwane: yes
obiwane: direct rendering: Yes
obiwane: OpenGL renderer string: Software Rasterizer
obiwane: software Rasterizer is good or not?
chithead: software rasterizer means no hardware 3d acceleration
obiwane: and there is something strange because in ubuntu 8.04 i have more than 1000 fps with glxgears and now i have only 600
obiwane: oh
obiwane: sheet
obiwane: why?
obiwane: :)
obiwane: how can i do that
soreau: obiwane: Can you pastebin your X log?
obiwane: ok
obiwane: !pastebin
obiwane: where is the X log file please?
chithead: [17:36:20] obiwane: glxgears fps is not meaningful in any way
obiwane: ok
chithead: /var/log/Xorg.0.log (you can use the wgetpaste application to paste from command line)
obiwane: wgetpaste dont exist
chithead: install it
obiwane: sudo apt-get install wgetpaste
obiwane: but dont find
twnqx: right.
twnqx: so i *had* to reboot....
chithead: obiwane: if curl is installed, run "curl -f file=@/path/to/file nopaste.com/a"
twnqx: because of that other weird bug.
chithead: oops "curl -F file=@/path/to/file nopaste.com/a"
soreau: obiwane: Is this an upgrade from Jaunty?
obiwane: no
twnqx: which is there, was in the other radeon, and is also in radeonhd...
obiwane: what is curl?
obiwane: i need to install it
wirry: (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.31.0 <-- this is the line i get with kms off and this is the one with kms on (where x fails to start) (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
wirry: [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
obiwane: chithead: can i post in pastebin.com?
chithead: wirry: this means your xf86-video-ati is not built with kms support (probably you use the 6.12.4 release or older)
chithead: obiwane: any pastebin which you get to work
wirry: ok...and how do i change it?
chithead: wirry: you need to build xf86-video-ati from git
twnqx: http://digadd.de/err.mkv - did anyone see something like that before? happens with all radeons i have had so far
obiwane: .http://pastebin.com/d1531f61a
spreeuw: twnqx: whats repeated there?
twnqx: repeated?
twnqx: the screen slowly fades to white
twnqx: after X is terminated
obiwane: chithead: do you see something?
soreau: obiwane: The problem is (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI.
spreeuw: oh the white change is only noticable now you mention it
spreeuw: havent had that
obiwane: ok
obiwane: so what can i do?
spreeuw: but there seems to be a big rendert error bar to the left
soreau: Unfortunately, I don't know what would cause that assuming ubuntu has set everything up right..
twnqx: yeah, forget about that
twnqx: X didn't start any more after the first crash
chithead: obiwane: line 809+ in your pastebin, seems the agp module is not loaded
obiwane: ok
obiwane: and with modprobe agp?
soreau: obiwane: I think it's called radeon_agp
obiwane: ok
obiwane: so i try?
soreau: and I also think you need to load it before radeon gets loaded
obiwane: it called agppart
soreau: You can look at the output of 'lsmod|grep radeon' to see what is loaded
soreau: agpgart sounds good
obiwane: ok
obiwane: ok
obiwane: agpgart is loaded now
obiwane: i log out?
chithead: possibly you need chipset specific agp support too
wirry: yeah - working kms and 3d :D
obiwane: so what i can do now?
obiwane: its possible to repair?
obiwane: i try to log out?
twnqx: http://nopaste.info/5e84ddee59.html <- my Xorg.0.log where X crashes
twnqx: or rather, ends responding and consumes 100% cpu
Nightwulf: hi all
twnqx: (with KMS
soreau: obiwane: Restarting X wont reload the radeon module afaik
chithead: stop x, unload radeon module, load agp (if applicable agp_intel, agp_via, ... too) modules
soreau: twnqx: Can you try without aiglx?
obiwane: chithead: i need to load intel_agp?
chithead: if lspci says you have an intel agp bridge
obiwane: only nvidia
obiwane: ok
obiwane: i try
obiwane: hahahhahahahahahahaha
obiwane: its ok now
obiwane: :)
obiwane: it work good
obiwane: :)
chithead: obiwane: you may want to report a bug on launchpad giving your lspci and Xorg.0.log and telling them which module you had to load
obiwane: ok
obiwane: and how to do it automaticaly at boot?
chithead: obiwane: /etc/modprobe.d
obiwane: chithead: there is only blacklist in this folder
obiwane: maybe /etc/modules?
chithead: could also be
obiwane: ok
obiwane: thanks a lot
obiwane: i must go
obiwane: bye
osiris_: MostAwesomeDude: why have you removed the surface_(fill|copy) functions?
twnqx: so, without aiglx but with KMS i get a full hard crash (black screen, no keyboard, no network, no sysrequest, nothing)
wirry: hmm...with kms off glxgears gives 2500fps...with kms on only 1500 - is this normal?
twnqx: after two seconds of running, instead a 100% cpu load as before :P
twnqx: => KMS = evil
chithead: glxgears is not a benchmark
twnqx: has 1500 glxgears without KMS
wirry: i know...but i havnt installed anything benchable yet ;)
soreau: twnqx: You want more fps in glxgears? Resize the window to the smallest possible size :P
twnqx: nah
wirry: is just checked if it works
twnqx: i don't care about 3d
twnqx: ijust need opengl for an app that displays its video exclusively in gl :X
twnqx: and crashes X
soreau: twnqx: Were you able to get any logs from the hard crash?
twnqx: no
twnqx: log wasn't written to disk completely
twnqx: crashed before the buffers were flushed
twnqx: hm, should try mounting sync, maybe that helps
twnqx: but actually i doubt it's different from the one i posted, except for no aiglx
twnqx: tries
twnqx: k
twnqx: so entrance/X do not start with sync-mounted X...
twnqx: root filesystem*
twnqx: also, this time it didn't crash hard
spreeuw: xserver git + mesa r600 git is shitty right now
twnqx: http://pastebin.com/d5762d9d6
spreeuw: glxgears hardlocks
spreeuw: and ioquake has no gamma control
spreeuw: had some spontaneous reboots oto
twnqx: xserver 1.7.1 + mesa r600 works (without kms)
spreeuw: uplon app launch
spreeuw: it "works" yes
twnqx: crashes all over with kms, though
spreeuw: I use dri 1
spreeuw: atleast I think I am
spreeuw: GL_RENDERER = "Mesa DRI R600 (RV620 95C5) 20090101 x86/MMX+/3DNow!+/SSE2 TCL"
twnqx: OpenGL renderer string: Mesa DRI R600 (RV635 9591) 20090101 TCL
twnqx: mesa from two days ago
spreeuw: what kernel?
spreeuw: I use drm and radeon from 32 rc5
twnqx: 2.6.31.5-00228-g0ac9a1d (2.6.31.y + kms from 2 days back)
twnqx: wants mmx/sse in mesa, too
spreeuw: its autodetected
spreeuw: I didnt specify any flags
twnqx: :X
spreeuw: except install suid
twnqx: hm
wirry: ok, world of goo runs smoothly :)
twnqx: # Deactivate assembly code for pic build
twnqx: myconf="${myconf} $(use_enable !pic asm)"
twnqx: hmmmmmmm
twnqx: no, it compiles with --enable-asm :\
twnqx: spreeuw: do you use 32 or 64bit?
spreeuw: 32
spreeuw: gonna rebuild this box 64 when theres a stable 64LFS book
osiris_: MostAwesomeDude: I think all geometry corruptions should be fixed now in my r300g-vbo branch. glxgears, bounce, engine, vao_demo and others are fixed now
twnqx: is there a difference between 32 and 64bit in that regards? oO
spreeuw: possibly
spreeuw: twnqx: you're on intel right?
twnqx: yeah
twnqx: funny, my mesa doesn't have that "experimental radeon" option
twnqx: oh wait...
Nightwulf: hmm...seems the git server on kernel.org is down or overloaded
Nightwulf: getting "fatal: The remote end hung up unexpectedly" all the time when trying to checkout stable kernel
Nightwulf: ls
Nightwulf: ups..sorry..wrong window :)
Maestr123: IRQ's not enabled, falling back to busy waits: 2 0
Maestr123: 13737 frames in 5.0 seconds = 2747.346 FPS
Maestr123: 14468 frames in 5.0 seconds = 2893.452 FPS
Maestr123: what is it?
Maestr123: first line
Maestr123: bad?
honk: normal
stikonas: it is not implemented yet
Maestr123: thanks =)
MostAwesomeDude: osiris_: Looks interesting.
MostAwesomeDude: I wanna cherry-pick "split constant buffer and shader emission" since it's been on my list for a while, but it breaks glxgears.
MostAwesomeDude: "don't hang GPU" already got picked.
MostAwesomeDude: I'm not doing "bring back surface_fill and surface_copy" without a really good reason, or, preferably, a blitter version.
MostAwesomeDude: "add missing flush" doesn't seem to have a good justification.
MostAwesomeDude: Oh, I see. "fix geometry corruptions" should be mushed into "split constant buffer and shader emission", right?
MostAwesomeDude: Nope, still doesn't work here.
osiris_: MostAwesomeDude: better leave "fix geometry corruptions" as seperate
osiris_: MostAwesomeDude: isn't 500fps+ on glxgears good reason for surface functions?
Kuaera: Hello; I was wondering if random X.org crashes on a Radeon X1950XTX [r580] were still a reported 'problem' of the driver
MostAwesomeDude: osiris_: We should be doing it in mesa st, not in the pipe.
osiris_: MostAwesomeDude: "add missing flush" - yeah, I think it just workarounds a problem (it's possible that TX_INVALIDTAGS emit is missing somewhere)
osiris_: MostAwesomeDude: what doesn't work?
osiris_: MostAwesomeDude: what should be done in mesa st?
MostAwesomeDude: osiris_: If surface_fill is missing, then it should draw tris or point itself.
MostAwesomeDude: Also util_clear should learn to do this.
MostAwesomeDude: osiris_: If you need to flush texture cache, there's a func in r300_emit for it.
MostAwesomeDude: osiris_: My glxgears has corruption after "split constant buffer and shader emission," is this fixed somewhere?
osiris_: MostAwesomeDude: glxgears is also corrupted also without my patches (just see the back of the gears), and these patches + VBO makes it work 100%
MostAwesomeDude: osiris_: Wait, it's corrupted for you on master?
osiris_: MostAwesomeDude: yes, but to see it you have to rotate the gears
MostAwesomeDude: Hm.
soreau: Does any of this fix resizing of the gears window issue?
osiris_: soreau: I wasn't aware of this issue so probably not
Nightwulf: having 3D+KMS on my HD4890 now...runs very fine. A big thank you to all developers and helpers!
wirry: hehe, me 2
wirry: cant wait to have opengl2.0
MostAwesomeDude: osiris_: Well, I do want to pick the split constant emit and flush. Those *are* correct and good.
soreau: I dont know if it only happens on rv3xx or what but here when I resize the gears window using r300g, the window resizes but the contents are not resized correctly
MostAwesomeDude: I'm not grabbing surface_fill and surface_copy. As discussed before, having 3D versions of them is crufty and going to suck in the long run.
Nightwulf: even GoogleEarth runs fine....WOW
osiris_: MostAwesomeDude: agreed
MostAwesomeDude: osiris_: Is there a reason for splitting r300_render into two files? I was hoping to keep all the render functions in one file...
osiris_: MostAwesomeDude: r300_render and r300_vbo?
MostAwesomeDude: osiris_: Yeah.
MostAwesomeDude: I mean, the VBO setup functions are still part of the render pipeline, and we should be sharing most of that code between HW and SW TCL setup anyway.
osiris_: MostAwesomeDude: I wanted to keep my current work seperated, but it's still WIP and I'm open to any suggestions for naming and placement of functions and params for r300_context
MostAwesomeDude: osiris_: Well, I don't want to pick anything broken into master, so I was going to bring the VBO stuff in all at once. :3
MostAwesomeDude: That's why I've been slowly bringing in little bits and pieces.
osiris_: MostAwesomeDude: I'm ok with it. VBO patch is certainly not ready to be merged yet
marvin24: hi, I'm tried gallium on rs690 and glxgears segfaults in r300_vs_tab_routes
marvin24: is this a know issue?
MostAwesomeDude: marvin24: It is now. :3
MostAwesomeDude: SW TCL path doesn't get much love, so RS690's apt to not quite work right.
marvin24: MostAwesomeDude: ok - I even had problems with this in the classic driver
MostAwesomeDude: marvin24: Oh, really? Classic should work well with RS690.
marvin24: MostAwesomeDude: maybe it went away in the mean time (error had something to do with z-buffer not reserved)
osiris_: marvin24: what mesa version did you try?
marvin24: current
marvin24: and this bug for classic: https://bugs.freedesktop.org/show_bug.cgi?id=23532
marvin24: I can post a backtrace for the gallium problem
MostAwesomeDude: marvin24: Feel free to file a bug for r300g; it might be a while before I can really get to it, but I might fix it during a few other things I'm working on.
marvin24: ok - bt is at http://pastebin.com/m5c70e989
marvin24: but I'll wait for the bug report until it gets more stable
MostAwesomeDude: Oh, I don't mind bug reports. :3
MostAwesomeDude: Just understand that I can't promise it'll get fixed quickly.
osiris_: marvin24: the #23532 isn't specific to rs690
marvin24: osiris_: could also be a kms problem
MostAwesomeDude: Well, it's a kernel_mm-related problem.
marvin24: 1,
marvin24: ⁷
marvin24: ups
marvin24: keyboard hit ground
MostAwesomeDude: osiris_: Your VBO branch appears to work, now we've just got to figure out how to bring it into master. Good work. :3
osiris_: MostAwesomeDude: I need to make it work with swtcl, then some cleanup
wirry: with some games/apps i get the error: "unable to set video mode: x11 driver not configured with opengl" - how to fix this?
MostAwesomeDude: osiris_: Yep.
MostAwesomeDude: I'll commit a few more bits of cleanup I've got, and I'll try to see if I can pull more bits of your code out into master cleanly.
_moep_: is it possible to use a radeon and a intel card in a laptop and switch if i need a other card?
twnqx: ohh you have one of those, too :]
Zajec: osiris_: your commits look like: "author Maciej Cencora "
Zajec: osiris_: maybe you would like to fix that :)
osiris_: Zajec: oopsie
osiris_: Zajec: how do I do that?
Zajec: git global sth...
Zajec: osiris_:
Zajec: git config --global user.name "Your Name Comes Here"
Zajec: git config --global user.email you@yourdomain.example.com
osiris_: Zajec: thanks
Zajec: osiris_: welcome
VitRuss: Hi! I'm getting (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/xorg/modules/dri/r600_dri.so: undefined symbol: _mesa_texformat_luminance_float16)
VitRuss: with latest mesa from git
Zajec: hm, make clean && make maybe? but wait for confirmation :)
VitRuss: Zajec: I'm made by PKGBUILD
VitRuss: Zajec: solved. Updated pkgbuilds and all is working now.
airlied: glisse: thats not postponing
airlied: you are hitting a different bug
airlied: glisse: not sure how you think the AGP fix I sent isn't an actual fix for a real stupid assumption
airlied: blitting to cached memory is always wrong
airlied: like I'm sure we can blame AGP hw for lots of things, but we should start by blaming our code ;-)
airlied: F11 on AGP machines didn't show any corruptions from memory
mattst88: airlied: if that patch for _only_ AGP, or is it possible that it could fix the KMS font corruption I see on alpha with PCI?
airlied: mattst88: should onky matter on agp
airlied: we have other bugs i suspect, font corruption is just a symptom
Nightwulf: airlied: just as a feedback: I'm using radon with your latest DRM code on an 2.6.31.5 kernel and mesa 7.6 for some hours with my HD4890 now...all I tried since then works like a charm...thanks a lot to you and the other devs
Nightwulf: airlied: tested apps so far: KDE 4.3 w/composite effects, GoogleEarth, glxgears, Neverball, tuxracer -> all without a single problem
twnqx: Nightwulf: with KMS or without?
Nightwulf: with
twnqx: don't fix the 4xxx before the 3xxx *grml*
soreau: twnqx: Arent you using 64bit ?
twnqx: i am.
Nightwulf: twnqx: to be honest...i never tried it without since it works so good with ;-)
agd5f: twnqx: all my r6xx and r7xx cards work fine with kms
twnqx: my 635 doesn't, at all
agd5f: twnqx: intel motherboard?
twnqx: opens his laptop
twnqx: well, chipset and such is, yes
agd5f: twnqx: there's apparenty some issues with that on some systems
twnqx: rrrrr
twnqx: why are it always *my* setups that break
twnqx: oh hm, need to recheck where i sent the fix for pam_mount
twnqx: and whether my udev fix is in or not
airlied: twnqx: btw DP has eDP for internal use
airlied: gets to play with intel sdv + rv635 today.
spreeuw: does 2.6.31.5 have appropriate drm and radeon modules?
airlied: though I think darktama w500 is also screwed
Nightwulf: spreeuw: no, you need the git tree from agd5f
Nightwulf: spreeuw: look at the radeonBuildHowto, it says really all :)
agd5f: spreeuw: not for r6xx+ 3D
twnqx: spreeuw: with the git patches, yes
spreeuw: ok running 32 rc5 which does
spreeuw: considered a downgrade because of some problems I'm experiencing
twnqx: stock 2.6.31.5 doesn't
twnqx: wonders if he should consider replacing his obsolete, 2 days old kernel/libdrm/mesa/xf86-video-ati with something more current
scandium: hello, might be strange question, but let's go :P Should open source radeon 3d support work on Macs with the mobility radeon 4k series? or will there be random bogus behaviour because of some low level initialization stuff (BIOS vs. EFI etc.)?
bonbons: huh: radeon KMS from 2.6.31 thinks my DVI connected display is connected to a HDMI port...
bonbons: 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS690 [Radeon X1200 Series] [1002:791e]
bonbons: dmesg reports 3 connectors, VGA, DVI-D and HDMI, but as connectors I see VGA and DVI-I
bonbons: (display does not understand signal it gets via DVI, mostly displays black sometimes console, sometimes garbage)
bonbons: not better with airlied's for-linus branch as of today :(
mfwitten: I am using the open-source radeon driver for my Radeon Mobility X600, and it seems that the driver must be incomplete: Sauerbraten runs quite smoothly unless certain textures are in view (IIRC), and Warsow has the same problem---both the `sound rate' and frame wrate drop tremendously; also, in Warsow, the menu buttons are filled with white when when the cursor hovers over them---which is decidedly not correct. Is this a kind of bug ...
mfwitten: ... that will never get fixed, will get fixed in the near future, is too hard to fix?
mfwitten: Basically, I'd just like to know where things stand? Is something that I could look into?
mfwitten: or do I need a diagnostic rig sodered to my laptop's insides?
mfwitten: *soldered
yangman: mfwitten: 3D is handled by mesa. try updating to the latest mesa for a start
chithead: or maybe disabling low impact fallback in driconf helps
mfwitten: yangman: Well, I couldn't find an IRC channel for mesa discussion
mfwitten: yangman: Latest as in git master HEAD?
yangman: mfwitten: discussing it here is fine. :) just pointing out a common misconception about linux graphics
yangman: mfwitten: start with latest release
mfwitten: yangman: Actually, I think I've talked with you before about the linux graphics pipeline(S)
mfwitten: yangman: I'm still confused though.... :-)
mfwitten: The docs suck, in my opinion :-P
mfwitten: yangman: So, I have mesa 7.5.1 installed. Do you mean newer than that?
yangman: well, most devs understand what they need to know. aside from the very basics, it's not crucial that standard users understand the plumbing
yangman: 7.6 is the latest
mfwitten: yangman: But what about the non-standard users? Maybe non-standard users would more easily become helpful devs if there wasn't an air of the occult about the subject
mfwitten: yangman: Is that an official release?
yangman: yes: http://mesa3d.org/relnotes-7.6.html
mfwitten: hmmmmmmmmmmmmmmmmmmmmmmmmm
mfwitten: Arch Linux is usually very on top of such things; I wonder I don't have official packages instaleld
chithead: you don't want to inflict mesa-7.6 on normal users
mfwitten: oh?
yangman: yeah, not recommended, apparently
mfwitten: Ah. They just put it in yesterday
mfwitten: I've got to UPDATE!
mfwitten: Oh pish posh
chithead: arch linux and other distros will probably ship 7.6.1 when it comes out (or heavily patched 7.6)
twnqx: OpenGL version string: 1.5 Mesa 7.7-devel yeah, yeah, 7.6....
mfwitten: http://www.archlinux.org/packages/?sort=&arch=&repo=&q=mesa&last_update=&limit=50
mfwitten: So it's there
mfwitten: I was going to try catalyst, but ATI probably won't update it any time soon, X600 has been deprecated, and I don't care to gravel before them.
MostAwesomeDude: Please don't use fglrx.
MostAwesomeDude: We're the official driver now for your chipset.
mfwitten: Most Awesome
mfwitten: Do you guys have all of the info you need to make the drivers functionally on par with the proprietary drivers? or is such an outcome a long ways off?
bonbons: MostAwsomeDude: any idea why radeon detects my DVI connector as HDMI and probably sends HDMI signal over it?
MostAwesomeDude: bonbons: Nope, sorry.
MostAwesomeDude: mfwitten: It's largely just a manpower issue these days.
chithead: bonbons: how is hdmi signal different from dvi signal?
bonbons: an idea what information I should provide to help getting it fixed?
bonbons: isn't there audio coded somewhere in it (or HDCP)
MostAwesomeDude: agd5f might know, but he's probably taking the day off.
MostAwesomeDude: bonbons: We don't do HDCP. We do support HDMI audio, but the signals don't magically interfere just because you're on DVI instead of HDMI.
mfwitten: MostAwesomeDude: Well, that's good to know; no arbitrary barriers
twnqx: MostAwesomeDude: get audio for displayport, please :(
bonbons: but my DVI display does not get anything useful out of the signal... mostly it displays black sometimes a frame or two of console or something that makes no sense
mfwitten: yangman: ^^^ that's also why it's important to have good docs, so that the non-standard user might gain interest in helping
MostAwesomeDude: twnqx: I haven't touched the DP code, sorry.
twnqx: at least input detection ("connected or not, that is the question") works again
mfwitten: Hmmmmm.... I do believe my hard disk is failing.
yangman: mfwitten: not sure what you're trying to point out
agd5f: bonbons: file a bug and attach your video bios. does non-kms work properly? Also, DVI and HDMI use the same signaling
agd5f: bonbons: what ports does your system actually have?
bonbons: agd5f: I've no X on that box...
bonbons: my system has VGA and DVI (and I guess a component video pin-header)
mfwitten: yangman: Just what MostAwesomeDude said about the main difficulty is now just a matter of man-power
bonbons: radeon sees 4: s-video, vga, dvi-d and hdmi (the enabled output is HDMI - which seems to be routed to DVI connector)
yangman: mfwitten: as someone who fits into the "non-standard user" category, I assure you the lack of documentation is the smallest barrier of entry
agd5f: bonbons: does the hdmi port even show up as connected?
mfwitten: yangman: Then maybe I should just read the code?
yangman: read the code, ask questions
agd5f: I suspect you have one of the boards with an option hdmi addon board. the vendor probably uses the same bios
bonbons: agd5f: yep, it's the only one that reports connected and has edid in sysfs
agd5f: bonbons: ok. might need a quirk then
mfwitten: yangman: Maybe I'll even write the missing docs ;-)
yangman: personally, "lack of documentation" is not in my set of reasons that's preventing me from hacking on the stack these days
bonbons: agd5f: pretty probable that the BIOS has something to do (the BIOS update change-log has multiple messages about video bios! broken/fixed)
MostAwesomeDude: agd5f: Thanks for fixing up the RadeonFeature page; I got frustrated that it didn't fit on my netbook screen and kind of went to town on it. :3
bonbons: agd5f: what's the trick to extract video bios?
agd5f: send me the vbios and lspci -nv
_moep_: hi guys
agd5f: bonbons: (as root) cd /sys/bus/pci/devices/0000\:01\:05.0/; echo 1 > rom; cat rom > /tmp/rs690.rom; echo 0 > rom
bonbons: ok, thank, will submit all of that to bugzilla (freedesktop.org?)
agd5f: bonbons: yes. https://bugs.freedesktop.org
bonbons: agd5f: ok (well other alternative was kernel.org bugzilla)
agd5f: mfwitten: what documentation is missing?
mfwitten: agd5f: An overview of the concepts / data flow that doesn't suck
agd5f: mfwitten: for the hw or mesa?
mfwitten: agd5f: There's a lot of confusion surrounding the linux graphics system, as yangman pointed out, and there probably is no good reason for that.
mfwitten: mesa/drm/dri/xorg
yangman: I'd say people not realizing they have no idea what they're talking about is a pretty good reason :\ too many "power users" spreading false information
mfwitten: dri/dri2/GEM
mfwitten: etc.
mfwitten: 2d vs. 3d
mfwitten: yangman: That's for damn sure.
mfwitten: Well, I've got to restart X now; unfortunately, my IRC session is tied to X running at the moment. Wish me luck and catch you later!
revx: where "power users" means eating more watts than anyone lese :P
revx: else*
revx: speaking of, is there an easy way to force the minimum clocks on my rv770?
agd5f: revx: xf86-video-ati in non-kms mode has options to do that
revx: agd5f: what about when X is not running?
agd5f: revx: not at the moment
bonbons: agd5f: here it is: https://bugs.freedesktop.org/show_bug.cgi?id=24844
bonbons: anything else I should add?
agd5f: bonbons: looks good. I'll take a look
bonbons: adg5f: thanks
logari81: with 2.6.32-rc5 on ubuntu karmic I get the following error:
logari81: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
logari81: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(3).
logari81: btw there is a typo in the error message
logari81: Faild instead "Failed"
mfwitten: Unfortunately, updating to the latest mesa didn't help; the same problems persist
logari81: is there any dependency I should take in account in order to use this kernel?
airlied: logari81: what gpu and did you do anything to trigger it?
airlied: isn't sure if karmic as kms
logari81: airlied: r400 and X doesnt start at all
logari81: KMS enabled as a boot option
logari81: with the stock karmic kernel I have no problem with kms, only suspend doesn't work
airlied: I've some patches to go to linus which might fix it
logari81: thats the reason I would like to test the improvements in 2.6.32
logari81: should I give it a try again when rc6 is out?
stikonas: airlied: suspend on RV730 with KMS is not expected to work yet?
stikonas: with drm-next kernel
airlied: stikonas: it shuold, but I have one card that doesn't seem to always resume in all my r700s
stikonas: I've never managed to resume
cxo: Looks like the feature table lost some weight
cxo: wonders if all the pink blocks could also be made white
Zajec: damn, who deleted that?
Zajec: was that so hard to split page into 2? :/
cxo: pink kinda looks like red, and that kinda makes it look like it has broken support
cxo: which kinda makes the thing look whack
airlied: Zajec: its still in history I assume
Zajec: airlied: yeah, but way of doing that... eh :/
Zajec: don't like it
airlied: you don't think it should hhave been removed at all? or you think you can't bo bothered making an rhd table and maintaining it?
cxo: If radeon > radeonhd ; who cares right?
cxo: I remember seeing HDMI Audio supported in RadeonHD, but i dont get what the video driver has to do with that, I thought the sound chip was just another thing on the pcie bus that alsa would support
yangman: cxo: audio packets needs to be mixed in to the video data stream. the GPU has to do this
cxo: So couldnt you guys just copy and paste the radeonhd code for Audio into radeon, cos that was like the only thing radeonhd had that radeon didnt
airlied: cxo: there is some code to di all properly pending review, for kms
cxo: I dont get how it needs IP review. Isnt all this work based on the non-NDA code?
cxo: s/code/docs
airlied: HDMI audioo wasn't documented
airlied: at least in the original codedrop
yangman: it still isn't documented
Ghworg: How long do these IP reviews typically take?
yangman: depends on what it is, and how much of it
cxo: I remember the initial one took forever, like 6months
cxo: or maybe longer
Ghworg: Yikes
cxo: People Managers are lazy
airlied: well its more it has to pass a lot of busy ppl
airlied: its not managers its engineers
cxo: Back when I was in the field, company policy was any co-worker in your dept could do the IP review for you and sign off, Made things easier to do
airlied: this is a lot more detailed than that, its more of a security review
airlied: IP isn't as big a worry
cxo: Then whats the review for?
airlied: its mainly to avoid releasing any info that might get them sued
airlied: or could provide someone with the info to hack the windows driver copy protection which would get them sued
cxo: Ah ok. So not worrying about your own IP, but more about someone else's
cxo: the windows driver has copy protection? copy what?
airlied: cxo: DRM
cxo: Oh when you watch DVDs? But how come you can still use basic dvdrippers and still copy dvds?
airlied: Blueray
cxo: I didn't realise that was any different.
amarks: i've had 2 lockups this morning, where the screen goes blank (except the cursor), they keyboard capslock+scroll lock are on, and the system is frozen, can't even ping it
biotube_: cxo: the drm scheme is stricter
cxo: What has the video card have anything to do with ripping movies
biotube_: cxo: the video's required to be encrypted up to the monitor to prevent siphoning
chithead: the uvd will contain video data at some point
cxo: biotube_, so you cant rip blurays?
Ghworg: cxo: The bluray needs to have an encrypted path between the player and the monitor, so the gpu needs encryption support
amarks: what causes caps+scroll lock to come on in a freeze
biotube_: cxo: you can, but you've got to crack the disc directly
airlied: cxo: its not to stop you ripping things by other means
chithead: kernel panic maybe
cxo: but can't you just dump the output from the player?
airlied: its to stop you ripping them using AMD hardware
Ghworg: cxo: Doesn't stop pirates of course since rippers can still do everything in software
cxo: yeah, so I dont get what DRM is meant to be protecting
amarks: chithead: don't they blink on and off?
airlied: cxo: no-one does, but it doesn't stop you getting sued
biotube_: cxo: to an extent, it's to let them sue you(DMCA and all)
airlied: or even worse than sued, stopped from shipping cards in the Windows market
chithead: for dvds, the css "protection" was used to enforce the region coding scheme
cxo: So DRM basically just stops you from copy and pasting the video files onto your PC?
biotube_: yep
cxo: There aren't many bluray ripping software on Linux. Well at least not nice packaged up programs for n00b00n2s to install
cxo: But there seems to be tons for Windows
airlied: Zajec: ping
cxo: So all bluray movie discs are encrypted?
biotube: all dvds are
biotube: the encryption's just orders of magnitude stronger
biotube: (on blurays)
cxo: So it would take a generic intel cpu ages to "decrypt" while a gpu could do it much quicker but must use DRM equipped proprietary software?
Ghworg: There are a few DVDs that aren't encrypted, I have a couple. Don't know if any blurays are unencrypted
happycube: CSS is more effective than rot13, which if the adobe ebook thing's to be believed is the mininum encryption standard for the DMCA
happycube: of course, it's almost completely useless, along with 40-bit WEP
biotube: cxo: IIRC, it's encrypted up to the monitor if you want 1080p goodness
happycube: it's decrypted and reencrypted
happycube: HDCP is another crappy encryption... it was designed by n00bs to fit into 10k gates
cxo: But its just a file. Why does it have to be viewed to be copied/decrypted
Zajec: airlied: poing
Zajec: poing... newer pong :)
Ghworg: cxo: It doesn't you are right, it just can't be decrypted in realtime by typical cpus so it needs to be ripped
happycube: there are actually some tv's with hdmi switches inside that decrypt hdcp... someone figured out how to solder another hdmi plug to get unencrypted (and rippable) hdmi. (are there any hdmi cards with free drivers?)
airlied: Zajec: so that ring bug with RPTR going above ring size, you make any sense out of it yet?
happycube: most typical cpu's can barely decode the h.264 - decryption at the same time's just a lil too much
dmb_: IMO, it shouldn't be encrypted in the first place
dmb_: what ever happened to fair use?
dmb_: you should be allowed to copy it for youself
Zajec: airlied: not yet, i first fixed general bug in ring info in debugfs
dmb_: you paid for it
happycube: RIAA/MPAA paid for that
Zajec: airlied: http://bugs.freedesktop.org/show_bug.cgi?id=24837
biotube: dmb_: welcome to tthe wonderful world of influence peddling
Zajec: airlied: i have some suspictions, will dig into that today/tomorrow probably
cxo: Ghworg, back when I was in highschool, it took my about 3 days for my PC to rip a single DVD
Zajec: airlied: i think we start writing to beginning on ring too soon leaving some untouched place and the end of ring
happycube: that must've been an early rip program
Zajec: airlied: not sure why this could happen
Zajec: airlied: but then end of ring could contains garbages making GPU crazy like reading over ring
cxo: reads DRM on wikipedia
cxo: mplayer can play blurays. is it using the cpu or the gpu?
cxo: to decrypt
airlied: Zajec: I might have a look today, we are seeing wierd hangs on certain gpu/chipset combos
airlied: and I need to start with something ;-)
cxo: my Asus A8N-Sli and HD4870 never went together. fglrx never ever worked
cxo: Had something to do with IRQs, but i forgot what
Ghworg: cxo: As far as I know mplayer can't decrypt, it can just play the decrypted video. i.e. it has the right codecs
Zajec: airlied: sure, try, would be nice to have that solved :)_
zhasha: eosie: ping?
cxo: Ghworg, so if i stick in a bluray into my pc right now, i coudlnt watchi it in realtime? ie. i'd have to rip it first?
Ghworg: cxo: That is my understanding yes
cxo: Why cant they just use one of the million keys available and play the movie?
cxo: Or is that unethical somehow
Ghworg: Writing software that decrypts bluray without a license is illegal in many jurisdictions
cxo: My understanding is, if you 1) Have the key, you can decrypt on the fly and watch it or 2) If you dont have the key, you need to decrypt in another way which takes much longer and thus prohibits realtime playback
cxo: so once all this openCL mumbo jumbo is in the works, could the slower non-licensed decryption process be accelerated to realtime speed?
cxo: Looks like there is a library in the works to decrypt on the fly, http://forum.doom9.org/showthread.php?p=1332018
cxo: Using Fglrx can you watch blurays?
cxo: (on the fly)
airlied: Zajec: ping again
airlied: gym
Zajec: airlied: still here :)
airlied: Zajec: hmm I thought I saw something but I might be wrong
Zajec: say anyway :)
airlied: needs ro read drm_order()
airlied: but I'm not sure the bufsz calc in cp_resume is correct
airlied: I need to find agd5f or bridgman to confirm though
airlied: silly ATI changing how its worked for years.
airlied: Zajec: you could try subtacting one from rb_bufsz
airlied: to see if it reproduces
Zajec: airlied: slowly... try to understand what you wrote ;)
Zajec: not idea what is drm_order
Zajec: cp_resume... do I ever hit that? resuming cp?
Zajec: i don't do suspending
Zajec: so cp should be working without suspending, right?
eosie: zhasha: pong
zhasha: eosie: you seem to have fixed texobj. anyway, I just got ridiculously lucky with mipmap rendering. Turns out it was just a huge coincidence so nevermind :/
eosie: zhasha: me? I don't understand, texobj doesn't work for me
zhasha: I'm assuming it was your patches as MADs patched didn't really do much
zhasha: eosie: http://imagebin.org/70094
eosie: zhasha: no, i haven't sent any patched today or yesterday
eosie: *patches
zhasha: ah. I just skimmed the list. It wasn't you after all. Try pulling
zhasha: it's pretty cool
eosie: ok
Zajec: airlied: for me this bug is strongly related to the end of ring... not sure how buffer's size could affect anything
airlied: Zajec: buf sz is the ring size
airlied: good point on cp_resume need to fidn the other place we write the value
airlied: ah no cp_resume is called in normal startup as well
airlied: executes bridgman or agd5f dance
happycube: there's an off-by-one in r300g's r500_emit_fs_constant_buffer - BEGIN_CS is one short
happycube: and src/redbook/planet now has a totally different bug - it only draws one circle
meoblast001: hi
meoblast001: my friend has an r700 card and currently uses the binary drivers (which he hates)
meoblast001: i wanted to know if there are any estimates for when radeon will be stable on r700s
happycube: r300g's only drawing the first part of a sequence, so to speak...
happycube: R300_NEW_VERTEX_SHADER_CONSTANTS is kicking it, so there's something that's not being done along the way
happycube: http://pastebin.com/m75bfd409 - rough patches to look at... makes a lot of redbook samples and etracer's menu screen work properly...
cxo: PuffTheMagic, a dragon by any chance?
wirry: :D
cxo: Puff, the magic dragon, lived by the sea...
amarsh04: I never saw PPM perform that, but did see Paul Stookey perform it solo
cxo: I liked the Kingston Trio version
amarsh04: I haven't heard that version
amarsh04: back in a few, restarting