spstarr_ebook: agd5f / airlied: when do you anticipate the APIs being frozen/stable?
spstarr_ebook: 60%? 80%?
MostAwesomeDude: spstarr_ebook: Which API?
spstarr_ebook: DRM
airlied: not sure how much its changed
spstarr_ebook: since i cannot current fidget this into Fedora 11 at present
MostAwesomeDude: KMS and GEM are solid.
airlied: I assume when 3D works
spstarr_ebook: r6xx is still only for .28
MostAwesomeDude: CS probably is gonna stay for the most part; I can't think of any reason to change that (but I'm sure somebody else will!)
spstarr_ebook: I am so itching to test but i failed 2 days ago :/
spstarr_ebook: I am not sure what changes are needed for the r6xx drm bits to work on .29/30/31
Nightwulf|work: hi all
ssieb: airlied: sorry, I had gone away by the time you responded
ssieb: airlied: the message (radeon_common.c:1008: radeon_validate_bo: Assertion `radeon->state.validated_bo_count < 32' failed.) was caused by a game
ssieb: it's a car racing game and certain levels cause that message and the game crashes. it doesn't happen with KMS
MostAwesomeDude: Which game?
ssieb: trophy
glisse: ssieb: f11 ?
alpha_one_x86: Hello, I seam have graphic card not supported and repertoried, how can you help you (with dump, lspic, ...) for support it?
chithead: lspci -nn
alpha_one_x86: http://pastebin.com/m33ed213b
alpha_one_x86: and after : update-pciids
alpha_one_x86: That's help you?
chithead: alpha_one_x86: that card is supported by latest git
alpha_one_x86: No, with git drivers + git kernel + git xorg server my card is not supported
chithead: what does Xorg.0.log say
airlied: been in DDX since dec 18th 2008
alpha_one_x86: Sorry, but I have remove this file and reinstall all, but I have send url of pastebin the last day in this channel, where have the archive of the last day?
chithead: well what error do you get if you start X on that computer now
alpha_one_x86: I use the vga mode with older xorg, it work
alpha_one_x86: (for now)
nanonyme: Hmm, he didn't want help after all?
suokko1: :(
suokko1: :(
suokko1: radeontool regmatch "VPT*" did hang my system :(
EruditeHermit: nha: hey
nha: EruditeHermit: greetings
EruditeHermit: nha: how is the rewrite of the shaders going?
EruditeHermit: i thought you were meant to be on holiday
nha: pretty much finished
nha: my plane leaves in a few hours
nha: note that rewrite means: still only supporting ARB_v/f_p
nha: but that part is finished, except there are probably still bugs in how it's hooked up to the Gallium driver
taiu: nha, what depth/stencil test you had problems another day?
nha: taiu: the problem I had was related to *depth textures*, not depth/stencil test
EruditeHermit: nha: where you off to?
nha: Iceland
EruditeHermit: nice
taiu: nha: can you try if selecting W conponent helps in SetDepthTexMode
taiu: e.g R300_EASY_TX_FORMAT(W ,W ,W , ONE, X24_Y8)
nha: I did, it didn't
nha: note that this used to work, but what's messed up is that for some reason we switched from z24_s8 to s8_z24
nha: no idea if that's even correct
taiu: hmm ,yeah I have that one too
EruditeHermit: nha: how come it won't work with gallium?
EruditeHermit: just never tested it?
nha: EruditeHermit: not tested extensively
EruditeHermit: nha: have you ever used the gallium driver?
nha: actually, fogcoord and fragment.position are very likely to not work, everything else is probably fine
nha: EruditeHermit: not in anything resembling production, but I've ran several test programs to check whether the hookup looks basically correct
EruditeHermit: you've booted it though?
nha: also, I suspect MostAwesomeDude would have hit me if any shader-related problems have cropped up
EruditeHermit: how does it look?
nha: EruditeHermit: never used it for compiz, I'm not crazy
EruditeHermit: lol
MrCooper: nha: your changes have improved it quite a bit here, almost getting usable
nha: well, it kind of works, with many missing features and many bugs
EruditeHermit: did you ever try glxinfo on it?
nha: EruditeHermit: of course
EruditeHermit: does it report OpenGL 2.1?
nha: I routinely do a glxinfo after copying the driver files to verify that the correct driver is loaded (sometimes, the driver fails to load if some function is missing, for example, but the linker fails to recognize this during build)
nha: EruditeHermit: of course not, you need GLSL for that
MrCooper: nha: btw though, be careful not to introduce dependencies on Mesa into the core Gallium driver - I noticed there's an -I for mesa headers now
MrCooper: (beyond the shader compiler)
nha: MrCooper: how much can break because of that?
MrCooper: nha: the Gallium driver can be used without any Mesa bits
MrCooper: e.g. with the Xorg state tracker
MrCooper: in the long run the two trees might even become independent
EruditeHermit: nha: is the GLSL thing something that again is going to be written to work with both classic and gallium?
nha: EruditeHermit: I would strongly recommend that, yes, and because of the rework, it's pretty much possible
EruditeHermit: nha: does that mean when you get back there is a possibility of OpenGL 2.1 in classic mesa too?
EruditeHermit: agd5f: hi, I have one quick question for you if you have time
EruditeHermit: agd5f: do I have to set the registers and reboot if it doesn't work each time?
EruditeHermit: and then try another one?
nha: MrCooper: okay, that part is clear; pretty much the only reason that -I is there is because we still use the prog_instruction structure; I've contemplated essentially duplicating these structures in the shader compiler, but since it's a lot of work without immediate payoff, I didn't do it. I certainly only want to reduce dependencies going forward; when I get to look at branch / loop support for R500, I'm going to reconsider moving to a diffe
nha: rent instruction structure again, and that'll deal with all Mesa dependencies
nha: EruditeHermit: yes
MrCooper: nha: okay great, just wanted to make sure you're aware
EruditeHermit: nha: is GLSL shaders the only thing missing to make it OGL 2.1 right now?
nha: EruditeHermit: no
nha: there's also VBO, OQ (osiris_ is working on those), I believe multiple render targets, and a bunch of other random extensions
EruditeHermit: i thought VBO is supported on kms
agd5f: EruditeHermit: you can try them all without rebooting. however, some may be timing depending so they may not fix anything by just changing them
nha: EruditeHermit: well, technically yes, but it's only fake support so far
EruditeHermit: agd5f: well I tried them all and they didn't work
EruditeHermit: nha: fake support? =p
agd5f: spstarr_ebook: several people have had luck with newer kernels
agd5f: EruditeHermit: yeah, I figured as much. so either some need to be adjusted during the mode set, or it's some other regs that we aren't dumping in radeontool
nha: EruditeHermit: well, you can implement VBOs without actually accelerating rendering from VBOs
EruditeHermit: agd5f: so where do we go from here?
EruditeHermit: nha: so a lot is still to be done before OGL 2.1
nha: yes
agd5f: EruditeHermit: figure out what regs are to blame. probably hack radeontool to dump more stuff, or try radeondump
nha:
nha: though it's actually not that bad
nha: I hope we'll get there by the end of the year
nha: (for the r300 driver; r600 is a different beast, I can't speak for them)
EruditeHermit: agd5f: so nothing I can do now
nha: oh, and to the phoronix crowd: the above is not a plan, nor any committal to anything at all, just random guess-work on my part
nha: (I hope it's not too later for that disclaimer ;))
EruditeHermit: lol
chithead: nha: too late, what you said has been recorded and will turn into a phoronix article immediately :p
EruditeHermit: nha: you forgot to multiply time by 3
nha: chithead: damnit, we're screwed
EruditeHermit: 6 developer guess months ~18 real world months
nha: EruditeHermit: I will promptly go into Scotty mode ;)
EruditeHermit: relativity
EruditeHermit: developer relativity theory
nha: true
nha: the faster a project moves, the shorter it will appear to a stationary observer
nha: or something
nha: a project moving at lightspeed appears not to age
MrCooper: nha: my guess is the article was up before your disclaimer ;)
EruditeHermit: lol
EruditeHermit: nha: you have to work especially hard when you get back to meet your promises to phoronix
EruditeHermit: =p
virtuald: why can't i play heroes of newearth? i have an rv570 and the game dies saying opengl 2.0 not available, is that right?
nha: virtuald: that's right
virtuald: ok
nha: come back in 18 months, according to the discussion above ;)
virtuald: heh
EruditeHermit: sucks for those who have r500
EruditeHermit: =p
virtuald: yeah :/
EruditeHermit: atleast r3/400 users probably want to upgrade soon now
EruditeHermit: r500 is still pretty new
nha: and we'll get r500 up to what it can support in hardware, and you won't have to worry about end of life of driver support
EruditeHermit: virtuald: you could try running it with the software renderer
EruditeHermit: =p
nha: that's the beauty of open source
EruditeHermit: nha: yeah eventually it will be great
nha: well, until all the r500s owned by driver developers break; once that point is reached, driver support will whither and die
EruditeHermit: i'm already quite happy with it apart from a few bugs
EruditeHermit: nha: good thing about ATI cards compared to Nvidia in my experience is that they last forever
EruditeHermit: my nvidia cards died at 2-3 years
EruditeHermit: my ATI cards are running strong at 5 and 6
virtuald: hehe if i tried with software renderer i would probably just have to struggle to kill the game because it would almost freeze the computer
boghog: had the same with my nvidia cards, except last 2 ATI purchases had the fan die of once card (crappy non-reference design fan), and the other card (hd4850) just died after a few weeks of use :/
virtuald: i still have a working mach64 somewhere
boghog: my opinion is that all hardware these days sucks equally :p
dileX: nha: here is gate #34- last call for mr. nha - please come to boarding :-)
boghog: 06:04.0 VGA compatible controller: ATI Technologies Inc 210888GX [Mach64 GX] (rev 01)
boghog: still using that in a server of mine :p
boghog: needed a PCI card
boghog: sometimes it inverses video at boot though.. really odd
suokko: Is there any others tool to read gpu registers than radeontool? It causes freeze for me :(
suokko: glisse: Is there some register dump file in sysfs?
glisse: some of the files there, dumps some of the regs
glisse: suokko: what are you looking after ?
suokko: I would like to read Viewport/clip registers from my r200
suokko: I don't understand why everything renders only to top left 30x30 corner
gopher`: hi people
gopher`: the radeon kernel module hangs my machine, could somebody please help ?
gopher`: X starts, then works "normally for about 15 seconds, then freezes
gopher`: my config file : http://pastebin.com/m4491d1fd
suokko: fixme:d3d_shader:shader_arb_generate_pshader No free constant found to load NP2 fixup data into shader. Sampling from this texture will probably look wrong. :) (r500)
gopher`: my board : 06:00.0 VGA compatible controller: ATI Technologies Inc RV515 PRO [Radeon X1300/X1550 Series]
gopher`: 06:00.1 Display controller: ATI Technologies Inc RV515 PRO [Radeon X1300/X1550 Series] (Secondary)
gopher`: this only occurs when the radeon / drm module is present, without the two of them it works, but with poorperformances...
gopher`: thanks in advance :)
suokko: gopher`: Can you paste xorg.log and dmes?
suokko: dmesg*
gopher`: yes of course
gopher`: just a second
gopher`: http://pastebin.com/mc1be0d1 <== dmesg (without loading radeon module)
agd5f: gopher`: need to see it with radeon
agd5f: at least the xorg log
bridgman: posting logs for the configuration that is causing you problems is what matters
gopher`: here are the lines of dmesg after loading the modules, a couple of hours ago : http://pastebin.com/m5a44672f
bridgman: if it works then logs don't help much ;)
agd5f: gopher`: looks fine
agd5f: what kernel are you using and are you using the in kernel drm or one build from some other tree?
gopher`: the 280 last lines of the X.log a the same time : http://pastebin.com/m56901e79
gopher`: I'm using vanilla 2.6.30.4
gopher`: I use to compile my own kernel for years, now...
bridgman: gopher, can you pastebin the entire xorg log ? there's not much useful in the excerpt
suokko: gopher`: Full logs are more helpfull
agd5f: gopher`: is this an AGP card?
gopher`: nope, PCI-E
gopher`: just a second for the full log
gopher`: http://jazzcomputer.org/temp/Xorg.0.log.old
gopher`: (the radeonhd module turns my screen black and hangs the machine, if this can be of a help)
gopher`: s/module/driver
bridgman: wierd message; (WW) RADEON(0): R500 support is under development. Please report any issues to xorg-driver-ati@lists.x.org
bridgman: that's not in the current driver is it ? but the startup message indicates 6.12.1...
gopher`: Installed versions: 6.12.1-r1
suokko: gopher`: You should set AccelMethod to exa
gopher`: suokko: I did it, either method does the same result, freeze
agd5f: gopher`: you might try 6.12.2
agd5f: or git master
gopher`: I've changed in the BIOS the option not to assign an ORQ, too, without effect
gopher`: yes, I see 6.12.2-r1 is in gentoo
agd5f: gopher`: irq shouldn't matter, you'll want one enabled for optimal performance with 3d
gopher`: ok, I'll put it back in the BIOS at the next rebbot
gopher`: it's compiling...
suokko: http://antin.net/wesnoth/civ4.png <- "Minor" rendering bugs
gopher`_: back, after reboot, because of freezing with the last version...
gopher`_: in the system logs, I find just before it hangs that R500 Microcode is loaded, then writeback test succeeded in 1 usecond
gopher`_: could there be a firmware problem or something ?
agd5f: gopher`those are the about the only messages the the drm prints
gopher`_: ok but couldn't this R500 microcode be buggy in a way ?
agd5f: gopher`_: doubtful
agd5f: unless your kernel source is corrupt somehow
gopher`_: very doubtful, too...
mikkoc: gopher`_: i also get lockups with r500, but randomly, not after 15 secs
mikkoc: been getting them for ever
agd5f: gopher`_: does it hang if you start just plain X (without KDE or gnome)?
gopher`_: I use XFCE
gopher`_: mikkoc: X freezes *always* with this very same board ?
agd5f: gopher`_: might try xf86-video-ati git master
mikkoc: gopher`_: well, my freeze is global, the whole pc locks up.. not X
mikkoc: and its random
agd5f: gopher`_: I have an rv515 and it works fine
gopher`_: agd5f: PCI-E ?
agd5f: gopher`_: PCI and PCIE
agd5f: both work fine
gopher`_: ok, I think I'll look at nvidia fanless boards... sorry but it's rather unusable, presently...
gopher`_: thank you very much for your help anyway, it's very king of all of you :)
gopher`_: s/king/kind sorry :)
agd5f: gopher`_: might try xf86-video-ati git master
agd5f: I think gentoo has an ebuild for it
gopher`_: ok, I'll give this a chance, be right back
Flyser: What's the best kernel/radeon-driver/mesa/libdrm version combination to get good kde4 performance (don't care much about 3d, but 2d and video playback should be smooth)
Flyser: I am using 6.12.x and scrolling in firefox is very slow
agd5f: Flyser: enable EXA: Option "AccelMethod" "EXA"
agd5f: in the device section of your xorg config
Flyser: I am using that
suokko: gopher`_: I would think you either have some fglrx junk left behind or one of X components are just too old for all the bugs getting fixed
Flyser: oh forgot to mention: its a r100 (thinkpad T40). I also have a r300 in an acer notebook which seems to suffer from the same problems
gopher`_: suokko: yes, but as my kernel is completely new, how could stay some fglrx junk ? in the previous kernel ok, but there...
gopher`_: (I have compiled 2.6.30 for this purpose)
agd5f: Flyser: same option applies
agd5f: gopher`_: fglrx also overwrites some libs on the system which may be causing a problem
Flyser: well I am already using EXA, so ...
agd5f: Flyser: you might try XAA then since your r1xx acrd probably has limited vram
gopher`_: agd5f: how is it possible to find these libs and get rid of them ?
phercek: fglrx also overwrites some libs; it does I needed to reinstall xorg, but in my case X did not even start
Flyser: okay I will. Still is there a recommended kernel/radeon-driver/mesa/libdrm version combination similar to the Intel 2009Q2 package
gopher`_: xorg have been recompiled since...
agd5f: Flyser: you could try kms, easiest path for that is Fedora 11
Flyser: I don't think that's a answer to my question?
bridgman: I think it is... you asked about something similar to the Intel package, and that would be the KMS stack
bridgman: and F11 is the easiest way to get the KMS stack right now
chainsawbike: gentoo and x11 overlay isnt to big of a battle though...
suokko: I think kms is way too slow still for older cards
EruditeHermit: kms is about 1/3 the speed
EruditeHermit: for me
EruditeHermit: its usable
EruditeHermit: but not as smooth
otaylor: suokko: what do you mean by older cards?
suokko: otaylor: (maybe more like agp) but r200 at least has horrible performance with kms
glisse: biggest slow down today is copy to front buffer
Flyser: and what versions does fedora use? I prefer not to switch distributions just because installing the latest graphics driver is easier ;-)
glisse: with pagefliping fullscreen app should pretty much see their frame rate double
otaylor: suokko: hmm, don't know about r200. Do you have AGP turned on? Frequently it isn't
otaylor: glisse: really? for apps not just doing glClear()
bridgman: Flyser; F11 was ahead of upstream, so the driver versions don't correspond to anything in the upstream tree
suokko: otaylor: yes. In fact pci mode is better for some oeprations that transfer only little data to card but do it often
Flyser: mh :-/
chainsawbike: anyone had any problems when using kms and a dual-screen setup (xrandr) and the mouse is only visible on one screen untill you make it switch sides
otaylor: suokko: but it's the kind of thing that it's hard to talk about in the abstract, since there is so much variation at the moment - I had to bang F11 into shape quite a bit to make it usable with r300+AGP
otaylor: (much of the banging into shape is now in f11 updates)
otaylor: suokko: Do you mean for 3D or for 2D?
glisse: otaylor: yup here quake3 goes from 90fps to 174fps
suokko: Problem is more like that all 2D and 3D is doing large amount of memory allocations and dealocations that now require kernel interaction which is slow. Also cache mode changes used to be bad for my system
suokko: otaylor: both are slower than without kms
glisse: and this is a big card with a lot of bandwidth so i expect gains are bigger on older card
otaylor: suokko: there were various "infelicities" in certain kernel driver versions that made allocations really suck big time on AGP
otaylor: suokko: so, you may have seen that in testing. I don't think it's an inherent issue though
suokko: otaylor: I have pretty much run all the versions since kms was merged to linus' tree
EruditeHermit: glisse: when is pageflipping going to be merged?
otaylor: glisse: Do you have any explanation for that?
otaylor: glisse: IT doesn't seem to make any logical sense
glisse: otaylor: today with dri2 we render to buffer and the Xserver blit this buffer to front buffer
glisse: for fullscreen app this cost a lot of bandwidth
otaylor: glisse: the amount of vram bandwidth being used to copy the back buffer to the front buffer once per screen really should be minimal
otaylor: glisse: But doesn't rendering the quake3 scene use lots *more* bandwidth?
glisse: 1280*1024*4*60 bytespersecond
glisse: hards to know if q3 use more bandwidth for rendering
bridgman: x2 for read & write, plus blitter uses relatively short bursts so consumes relatively more vram time than you would expect from comparing to raw numbers
glisse: dri1 goes up to 240fps on same configuration
MrCooper: the additional CS flushes may also be significant, there seems to be some significant constant cost to them
glisse: but dri1 has pageflipping
MrCooper: and tiling
EruditeHermit: dfs and uts too
otaylor: bridgman: yeah, with the x2 it gets almost up to what seems like it might matter a bit on an older card
MrCooper: EruditeHermit: we have that with KMS as well now, but it's not relevant for 3D
EruditeHermit: MrCooper: really?
bridgman: yeah; you probably need to double or quadruple it again because of the short bursts from the blitter
EruditeHermit: MrCooper: I saw my gears numbers increase when I enabled dfs
EruditeHermit: weird
bridgman: the 3d engine can usually move things more efficiently but it can be a pain to use
bridgman: ask agd5f ;)
bridgman: disconnects and runs
glisse: MrCooper: flushing didn't seems to be that high yet but i am sure microbenchmark exhibit this
EruditeHermit: MrCooper: where is UTS in kms?
glisse: EruditeHermit: we don't do uts yet
MrCooper: EruditeHermit: being discussed on the xorg mailing list
EruditeHermit: ok
EruditeHermit: yeah I didn't see it committed
jcristau: s/xorg/&-devel/ :)
MrCooper: for me it's actually a slight loss as far as x11perf numbers are concerned
glisse: MrCooper: btw do you see corruption with uts ?
EruditeHermit: glisse: is pageflipping also being discussed there?
MrCooper: glisse: no
glisse: where pageflipping is discussed is a bit fuzzy :)
glisse: mostly on #dri-devel so far
EruditeHermit: I remember agd5f had a UTS patch that gave me a lot of corruption
EruditeHermit: but that was a while back
agd5f: EruditeHermit: MrCooper posted a updated version on xorg ML
MrCooper: corruption? It locked up here :)
EruditeHermit: i just had text corruption
EruditeHermit: lol
suokko: ouch. font corruption :(
DanaG: What does UTS stand for? Opposite of DFS?
MrCooper: it was passing completely bogus parameters to a few functions, so if it didn't lock up for others that was mostly luck :)
DanaG: ah, yes. /me googled it. =รพ
EruditeHermit: MrCooper: your new patch reduced speed?
EruditeHermit: =p
suokko: glisse: http://antin.net/wesnoth/gears.ogv that is what I'm trying to debug
EruditeHermit: MrCooper: are you a tungsten person?
MrCooper: VMware person since they acquired TG
suokko: If anyone has pointers what could cause that clipping of rendering in r200 it would be very helpfull
suokko: I already checked that no user clipping planes are emitted and viewport transformation looks right to me
EruditeHermit: MrCooper: does VMWare have you do anything differently?
EruditeHermit: or has your role remained the same
MrCooper: the job's pretty much the same, but we're only working on VMware projects now
suokko: I guess none has off hand guesses what could be wrong in dri2 state :(
glisse: suokko: it's likely a bug in what mesa sends
glisse: suokko: adding printf to know what values mesa try to program might be usefull
suokko: I did enable state emit debug output
suokko: And it looked correct to me: all user clip planes were disabled and viewport transform float values at least were correct
suokko: I don't know if they are correct for card
glisse: suokko: that's what i mean
glisse: you need to add printf in the place the card value are built
glisse: and then look at reg spec and check if we are doing it right
suokko: (r200)
glisse: reg spec is radeon_reg.h :)
EruditeHermit: MrCooper: so is your radeon work part of the VMWare stuff?
MrCooper: no
suokko: But isn't it enough that I look at about enabled by DEBUG_CMDBUF in radeon_common.c?
EruditeHermit: MrCooper: where do you get the time?
EruditeHermit: =p
suokko: Does anyone want to see the debug output? I'm not very experienced to spot the mistake there :(
suokko: http://antin.net/wesnoth/err.log.bz2
suokko: I uploaded it anyway
glisse: suokko: emitscissor doesn't output much
suokko: glisse: scissors are disabled
glisse: disable cmddebug and add printf to r200EmitScissor
suokko: The line number tells it is outputing the else branch in r200_cmdbuf.c
suokko: Which looks from code that no variables are affecting it
suokko: OUT_BATCH(rmesa->hw.set.cmd[SET_RE_CNTL] & ~R200_SCISSOR_ENABLE);
suokko: glisse: I found state emit when scissors are enabled in SET state
suokko: line 15193
suokko: no luck with printf because scissors are disabled all the time
glisse: suokko: hhhmmm
carldani: hi
carldani: I heard the good news about 785G support
carldani: I'd like to verify some patches I have against a 785G lspci
carldani: Would somebody please be so kind and run "lspci -nnvvvxxxx" for me?
carldani: that's all I need
suokko: glisse: is viewport transform the way how hw is told about rendering buffer size?
suokko: or is there some others mechanism that tells hw where to render
Dr_Jakob: suokko: no viewport transform goes from GL:s viewport coords to render target coords
glisse: well viewport & scissor are the 2 things that should affect rendering
suokko: But how hw then knows not to render outside the buffer limits if scissor is not enabled?
glisse: viewport is also doing scissoring
glisse: from hw point of view
Dr_Jakob: glisse: hmm okay? I thought that scissor and viewport where different states?
glisse: Dr_Jakob: they are
glisse: i misexpressed my self there is always a scissor set to scissor to current viewport
Dr_Jakob: ah ok
suokko: glisse: Is viewport then correct in your option? r200UpdateWindow: y_scale: -1.000000 y_bias: 300.000000 depthScale: 0.000000 xoffset: 0.000000s(150.000000,-150.000000,0.500000) t(150.125000,150.125000,0.500000)
glisse: what is the last past s(...)
nanonyme: suokko: Looks neat still disregarding the rendering bugs though. :)
suokko: civ4? my rv280 card can render it more correct and with better fps ;)
nanonyme: Still.
nanonyme: That already looks pretty exciting.
nanonyme: It's over Wine, right?
suokko: yes
nanonyme: So yeah, I still think it's exciting. :)
nanonyme: (and a good reminder that Gallium3D isn't really a must, classic Mesa is good enough for quite a few cases)
nanonyme: Unless of course that thing requires full 2.0 to render properly. :)
suokko: nanonyme: It renders quite well without fragment shaders ;)
nanonyme: Hmm, right.
nanonyme: suokko: I was more wondering whether it would need GLSL but still run without it with borked rendering.
suokko: nanonyme: borked rendering is because of not enough constants in fragment shader for wine
nanonyme: Ah, right.
suokko: and some extension missing
nanonyme: Well, for the latter again, I hope it's not one of those bigger extensions that won't get into classic Mesa. ;)
nanonyme: (means I'd get sooner to the "hey, this actually works, now everything else is extra" phase...)
nanonyme: Heh...
nanonyme: Actually seems the buffer swapping isn't really the only place r600 driver memcpy's.
DanaG: oh yeah, I tried the r600 compiz, and true enough, it was slow... but the thing I found really odd was that trying to rotate the cube crashed Xorg.
nanonyme: (plus the other memcpy place comes with a FIXME tag for missing attributes)
nanonyme: (Oh, I'm wrong. It actually just advices what you have to remember when you fix it)
nanonyme: I wonder what dirty in the context of buffer objects means though.
nanonyme: Apparently more accurately context is bo_vram_validate.
nanonyme: Meh, some CS stuff, apparently.
nanonyme: mcgreg: Hey
mcgreg: hallo nanonyme :)
nanonyme: Seems the fix that should have really fixed your problem went upstream. ;)
mcgreg: means what? directl into drm master?
nanonyme: Naw, the thing in r6xx-r7xx-3d. Upstream meaning agd5f. (whereas I'm downstream)
nanonyme: It's a long river. ^^
DanaG: will be glad if/when all that stuff all goes into master.
nanonyme: It won't? ;)
nanonyme: It'll end up in Linus' tree eventually instead.
nanonyme: (Well, right. If you mean as in Linus tree git master, then yeah, I'm happy then too)
DanaG: Well, you're right -- I meant "master" as in "whatever's way upstream, and will go in distros".
nanonyme: Yeah.
mcgreg: nanonyme, yeah sry, I meant that. so, all your pacths went up .. means the normal r6xx-r7xx-3d should now work on .30/.31 without any additional patches?
nanonyme: There seems to be a certain level of optimism for r6xx-r7xx-3d getting into 2.6.32.
nanonyme: mcgreg: Yes... I also found out the problem wasn't just .30/.31.
nanonyme: mcgreg: It's 2.6.27+ with the specific kernel configuration.
MostAwesomeDude: I really hope that r600 classic cmdbuf stuff doesn't go into the main kernel. Once it goes in, it'll be there for eternity. :C
mcgreg: nanonyme, well, good work - again. and again, thx you :)
nanonyme: MostAwesomeDude: I was under the impression r600 cmdbuf isn't among the needed stuff when it gets ported.
DanaG: Might be good to skip pushing classic Mesa R600 up there?
nanonyme: DanaG: This is kinda different.
DanaG: ah, not sure what you meant by "cmdbuf."
nanonyme: DanaG: There's a file r600_cmdbuf.c in DRM, I assume he was talking about that.
MostAwesomeDude: nanonyme: Maybe. I'm not too up-to-date on it.
MostAwesomeDude: I haven't peered too closely, but I assumed that r600 is using something similar to the classic cmdbuf for submitting stuff to the card.
nanonyme: It is yeah...
nanonyme: MostAwesomeDude: Well, agd5f said cmdbuf isn't among the files you need to port code from. *shrug*
nanonyme: Apparently radeon_cs.c and new ioctl definition from radeon_state.c are the important stuff.
suokko: Ouh. Well I stil ldon't understand how everything works in GPU :(
suokko: At least the clipping part
nanonyme: MostAwesomeDude: The trickiest part there might be (unsure how well I understand the big picture still) radeon_cs_ioctl since there's a function with the same name in old radeon_cs.c and r600 radeon_cs.c. Might have to check how they should be combined if they should be combined. ^^
dileX: pooh, screen corruption w/ huge photos loading in ffx3
mimikry: dileX: yeah, here too
nanonyme: MostAwesomeDude: Also it might be that if you're a more proficient coder than I am, there is no tricky part...
glisse: nanonyme: should not be combined
glisse: specific r600 cs will be in 1 file
nanonyme: Ah.
nanonyme: Check.
nanonyme: glisse: So it's just a matter of copying the whole file over with a new name, then figuring out how to add the ioctl in the sanest way?
dileX: mimikry: like this?
nanonyme: Whoa. :)
glisse: nanonyme: well we want to share code
glisse: don't know yet how much/how good it will be
mimikry: dileX: exactly. everytime if there is a big picture
dileX: mimikry: which constellation are you testing (see my title in imagebin)?
nanonyme: glisse: Sure. Just interested, it's not like I'd be doing the actual porting...
mimikry: dileX: up2date fedora11 64bit with my X700 pro
mimikry: compiz enabled if that matters
dileX: oh, he said the c-word
dileX: mimikry: I am not in the F11 world, sry. building mostly from git (and or build debianized packages)
nanonyme: Which probably means you're using newer stuff than F11 has...
nanonyme: This was KMS-land, right?
dileX: in my case, yes
nanonyme: Yeah.
nanonyme: F12 KMS stuff should afaik be closer to upstream.
dileX: could downgrade ddx and later kernel, to see where it comes from
airlied: suokko: I saw the same on my r200 yeseterday
suokko: airlied: I have seen it for a while. compoiste manager hides it better but not completely
suokko: And I can't understand what is wrong in the state
airlied: I suspect the DDX emits something that confuses the 3D driver
suokko: airlied: I have 1:6.12.99+git20090804.6b1b4b92 installed
suokko: nanonyme: What was the alternative structure to DRI2BufferPtr? DRI2Buffer2Ptr?
nanonyme: Yeah.
nanonyme: Well, alternative and alternative.
nanonyme: DRI2BufferPtr still exists, just doesn't have that one field.
agd5f: nanonyme, MostAwesomeDude: r600 uses the CS ioctl
suokko: has to reboot because of font corruption
suokko: Can't bisect in ddx :(
suokko: at least not without using older kernel
MostAwesomeDude: agd5f: Ah. So it doesn't need any special extra work?
MostAwesomeDude: WRT CS, at least?
agd5f: MostAwesomeDude: the ioctl is written, it will need some tweaking for ttm when we had r6xx ttm support
MostAwesomeDude: But you're not planning on supporting two different sets of controls, right?
agd5f: nope. just one ioctl for legacy and kms
agd5f: CS
MostAwesomeDude: Are the old-style ioctls gonna stick around for r6xx when KMS starts up, or are those going to get nuked?
agd5f: MostAwesomeDude: same as r1xx-r5xx
agd5f: we need to support KMS and legacy
MostAwesomeDude: Ah, that's too bad. But that's life.
agd5f: MostAwesomeDude: but for 3D, it's the same ioctl in both KMS and legacy
MostAwesomeDude: At least we can incentivize it; 3D with KMS is going to keep getting more awesome.
MostAwesomeDude: (Did I just say "incentivize?" I'm turning into one of THEM...)
nanonyme: :D
nanonyme: agd5f: Still many things on todo list before buffer swapping? :3
agd5f: nanonyme: working on the buffer swap stuff now
nanonyme: Ah. X)
nanonyme: Great, won't be talking of it again until it's ready then.
glisse: posted another round for the pool allocator
glisse: core thing should be fine now, need to add set_pages_array_wc to core kernel thought
airlied: glisse: talk to venki about set_pages_array_wc
airlied: he mentioned he'd need to expand something two 2-bits
airlied: for tracking wc vs uc
yangman: anyone experiencing corrupt LVDS output on a M5x with KMS on resume-from-suspend?
yangman: nothing unusual comparing CRTC1_* and LVTMA register values. at a loss of what to investigate next
airlied: yangman: make sure distro isn-t postibg gp
airlied: gpu
yangman: airlied: on Linus' kernel with just echoing 'mem' to /sys/power/state atm
yangman: the corruption pattern makes it seem like it's a tiling mode difference...
airlied: doea fbcon restore without X
yangman: this is all without using X
yangman: although behaviour is the same with X
yangman: fine without KMS, so I can only assume it's KMS specific
airlied: most likely without kmsthe os is posting
airlied: though id expext we just arent resetting something
yangman: the screen just flashes a repeating pattern that changes depending on what's on the scanout buffer
yangman: seems like a timing issue, but I'm not sure where
yangman: same thing on LVDS and VGA-0, also
Vash63: So I tried fglrx again since there are patches to hack 2.6.30 support. Then I found out I still hated it. Now when I switch back to xf86-vide-ati, my DRI won't work.
Vash63: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
Vash63: [dri] radeon.o kernel module version is 8.63.2 but version 1.17.0 or newer is needed.
agd5f: Vash63: remove fglrx
Vash63: I did.
agd5f: airlied: BTW, we should save and restore the bios scratch regs for suspend/resume since they don't get re-inited
Vash63: brb, gonna try rebooting... there's no fglrx modules loaded but maybe that will fix something.
agd5f: Vash63: looks like the fglrx drm is still around
suokko: Vash63: you have kernel module left behind
Vash63: Why must fglrx haunt me even when trying to get rid of it?
Vash63: Oh, the module was still there.
Vash63: Package manager didn't get rid of it...
nanonyme: Solution: don't install it in the first place. ;)
Vash63: And Xorg automatically loaded it back in after I rmmod'd it.
Vash63: Know off hand where fglrx.ko is placed? I don't see it in lib64/modules/(kernelver) like with my other modules...
Vash63: It's on gentoo if that has a different location.
suokko: modinfo fglrx
Vash63: It seg faults...
MostAwesomeDude: Vash63: /lib/modules/`uname -r`
spstarr: hmm
Vash63: Yeah, maybe it was there MostAwesomeDude and I just need to reboot. Modprobe says it's still there but I don't see it.
spstarr: with f12 going alpha i wonder if it's safe to switch to rawhide yet
Vash63: modprobe -l shows "video/fglrx.ko"
airlied: yangman: VGA as well?
yangman: airlied: yup. haven't tried DVI, but I suspect it'll be the same.
airlied: yangman: okay that sounds wierd
yangman: airlied: was running in clone mode when I tried VGA, so what's on the CRTC itself is busted
airlied: yangman: can you get a dmesg.debug=15 trace?
yangman: sure. sec
yangman: airlied: http://pastebin.com/m1754afe9 beginning's cut off, but everything for drm should be there
nanonyme: curses at distros porting API changes from future kernels...
nanonyme: (make that, API changes which break things without leaving the old stuff as compat)
Vash63_: Well, I guess that worked. modprobe -l still shows it but if I try to use it it tells me the file doesn't exist.
Vash63_: And I got dri/exa working again with 'radeon' so I guess I'm happy. Thanks.
nanonyme: Vash63_: Try running depmod -a
nanonyme: See if it removes it from modprobe -l.
Vash63_: Ah, it did.
airlied: yangman: the ring doesn't get setup correct on resuime
airlied: not sure whats going on there
Vash63_: Anyway, can't wait for r600 KMS and 3d stuff to start hitting kernek/driver. Any idea how far off r600-700 3d is from being merged to master?
yangman: hmmm
airlied: sounds like something going wrong in there.
nanonyme: Vash63_: The DRI1 DRM stuff won't be getting in before 2.6.32.
Vash63_: Yeah, figured 2.6.31 was too late. Hopefully it's early so I can pick it up in a 2.6.32-rc kernel.
airlied: and that nmi doesn't look healthy
nanonyme: Vash63_: Well, the only way to give a realistic view sadly is to tell which kernel it can *not* get into. ;) Everything else is likely either optimistic or pessimistic predictions. :)
yangman: no idea what's going on with the NMI. I've noticed it before, but haven't looked into it. doesn't seem to break anything, though
Vash63_: Well I don't need that for 3d though, right? Just need newer Mesa and for r6xx-7xx rewrite to get merged?
nanonyme: Vash63_: You do need the DRM changes too.
nanonyme: So will take until at least 2.6.32 before you get 3D out of r6xx/r7xx with stock kernels. :)
Vash63_: Hmm, alright. At least the horrible video tearing and resizing from fglrx is gone again.
airlied: yangman: I wonder if aliging the GART further up would help
Vash63_: Amazing how they could spend so long not fixing 2d and video issues like that while having a 3d driver that performs relatively well.
airlied: Vash63_: why?
airlied: I doubt any of their flgrx customers care about the first two things
airlied: yangman: something like http://people.freedesktop.org/~airlied/gtt_align.patch
yangman: airlied: k. I'll give it a try
nanonyme: bridgman: Hey.
bridgman: hi
yangman: airlied: ring test is still failing. [drm] radeon: GTT from 0x20000000 to 0x3FFFFFFF
airlied: yangman: okay one guess down.
airlied: yangman: nmi still there?
yangman: yup
airlied: I think the resume path has some stupid in it
airlied: it appears to be redoing certain things that most likely shouldn't be redone
airlied: but they probably shouldn't affect this
yangman: hm. also the same issue on suspend to disk
airlied: finally sets up a desktop with suspend/resume working
bridgman: has never seen suspend/resume working, wonders what it's like
yangman: it's like a frail tower of cards. a sight to behold, but you darenot even breathe near it once erected
suokko: bridgman: It is something that works here ;)
yangman: ironically, on my desktop, it's windows that won't suspend properly
bridgman: even walking around FOSDEM nobody could show me working VT switch or suspend/resume
nanonyme: bridgman: I just succesfully suspended and resumed with r6xx-r7xx-3d. *shrug*
bridgman: I think it's a myth ;)
nanonyme: Just to see if it works. :)
suokko: I have lucky iron, both windows and linux can suspend :)
nanonyme: Same. My RV670 has pretty much done it always just fine. Only problem I've ever had was with forcedeth in one kernel release and that's fixed now too. ^^
airlied: well now that this desktop does it I get to plug in all my gpus
suokko: :)
airlied: starts at the r100
nanonyme: wonders if OpenGL compositing would work in breaking suspend/resume in DRI1
suokko: feels some one is pushing the luck a bit too much
nanonyme: :D
nanonyme: suokko: Naw, Fortuna likes me.
suokko: airlied: How about if I disable accerlation from ddx? Would that tell if r200 rendering bug is in ddx or mesa?
airlied: suokko: it might if you disable EXA composite
suokko: Is RenderAccel the right option to disable?
airlied: EXANoComposite "true"
virtuald: what is GTT?
airlied: graphics translation table
suokko1: airlied: gears works when composite is disabled
airlied: suokko1: I started playing with something like http://pastie.org/574917
suokko1: testing soon
suokko: bad news. It didn't help
suokko: and now I got screen corruption when I resize gears
suokko: and corruption stays after geras is closed
airlied: yeah I didn't debug it I just started on it the other day
suokko: Corruption=Seems like some clipibng rects are still in effect
airlied: I got side tracked
suokko: yes :)
airlied: the DDX programs RE_CNTL
airlied: RE_TOP_LEFT etc
suokko: Now I got everything back to normal
airlied: not sure the mesa driver does it
airlied: the radeon mesa driver probably does, the r200 one probably not
suokko: When I resize glxgears window and close it everything is after clipped to that size
suokko: So ddx enables scissors but don't updated the coords?
airlied: it clips for all rendering
airlied: the mesa driver needs to do the same
suokko: I tough there was bit to disable scissor clipping
suokko: (In RE_CNTL)
airlied: we pretty much want to clip all rendering
airlied: to the size of the colorbuffer object we are rendering to
suokko: yes. buffer overflow could be bad in kms world
suokko: ddx would need code to update the scissor registers. At least previous gears testing showed that ddx doesn't do it yet
suokko: Is ddx using UCP registers?
suokko: not at least in quick search
Rabenkla1e: hi, yesterday I updated my system to the most recent X libraries, xorg-server, mesa, libdrm and the free radeon driver and was running the new 2.6.31-rc5 kernel. But when starting X it got the following error:
Rabenkla1e: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
Rabenkla1e: [dri] radeon.o kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
airlied: Rabenkla1e: you didn't build libdrm with the right flags
Rabenkla1e: http://pastebin.ca/1520901
Rabenkla1e: I've installed the x11-libs/libdrm-9999 ebuild from gentoos x11-overlay.
suokko: Rabenkla1e: ./configure --enable-radeon-experimental-api for libdrm
Rabenkla1e: There is specified that libdrm will be configured with --enable-radeon-experimental-api
suokko: Then you need to recompile video-ati
suokko: I mean reconfigure and recompile
Rabenkla1e: Ok, then I'll remcompile it. Hope that'll do it.
Rabenkla1e: As I said, I'm using gentoo's live ebuilds, where those things should be done automatically
Rabenkla1e: Thanks for the hint, later this day I'll have a look, whether it worked.
Rabenkla1e: One more question. Will I be able to use radeon with DRI under 2.6.30, too?
Rabenkla1e: Or will this not be possible any more?
Rabenkla1e: So as before, without DRI2 and KMS?
suokko: yes. You can even disable KMS in new kernels and use DRI1
suokko: radeon.modeset=0 kernel parameter will disable modeset
airlied: yangman: so with that patch I posted to the mailing list, I can s/r my r100, rv370, r580 cards in my desktop
airlied: granted my r580 fan doesn't slow down once I resume which is quiute annoying
yangman: airlied: which list?
airlied: yangman: dri-devl
airlied: it was like the one I sent you earlier not sure if it was exact same
yangman: geez, sf.net is slowtastic as ever
suokko: gmane is better for mails :)
yangman: airlied: it's the same logically
airlied: yangman: okay boot with drm.debug=15 and pastebin it again
airlied: I'm not sure what else is broken in there
EruditeHermit: airlied: do you think that will help with bug 23103?
airlied: EruditeHermit: worth a try
airlied: it certainly makes some of my cards happier
EruditeHermit: airlied: how were they unhappy before?
EruditeHermit: what problems did you have?
airlied: EruditeHermit: they wouldn't resume
airlied: I'd see a ring error when I tried
airlied: and nothing on the screen
yangman: airlied: http://pastie.org/575006
EruditeHermit: airlied: is this a kernel patch?
airlied: EruditeHermit: yup on dri-devel mailing list
airlied: yangman: still getting NMIed
EruditeHermit: hmm
EruditeHermit: airlied: is there a way to just recompile this module in the kernel and copy over the file?
EruditeHermit: I don't want to have to do a 4hr kernel compile
EruditeHermit: =p
airlied: EruditeHermit: if you have
airlied: already compild it it shoudln;'t recompile it al
airlied: you just apply the patch
EruditeHermit: I don't have it already compiled =p
EruditeHermit: but I can get the source for the latest ubuntu kernel, patch it and compile it
EruditeHermit: but since it will be the same as the binary, if I can just compile that one file and replace it
EruditeHermit: it would be nice =)
airlied: does that kernel have all the kms bits?
airlied: but you could in theory do make drivers/gpu/drm/radeon
airlied: and it would just build the bits needed
airlied: but I'm not sure I never do things like that
EruditeHermit: lol
EruditeHermit: yeah it does have kms bits
EruditeHermit: I might have to ask sarvatt how to do this
EruditeHermit: or just do it overnight
yangman: I don't think I get NMIed without KMS. just double checking it now
EruditeHermit: airlied: is it git applt patch.diff?
EruditeHermit: I am getting patch does not apply
EruditeHermit: is this for 2.6.31-5?
airlied: yangman: I doubt it, the codepaths are very different without kms
airlied: EruditeHermit: 2.6.31-rc5 yes
yangman: yeah, no NMI
yangman: hmm
EruditeHermit: airlied: are you going to push this for rc6?
airlied: EruditeHermit: more than liekly
EruditeHermit: perhaps i'll try it then
EruditeHermit: rc6 is probably soon
EruditeHermit: next few days
yangman: relatedly, when should bios scratch register save/restore be done for KMS?
yangman: *unrelatedly
EruditeHermit: i don't get why its not applying
airlied: yangman: probably before suspend finishes and after post on resume
airlied: though your problem is definitely MC setup related
yangman: airlied: http://people.freedesktop.org/~yzhao/save_atom_scratch.patch something like this? hopefully I'm following kernel conventions correctly
airlied: yangman: yup, not sure if we want to just save them all into an array
airlied: 0->max_scratch and define max scratch depending on gpu
yangman: yeah, I just did a quick port from what rhd does
airlied: suokko: I think I've fixed the DDX scissors at least
airlied: not to fix mesa
airlied: now to fix mesa even
yangman: not sure how useful genericizing it would be, since there's very few registers in a non-contiguous address range
airlied: the bios scratch regs are in an array though
suokko: EruditeHermit: You probably want to use git am
airlied: suokko: I have gears now also
suokko: Because git patches are often made with git format-patch instead of git diff :)
suokko: airlied: good. I will test when you push the patches :)
yangman: right. not sure why those 4 are singled out
airlied: suokko: pushed to ddx and mesa
suokko: anongit is very slow for ddx :(
EruditeHermit: suokko: fatal: HEAD: not a valid SHA1
suokko: airlied: I begin to think that ddx commit disappeared somewhere
airlied: oops
spstarr: hmm
spstarr: OpenCL
spstarr: good for HPC and number crunching
airlied: suokko: now trry ;-)
airlied: suokko: there is no lag between git and anongit
airlied: if you can't see it then I didn't push it :)
suokko: ok
vehemens: airlied: what the problem with kms scissors?
airlied: vehemens: r200 rendering got clipped funny
vehemens: was curious as r600 with and without seems to have clipping problems
airlied: probably not close
vehemens: on a different note, my r600 seems snappier with the last set of xserver exa updates. anyone else noticing some improvement?
airlied: yeah it should help a lot
airlied: though its mainly for driver pixmaps
airlied: not sure it should help without them
dileX: to my firefox-problem (loading huge photos), 1st loading in tab is OK, 2nd loading (same photo) in another tab causes screen corruption. I have this error-messages in dmesg
vehemens: hopefully he'll publish some before and after numbers
airlied: well he tested with nouveau
agd5f: yangman: probably want to save all the scratch regs