MostAwesomeDude: The r300 questions have all been answered except for one.
airlied: arrgh finally, radeon has gears.
kcodyjr: MostAwesomeDude, what's that one
MostAwesomeDude: Q: On r300, is it more efficient to push fog blending (or fog-like maths) from fragment shading into the fog block, or to do said math in the shader block instead?
kcodyjr: that's a pretty low level question ;)
kcodyjr: (and wtF has happened to git and libcurl on that box. i got mice peeing on the southbridge or something?)...
MostAwesomeDude: kcodyjr: And it's also an unanswered question. But pretty much all other questions about the HW are figured out.
kcodyjr: is radeon not hosted at fdo?
oga: if you mean the ddx
kcodyjr: i mean xf86-video-radeon
oga: yes. that would be stored in xf86-video-ati
kcodyjr: ahh, do i want the master branch or even the master repo? for kms userspace?
kcodyjr: growl. version dependency? video-modesetting wants a package called 'xvmc' which gentoo seems unaware of.
kcodyjr: i'm thinking i ought to just call it a night and come back after a brain reset.
kcodyjr: hmm. yeah, it does seem that the master repo has no modesetting support. i found xf86-video-ati-airlied, i assume that's it? radeon-gem-cs2 branch?
kcodyjr: throws my hands up in frustration. that wants dri2.h; that means xorg-server version i think? i really am going to bed. ;) catch you guys tomorrow, my focus for now is getting some piece of code installed and working which will let me test r600 cs as i integrate it. a ddx would be nice but any old test harness will suffice. 'night...
MostAwesomeDude: kcodyjr: dri2proto.
kcodyjr: MostAwesomeDude, that is one most awesome answer. ill start the ebuild before crashing, thanks
airlied: nha: hey, so I haven't do major DRI2 testing yet, I just integrated glisses work.
airlied: if you find instability try EXANoComposite as a workaround, I suspect the state emit needs work
airlied: I just got gears going on radeon again here, so I'm going to start playing with piglit on r100/r200 on legacy codebases now
airlied: then I have to do r100/r200 userspace clears
nha: I see
nha: do you have a theory about where the strange modesetting behaviour might come from?
nha: I noticed that in the subsequent X sessions where the largest resolution is 1024x768 instead of 1280x1024, there is a video mode with a resolution of 0x0 at 0Hz
nha: some kind of strange memory corruption where a pointer gets messed up, maybe?
airlied: nha: I think DDC sometimes fails for some reason
airlied: I need to take a detailed look at the timings
osiris_: airlied: did you try on r300 with hw tcl?
airlied: nope only on r500
airlied: I don't have an r300 anywhere easy to use at the moment
MostAwesomeDude: osiris_: Which branch is this based on?
MostAwesomeDude: If it's based on classic Mesa, I could test right now...
MostAwesomeDude: Wait, actually, nevermind. Can't test right now.
osiris_: MostAwesomeDude: yes, it's based on master
MostAwesomeDude: osiris_: If you have a link, I can check when I no longer have to worry about hardlocks.
osiris_: MostAwesomeDude: http://pastebin.com/m42e72465
MostAwesomeDude: osiris_: 'k, will check later.
osiris_: airlied: could you test it on r500 with forced sw tcl?
airlied: osiris_: will do tomorrow
osiris_: airlied, MostAwesomeDude: here's updated patch http://pastebin.com/m5287267f
osiris_: MostAwesomeDude: : is 1WWW swizzle legal in vertex program?
MostAwesomeDude: osiris_: I think so?
jaggz-: hi :)
jaggz-: I have an older card (7000) in this server -- and I just updated debian etch->lenny. My graphics seem slower, and then locked up and crashed when I ran a 3d graphics app. I'm using the radeon driver and the xorg.conf driver is set to "ati".
jaggz-: the 7000 is considered R100/R200
jaggz-: graphics seem different than they used to.. as if I were in a higher resolution than the 1600x1200, although I am in 1600x1200.
jaggz-: ATI Radeon VE/7000 QZ (AGP/PCI) that's it.
osiris_: agd5f or bridgman: could you find out what's the formula for point size modifier vertex attribute (if any), and whether there is anything special in non hw tcl about it?
agd5f: osiris_: I'll see what I can find
hifi: hmm, I get some strange tearing on 1080p50 over HDMI
hifi: it's a single line from bottom left corner to top right corner
hifi: when running low resolution stuff in fullscreen I see the whole triangle tear but on 1080p video it's a smaller one flashing at the upper right corner
osiris_: airlied: ping
EisNerd: some one here who could tell me about the diffrences in talking to the asic between radeon/radeonhd and fglrx
EisNerd: I have trouble with dpms, powercord pluging unpluging, suspend
EisNerd: due to the fact that my problems are mostly un mentioned in the net, makes me to believe that my asic is broken
otaylor: EisNerd: if fglrx works and radeon doesn't it most likely means that the driver is at fault, not your hw. (doesn't mean necessarily mean that there is an easy fix)
EisNerd: otaylor: the other way around
ossman: agd5f, all types of poking of the hardware guys today is appreciated :)
EisNerd: otaylor: in oposition to all reviews in the web my comfort is bader than before
EisNerd: or nothing changes in the badnes
otaylor: EisNerd: really hard to say. fglrx doesn't have a good tradition of integrating too well with the rest of the OS, so if it breaks suspend that' not too shocking
EisNerd: otaylor: it was great
agd5f: ossman: will do
otaylor: then why did you switch?
EisNerd: otaylor: with fglrx
ossman: agd5f, I had a look at the docs for r5xx, and the filtering didn't make much sense there either
otaylor: Read the channel topic
EisNerd: otaylor: then the evil begins afaik without altering anything
EisNerd: otaylor: I know
EisNerd: otaylor: the point is my hope that some one here could tell me more about the ways of tweaking the asic in the diffrent drivers
EisNerd: so we could determine if it really is the asic
otaylor: EisNerd: you are not going to be able to debug the fglrx driver (that's what "closed source" means). So don't pretend that we're going to be able give you the information that would you to do that.
otaylor: let you do that
logari81: hi, could anyone tell me if there is a corresponding channel for intel?
MostAwesomeDude: logari81: #intel-gfx
otaylor: EisNerd: I would say that it's unlikely that your hw started to up and give you suspend problems one day. And just with fglrx. When hardware dies, it tends to just die.
logari81: ty MostAwesomeDude, I could not find it
MostAwesomeDude: logari81: It's hiding. :3
onox: I try to run an opengl app (celestia), but it doesn't render properly
onox: do I need to change something in xorg.conf?
PWMx: brigdman: You mentioned the need to skip or double frames in order to synchronize with the incoming broadcast stream rate.
PWMx: IMHO skiping and duplicating should be the very last resort in sychronizing. Simply because it'll introduce motion artefacts. (I.e. not high-definition anymore !)
PWMx: A better idea would be to have refresh rate closely matching the incoming broadcast stream rate - and then finetune the local clock to compensate the remaining offset and drift.
PWMx: CEA-861 says that the display device must accept farme rates within 0.5% of the nominal. (There is also variation of no. lines during vertical balnking mentioned etc.)
PWMx: So I think there should be hooks to vary the frame-rate as allowed by CEA-861. Then larger mismatch should be considered similar to de-interlacing.
PWMx: Both de-interlacing and frame-rate conversion can be seen as a special case of motion-compensated spatio-temporal interpolation ;)
PWMx: And yes, simple frame dropping / duplication and line-doubling are those very crudest (and lowest complexity) algorithms possible..
nha: osiris_: yep, vertex shader swizzle is completely flexible
nha: omg, brianp is going to merge gallium
nha: reports of icicles in hell have just come in
kcodyjr: ducks for cover and starts preparing his tax return
MostAwesomeDude: I only can hope that he remembers to disable radeon drivers by default.
spstarr_work: frantically refreshes cgit to see
nha: he wrote that initially, the old-school build will be the default
nha: this is exciting though
spstarr_work: gallium-master-merge re-add MSAA support Brian Paul 20 min.
nha: did we ever make a decision about how to move forward r100/r200-wise?
MostAwesomeDude: nha: I think that for now, they'll be left in classic Mesa.
nha: I mean, airlied has been working on unification, which is awesome, but both of them just don't fit into the gallium model
MostAwesomeDude: But marcheu may have some diabolical scheme to support them.
spstarr_work: "Oh yeah, we're cookin' now!"
spstarr_work: looks at MAD and grins
nha: MostAwesomeDude: so, which kernel philosophy does your gallium work follow? mm+cs only?
MostAwesomeDude: nha: CS only. Winsys provides functions for getting buffers set up, and I neither care nor need to care how those work.
MostAwesomeDude: MMIO, DRI1, DRI2, etc. should all be possible.
nha: well, there's a winsys/radeon, isn't there?
MostAwesomeDude: But yeah, I'm not making any allowances for non-MM.
MostAwesomeDude: Yeah, the radeon winsys is DRI2 KMS+MM.
nha: I think that's reasonable (not making allowance for non-MM, I mean)
nha: which kernel tree are you working with?
MostAwesomeDude: airlied's drm-rawhide ATM.
MostAwesomeDude: But that's 'cause I'm actually *on* Rawhide.
nha: I wonder if those patches can be sanely split into a batch for memory management and a separate batch for KMS
MostAwesomeDude: Hm. Maybe.
nha: that might make them easier to pass into the mainline kernel
MostAwesomeDude: The only things left (I think) are vert emit and shader assemblers, but each of those are really big tasks.
nha: mind you, I have not looked at all into that code, so if the idea is just too much work, forget about it
MostAwesomeDude: Well, I'm staying out of the kernel as much as possible.
nha: where are those things missing?
kcodyjr: actually, as a matter of interest... is there any official word on what's stopping KMS from getting into mainline?
MostAwesomeDude: kcodyjr: It's just a lot of API changes at once.
spstarr_work: MostAwesomeDude: does your gallium driver render a triangle?
nha: yeah, you want to get the api right
MostAwesomeDude: nha: r300_swtcl_emit and r300_state_shader, but really those are still in flux.
nha: that's why I was wondering whether the things could be split into MM(+CS) and KMS
kcodyjr: MostAwesomeDude, so it would probably be accepted if the old API's still functioned?
nha: then the api changes are not as gigantic
MostAwesomeDude: My idea was to have only simple assemblers for shaders, and then leverage LLVM to do all of the actual compiling and optimizing later.
kcodyjr: thing is nha, KMS really does depend on MM, even just looking at the api
nha: kcodyjr: you also want to be reasonably sure that the api will be stable once it's merged
MostAwesomeDude: spstarr_work: Nope, that's next on the list.
kcodyjr: nha, there is that...
nha: kcodyjr: yeah, but MM first, then KMS ĺater could be possible
nha: though memory management gets kind of nasty if you still have the vt switch problems that go hand in hand with not having kms, as far as i know
kcodyjr: the question is whether there's any real gain in splitting them up like that
kcodyjr: since the MM stuff has little bearing on the old way of doing things, either you're using it or you're not
kcodyjr: KMS, however, introduces ioctl incompatibilities, among other things
nha: true, I just thought it might be easier to get it merged upstream separately
kcodyjr: i'd say the MM stuff is simply a drm.ko update, requiring a lower degree of scrutiny than the KMS stuff which really is a fundamental change
nha: kcodyjr: and still, we have a shitload to gain with the MM stuff, arguably even more than with KMS, at least in the short term
kcodyjr: yes, but rather less so to gain from pushing it into mainline: the MM stuff is just as happy to be built outside the kernel tree. KMS (at least where set-it-once boot-time modesetting is concerned) is what needs to be compiled-in to the kernel
kcodyjr: and, MM has little impact outside of DRM; whereas KMS changes console behavior significantly
nha: ok, so why is the MM stuff not at least in the drm.git master? because that prevents us from officially releasing a libdrm that supports it, which prevents us from officially releasing a ddx and mesa that supports it
kcodyjr: that's a good question which i have not yet thought to look into. my first guess would be, the api stability issue.
nha: yeah, probably
oga: nha: not having the mesa would be a good start
kcodyjr: with any luck the patchsets i'm working on for airlied will help appease the upstream guys for KMS, but yeah it does seem like merging modesetting-gem to drm.git master is a prerequisite...
nha: oga: you mean, we should get more experience with an actual working mm-based mesa?
nha: that would make sense, I admit :}
oga: nha: well right now we don't have one.
nha: what about in airlied's tree?
nha: at least for me it seems buggy, but it exists
ossman: agd5f, has anything fun fallen out of the hw guys from the poking? :)
agd5f: ossman: haven't heard anything back yet
ossman: bridgman found some confusing docs yesterday. would you be able to share those for now?
agd5f: I found the same docs
nha: Matthias Hopf's slide mention a shader compiler from AMD
nha: that sounds exciting
nha: ... exciting enough for me to close the wrong window, anyway
agd5f: ossman: looks like we should probably do bicubic the old way.
agd5f: bicubic filtering was dropped in r7xx
ossman: agd5f, completely? or back to the r5xx way?
agd5f: ossman: on the shaders like we did for r3xx-r5xx
ossman: agd5f, yeah, but I was thinking of the filter4 stuff added in the r5xx. a 4x4 filtering kernel should be able to do lots of fun :)
agd5f: ossman: yeah that filter4 stuff is only on r5xx and r6xx
agd5f: it's dropped on r7xx
agd5f: TobiasTheCommie: probably better use of solicon to do it on shaders
TobiasTheCommie: ah, oki
osiris_: agd5f: did you find out anything about point size?
agd5f: osiris_: not yet
airlied: nha: drm.git master isn't anything anymore.
airlied: if it isn't in the kernel proper there is no release for it
airlied: I'm not going through API changing shit yet again
airlied: nha: so really once we have a reasonably performat 2D/3D and use the newer TTM code I'll start looking at upstream
airlied: as otherwise I think we'll freeze the API too early
airlied: MM without KMS is probably possible but VT-switch + getting back text mode + tearing down stuff just left me feeling dirty
airlied: so I decided it wasn't worth it, you get MM+KMS at once.
kcodyjr: airlied, sounds like time for a night out with that Haskell chick... ;)
airlied: the less paths we have to test the lest regressions we end up with
nha: airlied: that sounds reasonable
nha: airlied: but if drm.git isn't anything anymore, then where's libdrm?
airlied: nha: or sorry libdrm is drm.git :)
airlied: thats its main use :)
kcodyjr: airlied, but any kernel code i find in drm.git is either dated or just a temporary sandbox?
airlied: kcodyjr: depends, nouveau is based in there
airlied: but really anything stable needs to be in a upstream kernel tree, the API assumptions are just too messy otherwise
kcodyjr: nouveau == temporary sandbox in this context, i think
PetoKraus: stupid question - does radeon support dual head display? on X600?
peterz: airlied: agd5f: how usable is the r6xx-r7xx branch, and can I get away with just building that branch or do I need to upgrade more stuff?
agd5f: peterz: works great here. you'll need the drm kernel modules from the r6xx-r7xx-support branch of the drm
airlied: peterz: you need libdrm modules as well
airlied: drm even.
airlied: PetoKraus: should do.
kcodyjr: hrm. what do i need to have 'drm_bo_type_t' ?
spstarr: looks at airlied's mesa git bits
spstarr: airlied: man you're blowing up code all over the place :)
kcodyjr: hrm. perhaps i don't have the right xf86-video-modesetting sources?
spstarr: kcodyjr: looks like libdrm bits
spstarr: but im not sure if that type is a kernel or or from libdrm
kcodyjr: spastarr, yeah it's referenced in xf86drm.h, but i don't see where it's defined - i'm using drm.git modesetting-gem
spstarr: that looks to be from xserver
spstarr: git xserver?
spstarr: which Xorg version
spstarr: 1.4? 1.5?
airlied: kcodyjr: the code might be in gallium now :)
kcodyjr: epm -qf /usr/include/xf86mm.h tells me libdrm-2.3.0
kcodyjr: i've got server 1.3 installed, i'm working over portage dependencies
kcodyjr: airlied, i hope not... you know i like gallium but i shouldn't -need- it installed to get an unaccelerated ddx running...
kcodyjr: certainly not while there's still channels with "i don't wanna hear about gallium" in their titles, such as #nouveau
spstarr: 1.3 is so.. old ;)
kcodyjr: spstarr, it's what gentoo has marked stable for x86_64
spstarr: funny, I thought gentoo was the bleeding :)
kcodyjr: architecturally it is. KEYWORDS= is intended to put a brake on that so it becomes possible to have a stable installation.
airlied: I'm a gonna guess modesetting ddx isn't in the that git tree
kcodyjr: modesetting ddx isn't in xf86-video-modesetting ???
airlied: I've no idea, the was the initial attempt at doing one, it might have been deprecated
airlied: since you need some memory manager interface its not really possible to do a compeltely generic DDX
kcodyjr: ok let's think this through from two separate angles
kcodyjr: A) bottom line it for me, what must i install to get the current known codepath working
kcodyjr: and B)... to get basic X drawing to framebuffer, what's needed that isn't in the modesetting-gem branch. that looks sufficient to me.
airlied: kcodyjr: there is no current known codepath for r600 kms + accel
kcodyjr: at this point i don't give a tinker's damn about accel
airlied: for r600 kms without accel, the kernel you have + my radeon brnach
kcodyjr: i'll dance a jig if i can see an x startup pattern with modesetting active without relying on luck with radeonhd ;)
airlied: the problem with a generic DXDX is that memory management isn't a DDX
airlied: so you really need something in libdrm or somewhere to do allocate and map me a framebuffer
airlied: or have code in the geneirc DDX to do it
kcodyjr: the final activation call is drmModeAddFB, correct? that's what needs to be satisfied?
airlied: yup you need a handle for a framebuffer to give to it
kcodyjr: specifically, a bo_handle?
airlied: yes which isn't generic.
kcodyjr: what can i read to learn about that
airlied: well you get a bo handle by calling the driver memory manager
airlied: the entry points are driver specific
kcodyjr: would have to be one of the ioctls then?
airlied: the Intel GEM alloc, radeon GEM alloc
kcodyjr: don't see alloc's. DRM_RADEON_GEM_CREATE ?
airlied: ah create sorry
kcodyjr: so what parts of gem -aren't- driver specific?
kcodyjr: it's almost like it's more of an api guideline than an actual api
airlied: kcodyjr: the simplest bits
b0le: On fedora 10, using standard X/mesa packages. If I start compiz, then kill it, then start it again X dies. It is spamming "__glXDRIbindTexImage: Failed to register texture offset override" in the log file. Here is Xorg.0.log.old with most of the spam cut out: http://pastebin.ca/1332286
b0le: compiz starts fine initially, it is only the second time that X dies. This happens with both the packaged version of compiz, and master. Additionally, I have nomodeset in my boot parameters (otherwise compiz doesn't even start - it just locks up)
kcodyjr: reading through i915 and radeon, the create calls look compatible
kcodyjr: but what else would i need to do for the bo to be a valid framebuffer
kcodyjr: i don't see why all of these GEM ioctl's need to be driver specific... rather i'm seeing what ought to be ioctl's defined in drm but required to be implemented by the driver, and i'm unsure that create couldn't do with a common implementation
airlied: kcodyjr: tried that, ended up with TTM interface, fail.
airlied: you end up having to know for each driver what the secret incantation of flags to allocate a buffer sutiable for scanout
airlied: so the function call is the same name, but the args are per-driver and you save nothing in the end
kcodyjr: which is the same thing we've got with different call semantics
airlied: except you probably overoptimised the API for allocating scanout buffers
airlied: when that isn't its main job in life
airlied: kcodyjr: not really, you can't assume you know what the API is going to do.
kcodyjr: yet we still don't have anything which can serve as a "gimme a scanout buffer" call, which seems like a pretty necessary thing ;)
airlied: kcodyjr: depends on who you are aiming at.
airlied: if people are going to want to use accel at any point then they need to know more than that
airlied: its easier to just write a userspace wrapper in libdrm which we might do for wayland at some point
airlied: I think we also need it for plymouth
kcodyjr: certainly, but it's also not fair to say that if your card is too old to support the latest accel models (shaders) then suck eggs with the legacy drivers; from a practicality point of view, having a driver that can just fire up under the new kernels on whatever you find is a necessity
kcodyjr: acceleration or not; i'm talking about the fbcon ddx / vesa ddx / whatever of the new kms world order
airlied: kcodyjr: its prefectly fine to say that
airlied: legacy cards == legacy drivers
kcodyjr: there's legacy and then there's legacy
kcodyjr: and you run into problems with distros getting zealous
airlied: kcodyjr: with an allocate scanout in a libdrm helper lib you could wrap the ioctls for each driver easily enough I suspect
airlied: or just do it in the DDX.
kcodyjr: remember i'm coming at it from an i.t. department point of view rather than a full time developer's
kcodyjr: i'm going to attempt just that
airlied: IT depts buy distros like RHEL if they are any good
kcodyjr: only if their pockets are deep
airlied: any IT dept using anything unsupportable deserve the pain :)
kcodyjr: the rest of us use centos when possible and something else when more recent features are really needed
airlied: nuts 13 piglit regressions on radeon.
kcodyjr: i think i've been good about keeping my own wacky ideas separate from any work i try to get done from you - i'd like to keep pushing on that patchset but i'm unsure how to proceed from here
airlied: well I think the next hard bit is getting r600 accel going with kms.
airlied: and thats going to be a lot fun I would suspect
airlied: also really requires the documents from Alex.
airlied: I think the r300 CS scheme will need a new reloc type
kcodyjr: which i could potentially do by reading through the bastard line by line, -if- there's a single codepath that does work using the new model, but it seems i'm going to have trouble installing it unless i want to get bleeding-edgy with my base packages
airlied: kcodyjr: it doesn't really port
airlied: the new model uses the chip a bit different, and how relocs work is very different
kcodyjr: i was getting that feeling by reading it
airlied: also the IB command submission from the old model is unchecked
airlied: for the new CS we combined X and Mesa command submit methods and they are all checked
airlied: so there is no example r600 command submit at all, IB is way basic
kcodyjr: then proceeding on that front is over my head at least so long as the docs aren't public
kcodyjr: sounds like there's nothing further i can do on that thread and i ought to turn my attention back to the edid parsing?
airlied: it might be possible to start but I'm not 100% sure how its going to look myself, so it would be a lot of fun in the dark.
kcodyjr: i don't need to see the whole light but i do need at least a flashlight; without a functional guide i'll be SOL on that one
airlied: you should get -ati working on r600 to make sure that stuff work
kcodyjr: i need to know what it's trying to achieve at least. i can deal with vastly different algorithms and approaches but i do have to know what the target is.
airlied: using my branch
kcodyjr: ok i've got it checked out. it wants dri2.h. server version?
kcodyjr: i installed that, it gave me dri2proto.h
airlied: ah then server, it could do with a proper dri2 detect
kcodyjr: ;) ain't that pissah, love gentoo sometimes :(
airlied: 1.3 is too old for mode setting anyways
airlied: 1.4 introduced the necessary hook I think
kcodyjr: if you assume the model that the x server -shouldn't- set the mode, i was well on my way to making it work
airlied: it still needs something to pick modes that is network transparent
kcodyjr: XVidMode you mean? i'm of the opinion that actual modeswitching should be prohibited on a fixed resolution display
kcodyjr: but acknowledged; technically it would be a crippled driver if i did that
kcodyjr: just not necessarily any real disadvantage
kcodyjr: anything look missing or unwise in this update list? http://pastebin.com/m5ec0452b
airlied: should be good