Radeon IRC Logs For 2008-3-17

simpsonc: Hmm. Everything seems to pass around GLuints as registers, but that can’t be right since there’s only 7 bits per address per source?
airlied: simpsonc: they may not use the other bits
simpsonc: airlied: They’re using at least 23 of 32 bits. It appears to line up with flags “above” the register locations, but those aren’t going to port over to r500, so I guess I’ll have to mod them somewhat.
simpsonc: airlied: Okay, got it. The r300 registers can have the swizzles, imods, omods, and src selects “above” the register location.
simpsonc: But, on the r500, the only two flags always above the registers are the const and relative address flags.
simpsonc: So most of the reg flags have to be moved to live on different places.
simpsonc: So glad I figured that out. I’m going to bed now so I can take a calculus final in the morning. See you all tomorrow!
arekm: tried rotate left on r300… slow as hell
airlied: arekm: using EXA?
airlied: simpsonc-sleep: http://cgit.freedesktop.org/~airlied/mesa/log/?h=r500test
arekm: airlied: yes
airlied: simpsonc-sleep: maybe some bits of that are useful for you, nothing major just some moving code around
arekm: airlied: xaa shoudl work better?
airlied: arekm: nope.. EXA should.. thats what I asked.
airlied: arekm: what card?
airlied: why I asked even..
airlied: arekm: I assume you have a DRM..
arekm: airlied: x600 mobility, windows were slowly being repainted heh
arekm: “direct rendering: Yes”
airlied: arekm: not sure why it would be slow.. maybe oprofile, hopefully it is using accel..
mcgreg: airlied: any idea when there will be a first “alpha” of 3d acceleration for r500? 🙂
airlied: mcgreg: not a clue, just going to take it a step at a time, maybe before Fedora 9 final if I get more time.
airlied: mcgreg: though if simsponc can make progress it would be most excellent.
airlied: bbl.. zzz.
mcgreg: sleep well 🙂
MrCooper: arekm: using current xf86-video-ati Git?
arekm: d4446461c3630caff166456c351ace34f57cc119 so 2 commits old
hosler: Hey
hosler: Psycho__
PSYCHO___: he didn’t expected that i can react in 3 minutes
PSYCHO___: did he?
glisse: qjob
glisse: wrong window sorry
niravana_: hello guys
niravana_: does anyone knows TRANSPARENT XLOCK tool for linux?
niravana_: like xlock with transparent theme?
niravana_: found: xtrlock
hosler: PSYCHO__
hosler: you there?
hosler: anyone here?
OipOS: I am. Why?
hosler: ok
hosler: I have an Radeon X1200 series video card and im trying to get it to have DRI working
hosler: i installed the layman X11 thing and upgraded drm and ati drivers
hosler: but i still cant get dri to work. my xorg log say’t it cant find any cards in /dev/dri
OipOS: Probably because your kernel doesn’t have the DRM module.
OipOS: Either built a new kernel, or if your kernel supports modules, built the modules from git and modprobe them.
hosler: i built the drm module froms ource
hosler: drm is loaded
hosler: and so is radeon
hosler: PSYCHO___ guided me through this yesterday
OipOS: is there a /dev/dri directory? Does it contain any files?
glisse: hosler: you should have a message of drm module in your syslog (ie wherever your distrib print kernel message)
hosler: k
PSYCHO___: hosler: me here now
hosler: ok
hosler: i did all that stuff you told me, but still do cards found in /dev/dri
hosler: should i change my driver from radeon to r300 in xorg?
OipOS: Nah, ‘ati’ should be good enough.
PSYCHO___: what version of xorg you have
hosler: 7.2
PSYCHO___: more like radeon in gentoo
hosler: where is my syslog? lol sorry
PSYCHO___: /var/log/messages
hosler: check taht
hosler: its empty
hosler: nm its not
PSYCHO___: post on pastebin /var/log/Xorg.0.log
glisse: cat /var/log/messages | grep radeon
hosler: PHYSCHO__ is there an easy way to do that without copy and paste?
hosler: wait brb
hosler: http://pastebin.ca/946281
hosler: forgot about gedit
glisse: hosler: xorg log won’t tell much
glisse: cat /var/log/syslog | grep radeon
hosler: glisse: http://pastebin.ca/946283
glisse: hosler: what is your distribution ?
PSYCHO___: it tells error in xorg.conf
PSYCHO___: glisse: gentoo he have
hosler: gentoo 2007
glisse: hosler: rmmod radeon drm
hosler: k
glisse: modprobe drm radeon from the same source tree
hosler: whast that mean
hosler: lol sorry
glisse: your drm main module is likely not in sync with your radeon module
hosler: so what do i do
glisse: rmmod drm radeon
hosler: i did
glisse: to remove the current module
OipOS: Interesting. I thought he built the radeon and drm modules from one source. Hmm.
hosler: i did
glisse: then from where you build the drm module
glisse: cd drm/linux-core
glisse: insmod drm.ko
glisse: insmod radeon.ko
hosler: portage did that for me it think
PSYCHO___: this is done when he compiled that x11-drm and radeon from git
glisse: then cat /var/log/syslog | grep radeon and you should see somethings about successfull loading
PSYCHO___: only problem can be with changing kernel tree
glisse: i don’t know gentoo but building drm from git is easy
glisse: and you can replace your kernel distrib module by the one you build by cping over the files
PSYCHO___: glisse: ebuild do that all for him
glisse: PSYCHO___: obviously ebuild failled…
PSYCHO___: he must type emerge x11-drm only
PSYCHO___: no i have it from the same ebuild
PSYCHO___: and it is working
hosler: ok
hosler: so
hosler: should i unmerge libdrm x11-drm xf86-video-ati mesa and mesa-progs
hosler: and start over?
hosler: lol
hosler: thats usualy my approach towards this kind of stuff
glisse: hosler: well doesn’t emerge replace old things ? so emerge should be enough
glisse: no need to rebuild everythings
hosler: k
glisse: moreover here your problem lie in kernel drm module not in mesa or ddx ati
hosler: ok
hosler: whast your prognosis?
glisse: well working kernel module should print somethings, in the syslog or message or wherever such message are stored, about successfully loading microcode
glisse: then xorg should successfully open drm
glisse: then hopefully mesa & glx & r300 dri module are happy together and you see direct rendering: Yes in glxinfo
hosler: thats not what i meant
hosler: what do i need to do lol
OipOS: Get a copy of git-drm, compile it yourself, and install it yourself.
OipOS: (linux-core that is, not the libdrm part of it)
glisse: emerge x11-drm according to PSYCHO___
simpsonc: hosler: I take it that you’re trying to use Portage to install git code?
simpsonc: Morning, all.
hosler: simpsonc: yeah
hosler: should i unmerge libdrm?
glisse: libdrm is small won’t hurt
hosler: so should i or should i not?
OipOS: I advice against.
hosler: should i install the layman version of it?
OipOS: I advice against again. All you need to do to fix your problem, is fix the drm modules.
hosler: how
hosler: lol
hosler: i need a clear answer
hosler: cause i dont know shit about this stuff
hosler: im an fglrx veteran
hosler: lol
OipOS: git clone git://anongit.freedesktop.org/git/mesa/drm && cd drm/linux-core && make radeon.o && insmod drm.ko && insmod radeon.ko
hosler: alrighty
hosler: ill give it a try
glisse: simpsonc: btw for doing r500 as airlied adviced i suggest writting by hand a small program which copy color from input to output
glisse: simpsonc: so you can test that command submission work
glisse: simpsonc: otherwise debugging the compiler might be tricky as you might not know if cmd submission is functional or not
hosler: OipOS: ok done
OipOS: did you see a message about it having been succesfully loaded in dmesg?
OipOS: And is there a /dev/dri/card0 or so?
hosler: [drm] Module unloaded
hosler: [drm] Initialized drm 1.1.0 20060810
OipOS: If so, restart X, and see if DRI is enabled.
OipOS: (ctrl + alt + backspace)
hosler: there is nothing in /dev/dri
OipOS: Cool.
OipOS: Hmm, did it load the radeon module?
glisse: hosler: anythings about radeon ?
hosler: in dmesg? nope
glisse: lsmod ?
hosler: yeah its there
glisse: hhhmmm
glisse: and no /dev/dri ?
simpsonc: glisse: Yeah, that’s the idea. There’s a lot of stuff I’m still trying to get through my head.
hosler: there is a /dev/dri, but nothing in it
hosler: do i need to repopulate the /dev or something like that?
simpsonc: Does anybody know how to check out the repo in airlied’s userdir? “git pull git://people.freedesktop.org/~airlied/mesa” does not work…
glisse: simpsonc: well for doing this you just need to do the upload code, no need to port or do anycode like what is in r300_fragprog
glisse: simpsonc: git-add remote airlied git://people.freedesktop.org/~airlied/mesa
glisse: then git-fetch airlied
simpsonc: hosler: Okay, so you’re using git drm, and you installed the modules with “cd linux-core; make && make install”, right?
glisse: then you can do git-branch airlied-mesa:airlied/airliedbranch
glisse: and finaly git-checkout airlied-mesa to actualy switch to the code 🙂
glisse: i love git 🙂
hosler: right
hosler: git clone git://anongit.freedesktop.org/git/mesa/drm && cd drm/linux-core && make radeon.o && insmod drm.ko && insmod radeon.ko
hosler: i did that
simpsonc: hosler: Okay, unload the radeon module, then try loading it with “modprobe radeon debug=1”
simpsonc: And if you dmesg | tail you should see some gunk from the DRM.
simpsonc: glisse: the git-add fails; “‘remote’ did not match any files”
hosler: FATAL: Error inserting radeon (/lib/modules/2.6.23-gentoo-r9/x11-drm/radeon.ko): Unknown symbol in module, or unknown parameter (see dmesg)
simpsonc: I’m terrible with git…
simpsonc: hosler: And what does dmesg say?
hosler: radeon: Unknown parameter `debug’
hosler: i think it tried to load the old radeon module
hosler: git clone git://anongit.freedesktop.org/git/mesa/drm && cd drm/linux-core && make radeon.o && insmod drm.ko && insmod radeon.ko
hosler: that command never had install in it
simpsonc: Yeah.
simpsonc: I would personally make and install the libdrm and all drm modules from git.
simpsonc: If you use “make install,” it doesn’t matter whether or not you unmerge the Portage version.
hosler: i know
hosler: but i dont think it got installed with git clone git://anongit.freedesktop.org/git/mesa/drm && cd drm/linux-core && make radeon.o && insmod drm.ko && insmod radeon.ko
hosler: it just made the modules and inserted them
simpsonc: Right.
simpsonc: This is completely true.
hosler: i dont think they got put into the kernel module directory
simpsonc: “make install” should do that for you.
hosler: which dir?
simpsonc: linux-core
glisse: simpsonc: quick tuto: git clone git//fdo.org/git/mesa cd mesa git-remote add
glisse: you need to do git remote from inside a local cloned of the same project
glisse: so there is a common head in each repository
simpsonc: Ah.
simpsonc: Got it; reading new code now.
simpsonc: Hmm. Okay.
simpsonc: There’s some stuff in there that’s still shaky, like how exactly we’re going to emit the programs to the state.
simpsonc: But I see what’s going on.
simpsonc: I have a default program; haven
simpsonc: *haven’t been able to test it, but as it’s only one instruction it should be easy.
simpsonc: Ack, I forgot, there is one thing.
simpsonc: glisse: Do you happen to know which register holds the input colors?
RoiDuClapier: Would like to know if the release of r300 documentation will have a real impact on future performance for those chips or if the current state of r300 driver is close to optimum
agd5f: RoiDuClapier: there is a lot of room for improvement with the current r300 driver
RoiDuClapier: agd5f: That is what I thought, but what are those areas of improvement?
RoiDuClapier: I’m really interrested since I own such a card and that I want to contribute
agd5f: RoiDuClapier: there are a lot of places. first we need to clean things up with new documentation. replace guessed regs and bit fields with the actual names, etc., then,
agd5f: we can start adding new features and optimizations
agd5f: the fragment and vertex shaders would be a good place to start
RoiDuClapier: Ok, so the first thing is to make the driver conforms to doc
RoiDuClapier: Is the recent doc release enough to bring good perfiramce EXA driver?
RoiDuClapier: performance
agd5f: RoiDuClapier: yes
agd5f: RoiDuClapier: I’ve already started on r3xx composite accel, but I’ve run into some issues with masks: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r3xx-render
RoiDuClapier: agd5f: Ok thanks, it is what I had to know to get started
OipOS: What exactly are masks?
agd5f: OipOS: it’s kind of like a stencil
agd5f: OipOS: http://keithp.com/~keithp/talks/usenix2001/xrender/ look approximately 1/4 the way down
OipOS: Alright, thanks.,
glisse: agd5f: i believe real performance improvement will come with memory management
agd5f: glisse: definitely
glisse: as last bench i got, moving texture around was the performance killer
glisse: simpsonc: this is set in the routing register
glisse: let me check the name for r500
agd5f: glisse: you have any ideas what may be wrong with my FS code for EXA composite masks?
glisse: agd5f: got a pointer ?
glisse: i haven’t followed commit closely
agd5f: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r3xx-render
agd5f: glisse: ^^^
glisse: simpsonc: its all RS_* registers
glisse: they setup how output of rasterizer unit are routed to the fragment stage
arekm: airlied: one more thing about my “rotate being slow” problem – I was using lvds + external dvi-0 and I did rotate on that external dvi-0 only
agd5f: arekm: rotate accel is only available with EXA
arekm: agd5f: I’m using exa
agd5f: ok
agd5f: just making sure
glisse: agd5f: btw what’s wrong ? nothing on screen or corruption 🙂
arekm: agd5f: rotate on LVDS is fast (looks normal). rotate on dvi-0 is sloow (x600 mobile, thinkpad z60m)
agd5f: glisse: corruption, like I’m getting a bad texture for the mask
agd5f: arekm: are you using dualhead?
arekm: agd5f: yes (lvds in laptop + external lcd monitor)
agd5f: arekm: max texture size is 2048×2048, if you desktop is larger than that, it falls back to SW
arekm: 🙁 3360×2100 here
PSYCHO___: agd5f: could you please update those keys to 4096×2048
PSYCHO___: agd5f: i know you just guessed those numbers
arekm: agd5f: is this hw limit or driver limit?
agd5f: arekm: hw limit
agd5f: PSYCHO___: what keys?
PSYCHO___: agd5f: on r400 is it also 2048
PSYCHO___: ?
agd5f: PSYCHO___: yes
PSYCHO___: hmm
PSYCHO___: ok i will try something
agd5f: arekm: it could be worked around if we used separate buffers for each crtc, but that requires a lot of work
PSYCHO___: couldn’t i override this by saying i want not brick a*a in this 2048×2048 but a*b where b could i set max size of displays i have?
PSYCHO___: ie not 2048×2048 butt 3000×1000 ie
agd5f: PSYCHO___: I don’t follow
agd5f: the max width is 2048 and the max hight is 2048
agd5f: height
PSYCHO___: so i cant say to use buffer from hight to expand widht
agd5f: PSYCHO___: no
glisse: agd5f: to work around this you need that TFP extension to support tilling texture
agd5f: glisse: yeah that would work too
PSYCHO___: so my beautifull idea is doomed from begining :]
glisse: agd5f: marcheu is trying to push opinion for that i am helping him a little 😉
agd5f: glisse: 🙂
agd5f: glisse: but it wouldn’t help for xrandr rotation directly
glisse: yup for xrandr rotation better to split framebuffer
PSYCHO___: i have problem when i have big terminal and i switch from one destop to another it renders really slow
glisse: i believe splitting framebuffer is easier than what tiled support in tfp would ask
arekm: is this really big task?
arekm: I mean big == unlikely to happen
agd5f: arekm: the driver side would be relatively easy, the server side would be hard
agd5f: arekm: you’d need to “teach” the server to deal with multiple buffers per “screen” so SW fallbacks would work properly
agd5f: then there’s 3D
airlied: arekm: ajax has started looking at it.. but it is bery mesy..
airlied: very even..
ajax: it’s not _that_ bad for 2d.
ajax: 3d is where it becomes Truly Awesome
ajax: i really should finish it sometime
ajax: if nothing else than because it’ll probably be faster on r500 than linear 5k front buffer
ajax: and my second head isn’t lighting up until something gets fixed there
airlied: ajax: if you get it useable for 2D, I’ll hack the crap outta 3D 🙂
airlied: ajax: granted I get the feeling we would need a set of arbitary rules for 3D spanning boundaries.
airlied: or GL state resubmission of some sort like the > 3D render limits stuff
airlied: which as people keep saying isn’t fully solvable, granted I’d take mostly solvable over fully 🙂
ajax: airlied: right. my expectation here is that you bind multiple renderbuffers to the same back buffer, and submit the same batch buffer N times with the view matrix and clipping translated appropriately
ajax: which, sure, screws up at the seams a little, but who cares.
ajax: this is where it becomes what the ARB lovingly refers to as a “quality of implementation issue”
ajax: and working with edge artifacts is better than not working
airlied: ajax: hehe.. yes I’ll take that..
edgecase: hey question about TVscaler, something doesn’t add up, unless the scaler buffers one or more full frames, the CRTC must be only using the hdisp and vdisp, and the tvscaler setting the dot clock and all the scanout timings
airlied: edgecase: I’d go with the latter
ajax: (if you _really_ needed correctness you’d just have the back buffers overlap by the width of your filtering kernel, and then cut yourself blitting out of that to the front)
airlied: ajax: we probably need to have them overlap by the tile size
airlied: in any cse
airlied: case.
ajax: need?
airlied: if you screen width isn’t tile size aligned
edgecase: arlied, any idea if interrupts can be generated for blanking intervals, in with the tvscaler in the path?
airlied: edgecase: none…
airlied: though I suppose clipping can take care of it in the tiled case.
airlied: but it might be an option to make the overlap nicer..
edgecase: arlied, i notice some “tearing”, since scanout isn’t sync’d with video playback, however with textured video, it’s not a horizontal tear
edgecase: i get an obtuse triangle in scenes with a strobe light
edgecase: i suppose the player could be doing some deinterlacing foo
edgecase: but Z like Zorro pattern? too strange
simpsonc: glisse: Thanks. I’ll look at that right now before my next final.
edgecase: arlied, is either panel or TV scaler exposed to X clients in any way?
airlied: edgecase: the fix for the triangle tearing is to change textured video..
airlied: edgecase: nouveau do it better 🙂
airlied: edgecase: which came from the binary’s method..
airlied: you use one very large clipped triangle instead of two tris..
edgecase: interesting. ultimately i’d like vsync interrupts to trigger page flipping, the syncfb project is interesting in that regard
edgecase: anyone know if panel or TV scaler settings are exposed outside radeon driver?
airlied: edgecase: use a GL movie player 🙂
edgecase: for which issue is Gl movie player?
edgecase: I ask so manu questions, i’m loosing track 🙂
airlied: edgecase: syncing to vbl 🙂
edgecase: ooh right, 3d apps have wait-for-vsync
edgecase: vlc opengl output is about 1fps
edgecase: what opengl video player do you use?
airlied: edgecase: I used to use mplayer but it was a long time ago on intel hw.
airlied: edgecase: it was for an embedded app..
edgecase: oh i thought that was a use-case for textured video
airlied: edgecase: well I did textured video using OpenGL not Xv.
airlied: as I needed vbl
edgecase: well they say fashion is cyclic, so hopefully vbi will come back again
simpsonc: mplayer is awesome, though.
edgecase: i’d love to find 1 player that does everything. I don’t know of any that are smart enough to use xrandr to choose native resolution of source video, esp when a hardware scaler is in use
PSYCHO___: edgecase: mplayer will play even scratched metal plate
edgecase: yes it’s playing-foo is strong
PSYCHO___: but dvdmenu is problematic
PSYCHO___: some says it is working but not for me 🙁
glisse: agd5f: i am not sure anymore of the TEX_PTR is RS_IP_FIELD
glisse: agd5f: but for masked fragprog i would have set it to 1
glisse: line 1439
agd5f: glisse: yeah, I had that originally, same behavior
edgecase: does anything besides BIOS mess with vram controller setup?
edgecase: or is it always a contiguous chunk at a certain PCI BAR?
airlied: edgecase: it can move around and be configured differently
airlied: edgecase: by straps on the card and then BIOS
airlied: we raarely touch itin the drivers
glisse: from mym memory and from quite unspeakive doc
glisse: agd5f: btw i don’t see much of TX_OFFSET being set
agd5f: glisse: R300TextureSetup()
edgecase: once the card is POST’ed/inited, it’s just a big buffer, up to driver then to allocate it’s ram for various things, framebuffer, ring buffer, textures, right?
airlied: edgecase: pretty much..
edgecase: i mean, it stays linear, from CPU’s perspective
airlied: edgecase: not always.. but mostly..
airlied: edgecase: it can get tiled and then we have surface regs, and swappers
glisse: agd5f: so if i am following code properly you set texture address in unit 1 line 1083, try set 2
edgecase: right, but the underlying ram is still there yes?
airlied: edgecase: yes..
edgecase: i mean, the tiling isn’t done by the memory controller is it?
agd5f: glisse: right. unit 0 at line 1078, unit 1 at line 1083
glisse: i can remember all this stuff about the 16 texture addr while officialy there is 6unit
glisse: s/6/8
glisse: damm i getting bad at division 😉
agd5f: glisse: Is there anything special needed for FS TEX instructions? Like to I need to do an ALU no-op for them to load properly into temp regs?
glisse: agd5f: you need to pay extra attention to node things
agd5f: glisse: do you recall if I need an extra node for multiple tex instructions?
agd5f: it doesn’t seem like I should
glisse: agd5f: let me check i remember better when looking a r300_reg than by looking at doc i have 🙂
glisse: you need node only when you are doing a texture indirection and you don’t in your case
glisse: agd5f: lot of incoherency btw 1 & 2 in texture stack again at 1532
glisse: if you pick 2 you need it to be 2 their too
agd5f: glisse: whoops. yeah
agd5f: although it used to be 1 throughout, but I changed it to 2 at some point, but missed a couple places it looks like
glisse: agd5f: also doesn’t alu size need to be 1 ?
agd5f: glisse: but there’s only 1 alu instruction. I was under the impression that field was for max alu instruction used, but I could be wrong
glisse: agd5f: yup 0 is okay in fact
agd5f: glisse: do you think perhaps my VS setup is wrong?
glisse: agd5f: i haven’t look to vertex shader but they are lot easier
glisse: i trying to refresh my memory on this
agd5f: glisse: it should be basically just a noop, just pass the vertices through
edgecase: how do i find what git i’ve got, the big hex number…
agd5f: edgecase: you mean the latest commit in your tree?
airlied: agd5f: remove the VAP 🙂
edgecase: iono, posting a bug report, i want to say what version i have
agd5f: airlied: heh, then I’d have to fix the VAP to GA routing 🙂 I’m not sure which is worse
airlied: agd5f: just use 7 for Texture 1 🙂
glisse: waooo r300_demo look weird to me now
glisse: i used to understand each line 🙂
agd5f: airlied: do you understand how the vector slots in the PSC regs work for the tcl case?
airlied: agd5f: not at the moment in my brain 🙂 but I can look later ..
airlied: I think they are pretty much generic, i.e. you feed things into them and then the vp uses them..
airlied: there are no set functions for them, but many have suggested uses.
agd5f: airlied: yeah, I’m just wondering why the original code picked 10 for the second set of data rather than 1
agd5f: in the non-tcl case I guess they map to GA inputs
airlied: yup in the non-tcl they are direct mapped.
glisse: agd5f: so fixing texture unit didn’t help ?
agd5f: glisse: nope
agd5f: well, you mean the RS IP setup?
glisse: well all incoherency btw asking for unit 1 in prepare then telling 2 to rsunit and finaly using 1 in fragprog 🙂
agd5f: right. I changed it all to 1 🙂
glisse: agd5f: well otherwise fragprog looks good
glisse: wish i finished my new r300 demo, would help to easily test such things
glisse: agd5f: btw there is a typo in the r300 document for US_TEX_INST SRC_ADDR field is 6 bits big
glisse: well more exactly bit 5 is used to select btw const or temp
agd5f: glisse: no, it’s right. it’s a tex inst
agd5f: tex wouldn’t come from a const
glisse: agd5f: but how you select src addr from a const ? iirc this possible directly
glisse: oh it seems this isn’t
glisse: why in hell we did put that in r300
simpsonc-class: glisse: I’m still not quite sure how the pipe looks internally. There’s a lot of things in the r300 frag prog code that just doesn’t make sense to me yet.
simpsonc-class: But thanks for your help. Hopefully it will eventually make sense.
glisse: simpsonc: well fragprog are complex due to this sync things, r500 is even more complexe due to trick you can do for loops & texture synchronization
glisse: agd5f: the key of your problem might be somethings about this const things
glisse: agd5f: r300 re shows it
hosle1: yo
agd5f: glisse: what do you mean? I don’t see why I would use a const
hosle1: So how can I get a card to show up in the /dev/dri section?
agd5f: hosle1: make sure you have the drm loaded
glisse: agd5f: you provide texture coordinate through routing same right ?
phedramine: hello everybody
glisse: ie you don’t compute coordinate inside the fragprog
hosle1: agd5f: it is
agd5f: glisse: tex coordinates are passed through from VS
glisse: hosle1: and no message in syslog of dmesg or whereever your distrib print them ?
glisse: agd5f: so try setting bit 5 to 1 for all tex instruction
hosle1: i get drm is initialized
hosle1: thats all
glisse: hosle1: not enought
glisse: radeon should say its initialized if not maybe your card id isn’t added
airlied: hosle1: I only added your pci id to the drm yesterady..
airlied: and maybe I forgot to push it..
airlied: ops I only pushed it to the kernel.
airlied: its in git no.
airlied: now even.. bbl.
hosle1: airlied: when can i use it?
airlied: hosle1: re-emerge it should get it now from git..
hosle1: i got it from git today without using portage
airlied: then just git pull that
hosle1: git clone git://anongit.freedesktop.org/git/mesa/drm && cd drm/linux-core && make radeon.o
hosle1: then make install
hosle1: i should do that again?
agd5f: glisse: doesn’t seem to help
glisse: agd5f: still this bit is correct according to RE & r300_fragprog
glisse: agd5f: btw do you got screen shot of corruption ?
agd5f: glisse: sure
glisse: agd5f: i guess it would be nice if you could ping someone at amd to confirm this const selector bit, but as we have been using it in mesa r300 dri i would surprised if it doesn’t exist
hosler: great, now i dont even have a /dev/dri folder
hosler: Had anyone gotten dri to work on an xpress 1720 yet?
agd5f: hosler: what does your xorg log say?
hosler: that there are no cards in /dev/dri
agd5f: hosler: then the drm isn’t loaded properly
hosler: ok how do i load it properly?
agd5f: hosler: X should load it automatically if it’s installed properly
agd5f: hosler: git clone git://anongit.freedesktop.org/git/mesa/drm && cd drm/linux-core && make
hosler: already did that
hosler: but ill do it again
agd5f: cp *.ko /lib/modules//kernel/drivers/char/drm
agd5f: depmod -a
hosler: cp *.ko /lib/modules/2.6.23-gentoo-r9/kernel/drivers/char/drmcp: target `/lib/modules/2.6.23-gentoo-r9/kernel/drivers/char/drm’ is not a directory
simpsonc: agd5f: “make && make install” should do that for you.
hosler: there is no drm direcotry
agd5f: simpsonc: doesn’t always work for the drm
hosler: it goes in char directory
hosler: im also on a 64bit system, so should i put it in /usr/lib64, or does it matter?
agd5f: hosler: these are kernel modules, not libs
hosler: ok
hosler: so what do i do after i do make
agd5f: hosler: the path may be different on gentoo, but basically you want to replace your old radeon.ko and drm.ko
hosler: ok ill do slocate
hosler: ok i replaced them
hosler: now what
glisse: hosler: reload drm & radeon
glisse: and check that kernel print somethings about radeon being successfully loaded
hosler: OMG there is a card there
hosler: card0 oh i lvoe you card0
hosler: ima reboot and see if dri works
hosler: ok
hosler: so no dri still lol, but i got a lot further
hosler: (II) RADEON(0): Direct rendering enabled
hosler: (II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer.
hosler: (II) RADEON(0): Render acceleration disabled
hosler: so my card is too new?
hosler: now libGL is reverting to indirect rendering
hosler: i have to eat
agd5f: hosler: LIBGL_DEBUG=verbose glxinfo
agd5f: hosler: you probably need to add your pci ids to mesa as well
agd5f: glisse, airlied: I’ve got it working, but the masks are rotated 90 degress and inverted
airlied: agd5f: wierd…
PSYCHO___: hosler: try unmask mesa as testing
PSYCHO___: so you don’t use 6.5 but 7.X
airlied: OMG 30″ is awesome..
PSYCHO___: 2×24 is also cool :-]
PSYCHO___: i would love 4x
airlied: I could setup 30″ + 3×21″ for lolz..
PSYCHO___: but this ga could blow 🙂
agd5f: airlied: SWEET!
airlied: hosler: I’ve just added the pci ids to Mesa
PSYCHO___: is mesa from git stable? i remember that i tryed it few times and it really never survived hibernate/suspend
PSYCHO___: if i try launch any gl app it killed whole x
PSYCHO___: but i dunno how it looks now
airlied: PSYCHO___: we have a snapshot in rawhide and it mostly works.. but DRI2 may still be breaking things.
PSYCHO___: ook i will wait little more and start testing on mucholapka
hosler: airlied: so unmask mesa and install?
airlied: hosler: yes that might work.. no compiz yet though..
hosler: yeah
hosler: i cant install mesa without unmerging xf86driproto
simpsonc: hosler: Doubt it will help, but my technique is to put mesa and drm into package.provided and just use the git trees directly. Same with xf86-video-ati.
simpsonc: airlied: Your r500test branch looks awesome, even though it doesn’t build due to a lacking DRM.
airlied: simpsonc: the drm is in the r500-fp branch of my drm repo 🙂
airlied: simpsonc: I sent it to you yesterday but you may have disconnected before reading it
simpsonc: does a little dance
hosler: how do i get mesa with git? i cant do it with portage. its freeking out of me
simpsonc: I keep my trees in /usr/src, so “cd /usr/src; git clone git://anongit.freedesktop.org/git/mesa/mesa” would be my command.
airlied: replaced drm with mesa in the url you used for the drm
simpsonc: Oh, before I forget, is there any way to recover from an Xorg hang besides sshing in and killing X?
airlied: simpsonc: nope.. not usually..
airlied: two machines is always useful for X/3D devel.
simpsonc: Damn, going to have to go pull out my old workstation then.
simpsonc: airlied: Yep, new DRM enables new Mesa to be built.
simpsonc: Gonna tweak DRM to acknowledge my card, and then Mesa will be able to lock up X again. Good times.
hosler: ill be back tomarrow
hosler: i have to sleep
simpsonc: airlied: How long have you been sitting on this stuff? This is the exact same stuff I’ve been slowly trying to write for a week! Awesome!
rx__: he has a backlog of patches 😉
simpsonc: rx__: Well, but who wrote it? This stuff looks like what I might write if I weren’t a dimwit. It’s amazing!
airlied: simpsonc: I wrote the drm stuff 26 hours ago..
airlied: simpsonc: according to git and it know better than me 🙂
airlied: the mesa stuff I wrote last night so say 12 hours ago
simpsonc: *ahem*
simpsonc: pulls out Quake voice
simpsonc: EXEMPLARY!
simpsonc: No more hangs, just errors. Yay?
agd5f: simpsonc: does it draw anything?
simpsonc: agd5f: No, but it gives “drmRadeonCmdBuffer: -22”, which I’m trying to find right now.
simpsonc: Also doesn’t hang.
simpsonc: Okay, so it’s a bad ioctl in drmCommandRead, which is in libdrm.
simpsonc: The errno is EINVAL.
simpsonc: And that’s all I know so far.
simpsonc: Oh, also the error is persistent, and it looks like glxgears cleans up and exits without any segfaults when it happens.
simpsonc: Oh, and it doesn’t draw anything, just opens and then immediately closes the window.
agd5f: airlied: WOOT!!!!!! got r3xx render working
rx__: jaw drops
simpsonc: pants drop
simpsonc: Aw, wait. I’m doing it wrong.
edgecase: covers eyes
edgecase: dang too slow
RoiDuClapier: agd5f: You mean full RENDER extension working?
agd5f: RoiDuClapier: yes
simpsonc: Nice.
RoiDuClapier: agd5f: Interesting stuff… when will it be available?
rx__: congrats 🙂
agd5f: RoiDuClapier: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r3xx-render
agd5f: rx__: thanks
RoiDuClapier: Wow, that is fine
rx__: if only it were easy to modify that for r5xx 😉
agd5f: rx__: should be easy
agd5f: rx__: I’ll probably take a stab at it tomorrow
rx__: hey that’s cool
agd5f: not that I understand the rasterizer
agd5f: s/not/now/
rx__: oh.. hehe
rx__: totally different meaning
RoiDuClapier: agd5f: Does your work on r3xx render a result of AMD doc release?
agd5f: RoiDuClapier: more or less 😉
partymola: agd5f: gotta try it right now with my XPRESS 200 Mobility card 🙂
RoiDuClapier: agd5f: I know that the driver was before the doc release in pretty good shape since I use that for my desktop. But those progress will enable some more performance improvement. I’m impressed with the work done at present.
RoiDuClapier: I’m trying to delve into graphics driver writing and it is pretty a complicated matter
RoiDuClapier: A little question. Is it possible to kill a hanged X with ssh’ing? For example in a chrooted environment?
agd5f: RoiDuClapier: depends on the hang
RoiDuClapier: If it is caused by the graphics driver
RoiDuClapier: May be a deamon monitoring X I tought
simpsonc: RoiDuClapier: In many cases, yes. Try it.
RoiDuClapier: simpsonc: OK I will
partymola: agd5f: how do i active the render extension? just by: Option “RENDER” “Enable” in the “Extensions” section?
agd5f: partymola: Option “AccelMethod” “EXA” is all you need
partymola: agd5f: done
partymola: how can i know it is working?
agd5f: partymola: restart X and see if it’s faster
agd5f: or if it even renders correctly
partymola: it renders ok
partymola: but same speed, i think
agd5f: partymola: are you using my branch?
partymola: no, just the standard branch
partymola: where is yours?
agd5f: partymola: http://cgit.freedesktop.org/~agd5f/xf86-video-ati/log/?h=r3xx-render
agd5f: r3xx-render branch of xf86-video-ati in my personal repo
partymola: how do i download the files… ?
agd5f: partymola: git clone git://people.freedesktop.org/~agd5f/xf86-video-ati
partymola: ok
partymola: sorry, but i am very new to git 🙂
agd5f: git checkout -b r3xx-render origin/r3xx-render
simpsonc: Holy ****!
simpsonc: No crashes!
simpsonc: And it draws GEARS!
simpsonc: dances
RoiDuClapier: agd5f: Before I try your version, is EXA working good? I am currently using xf86-video-ati-6.8.0 under gentoo and every thing is slow with EXA, especialy with GTK+ apps.
agd5f: simpsonc: awesome!
simpsonc: trips over pants
rx__: simpsonc; what card?
agd5f: RoiDuClapier: yes
simpsonc: Radeon Mobility X1700. M66 (RV515 with couple extra pix pipes)
rx__: ooo
simpsonc: airlied: You are awesome.
rx__: i should test with my m56
simpsonc: Branches are r500test and r500-fp or similar in airlied’s mesa and drm trees.
rx__: btw.. i wouldn’t call x1700 rv515
rx__: rv515 is teh suck
simpsonc: rx__: It’s technically RV535, which is RV530, which is RV515, not R520.
simpsonc: http://dri.freedesktop.org/wiki/ATIRadeon
simpsonc: But it’s no wimp.
airlied: simpsonc: what draws hears?
airlied: gears even?
simpsonc: airlied: glxgears draws gears.
simpsonc: At 900 FPS with no crashes.
airlied: that crap code I wrote?
simpsonc: Aye.
airlied: I didn’t even test it…
simpsonc: Ah, wait.
airlied: I bet you hit sw fallback 🙂
simpsonc: That’s with SW Mesa.
simpsonc: Yeah, indeed.
rx__: haha
airlied: hehe.. yes.. no way my code could draw stuff 🙂
simpsonc: Gonna do this again. If I vanish and come back in five, it’s because I got a lockup.
airlied: agd5f: excellent on r300 render…
agd5f: airlied: thanks!
RoiDuClapier: airlied: But it draws our attention 😉
airlied: agd5f: I’ll have a look at the code and if I help on RS 🙂
agd5f: airlied: the finishing touch was offset if the second texture within the input packet
agd5f: s/if/of/
simpsonc: Dang, DRM problem is still there.
airlied: simpsonc: might be my FP upload stuff.. or it could uploading atoms the r500 doesn’t support
simpsonc: airlied: It’s EINVAL from drmCommandRead, called from drmRadeonCmdBuffer in r300_cmdbuf.
simpsonc: Don’t really know why. Yet.
airlied: simpsonc: most likely for submitting registers the r500 can’t handle
simpsonc: Probably.
simpsonc: So, submitting r300 regs that aren’t supported on the r500? Hmm.
airlied: you might have something in dmesg
airlied: simpsonc: I blocked a bunch of regs that moved.
airlied: simpsonc: and added r500 regs
partymola: agd5f: i got rendering issues 🙁
agd5f: partymola: no VAP 🙁
simpsonc: airlied: Got something, one second.
partymola: VAP?
agd5f: partymola: well, it has a VAP , but no vertex shader
partymola: ah
partymola: well
agd5f: partymola: RS chip 😉
partymola: windows look weird
partymola: you know, deformed
partymola: like wrong rendering
partymola: but, i.e.
partymola: xterm looks good
partymola: and glxgears renders well
partymola: but gnome does not
partymola: and no speedup 🙁
partymola: (I am using a XPRESS 200 Mobility, under FreeBSD 7.0, with X.Org 1.4)
simpsonc: airlied: Found the line that’s dying, now looking for the cause.
airlied: simpsonc: I’m guessing the code still emits FPI or RS state wrong.
simpsonc: airlied: Had to use some tricks to get a debug trace without the constant background chatter of the CP. Looking at it now.
simpsonc: airlied: http://pastebin.com/m2fecc1a3
simpsonc: Something’s causing massive numbers of R300_CMD_PACKET0, and I think that’s not right.
airlied: simpsonc: ah it might be my cmd_r500fp stuff
airlied: simpsonc: that just lots of submissions..
simpsonc: airlied: Okay, it’s r300_emit. Not putting in a value somewhere…
simpsonc: Can anything be done with “dd0dc1c0”?
simpsonc: Oh, wait, I have teh src, lawl.

Radeon IRC Logs For 2008-3-17

Rig Lab Hardware

You Might Also Like

RadeonHD.org | Radeon IRC Logs For 2008-5-02

RadeonHD.org | Radeon IRC Logs For 2008-11-06

RadeonHD.org | Radeon IRC Logs For 2008-12-14