Nightwulf|work: hi all
Nightwulf|work: hm....radeonhd-git still not buildable :/
telmich: good morning
telmich: Nightwulf|work: that's what I wanted to check in a few seconds, but thank you for the information!
Nightwulf|work: telmich: do you need the whole error output pasted somewhere?
telmich: Nightwulf|work: I guess it's similar to yesterday -- but just put it somewhere
Nightwulf|work: telmich: just posted the relevant part -> http://phpfi.com/340927
Nightwulf|work: telmich: btw...why does configure tell me DRI support is disabled despite the fact i didn't use --disable-dri ???
Diablo-D3: it might not have found an appropriate version
Nightwulf|work: strange
Nightwulf|work: libgl 7.0.3 installed here
Diablo-D3: you usually need dri, drm, gl, and the x server and all the x libs from git or whatever
Nightwulf|work: all in place
Diablo-D3: dunno then
telmich: Nightwulf|work: you are missing libdrm-dev most likely
Nightwulf|work: telmich: I'll double check...thx
telmich: Nightwulf|work: have a look at configure.ac, where it checks for DRI, that explains most what's missing
Nightwulf|work: ah...thx
Diablo-D3: see above where I said you needed drm
Nightwulf|work: Diablo-D3: and i said it's in place...out of that reason i said to telmich that i'll *double* check
Diablo-D3: er, you need say double
Nightwulf|work: double checked...libdrm-2.3.0 (headers included) is installed...hmm..investigating configure.ac
telmich: Nightwulf|work: hehe, german guy
telmich: Nightwulf|work: LANG=C make is mostly more helpful for non-german speaking people
Nightwulf|work: telmich: yeah...made the same mistake yesterday....I'll have to get used to it :P
Nightwulf|work: ok..solved...xf86driproto was missing
telmich: Nightwulf|work: that's one of the reasons, why locale is evil (though I've de_CH.UTF-8 here ;-)
Nightwulf|work: telmich: no...not locale is evil...habits are evil :P
Nightwulf|work: telmich: next part of the problem is, that we program only for our companies own purposes, no part of the software gets sold...so the language of all comments and variable/method names are german...this leads to german locales too :P
telmich: Nightwulf|work: ooooooooh
telmich: Nightwulf|work: that's _really_ evil
telmich: had to debug french python code once
Diablo-D3: ye gods, python, but _french_ python? thats horrible!
Nightwulf|work: telmich: yeah..that's why i use english variables/methods/comments only in private projects
Nightwulf|work: telmich: but most evil stuff i've ever seen is code with russian comments
LoneTech: thank you yet again :)
LoneTech: I'm now using radeonhd CS + DRI on my m54. It's mostly working.
LoneTech: it does annoy that it crashes after lid close, though
LoneTech: apparently it reinitializes to a nearly fully working text mode. a few characters are missing, including .:/
LoneTech: and after that a VT switch makes Xorg quit.
LoneTech: closing and opening already on another VT does not cause the problem
LoneTech: backlight levels DO work, though. This is on a thinkpad z61m.
mikkoc: LoneTech: is the cs branch better than master?
LoneTech: I don't know. I figure the support for simultaneous 2d and 3d accel may be a CS thing.
mikkoc: i see
mikkoc: have you compared it to radeon?
LoneTech: not recently
LoneTech: the RadeonFeature page seems to think I should, though.
LoneTech: wanders off to test
LoneTech: ok, that worked with lid close and dri. I'll test further.
LoneTech: xv fails and vblank syncing still doesn't work. best solution for the moment, though.
Diablo-D3: heh
Diablo-D3: wouldn't mind if suspend worked
Diablo-D3: suspend, gl, and xv need to work, in that order :<
LoneTech: oh, it's not suspend; just closing the lid
Diablo-D3: ahh, I wasnt implying it was
LoneTech: in my tests anyhow
Diablo-D3: closing the lid doesnt do anything on most laptops anyhow
Diablo-D3: just generates an acpi event
Diablo-D3: in some laptops it directly tells the hardware to shut the backlight off
LoneTech: Xorg reacts to acpi events, though, and in this case does something wrong.
Diablo-D3: it /can/ react to acpi events
agd5f: LoneTech: master support simultaneous 2d and 3d as well
agd5f: CS is just an experiment at making mmio command submission more like CP
LoneTech: agd5f: ok
libv: well, i'll see whether i can clean up my r5xx direct cp code and stuff that in as well
libv: LoneTech: not sure whether that issue is CS related though...
libv: LoneTech: can you get me a log with the backtrace in?
LoneTech: possibly, if I get instructions
LoneTech: it doesn't actually crash on lid open though; it crashes when I try to switch VT after that
agd5f: for the lid, you have to set the right bios scratch regsiter bits to prevent the bios from screwing around with the hw
LoneTech: but it's running a text mode when the lid is opened.
LoneTech: agd5f: sounds about right. I've no clue how to do that, though.
agd5f: LoneTech: radeon does the right thing. Egbert might have ported some of that in the atombios branch
LoneTech: yes, radeon does work. it also thinks it has xv, but that does not work
agd5f: LoneTech: using compiz?
LoneTech: no, I'm just running ion
libv: LoneTech: so X segfaults on going to the VT during a lid event... hrm
LoneTech: to be precise, after a lid close+open, X still runs, but it's not in graphics mode. It's in a text mode. At that point, trying to switch VT causes it to crash.
libv: hrm... but why does it switch to vt in the first place? it's just lid events
libv: LoneTech: is your distribution trying to do some stuff based on an acpi event?
LoneTech: only running laptop-mode
LoneTech: afaict it doesn't switch vt on its own. it does go to text mode. might be a bios thing
telmich: libv: hello! did your get your hands on the m54?
libv: telmich: nope, and i still need to get the m56 out
libv: telmich: lonetech here is also using an m54 :)
telmich: LoneTech: ahh, which system are you on? t60?
libv: weird how some characters in textmode are messed up there too
LoneTech: Z61m
telmich: LoneTech: at least same vendor :-)
libv: i thought this was only an issue on more recent r6xx and r7xx chips
LoneTech: it's just the font isn't fully loaded; consolechars can fix that
libv: LoneTech: do you also get a message about the VGA aperture not being in the main FB aperture?
LoneTech: not that I've noticed, but if you tell me where I can look for it
libv: "VGA FB Offset" is part of the string sent to the log
libv: it's actually an error
libv: so (EE)
LoneTech: then no. I searched for EEs.
LoneTech: why were you looking for M54s? is there some test I could help with?
libv: LoneTech: we still have some issues remaining with the panels on m54
agd5f: LoneTech, libv: whne the bios gets a lid event to tries to program a text mode (ie. wake up the screen), you need to set the necessary bios scratch bits to keep the bios from doing that
libv: even though part of that was already solved
libv: agd5f: ok... but our driver should disable those io ranges so this cannot happen
agd5f: libv: perhaps some bioses so something differently
libv: right... wouldn't be the first time :)
LoneTech: that problem doesn't occur with the radeon driver, though
LoneTech: I'd be pretty satisfied if I could just get vsync to work
LoneTech: (in mesa)
agd5f: LoneTech: set ATOM_S6_ACC_BLOCK_DISPLAY_SWITCH and ATOM_S6_ACC_MODE in bios scratch 6
agd5f: reg offset is 0x28
LoneTech: agd5f: I don't know where to put that
LoneTech: I can confirm that bit is not used in my radeonhd driver, but is used in radeon_driver.c
LoneTech: so you're probably right about it solving the problem
agd5f: LoneTech: yeah, those are the bits you need to set
boris64|alive: Hi folks, i have a (dumb/simple?) question. Is there a way to force vsync=on with the radeonhd drivers? I can use the newest git snapshots with my radeonhd (well, without video acceleration, but hey), but the tearing of my kaffeine dvb video (using the x11 driver) is driving me crazy. Any hints? thx in advance ;)
yangman: boris64|alive: there's no vsync support in radeonhd afaik. if you have a chipset that is supported by Xv, a tearing fix went in yesterday.
boris64|alive: yangman; I have a new 4870 chipset, i can't use any xv (yet).
yangman: ah. not much you can do, then
boris64|alive: yangman; ..., but, the joke is, radeonhd works great in favour of fglrx. The proprietary driver always kills my X instantly.
boris64|alive: yangman; Well, thx for your anwer, i'll track the radonhd changes, hopefully someday i'll have xv ;)
agd5f: yangman: that fix was for diagnle tearing when drawing triangles
agd5f: it uses a quad rather than a triange
agd5f: vertical tear could still be a factor
agd5f: really we need pageflipping
agd5f: and composite so we can queue a flip in the command stream so we are never rendering to the buffer we are displaying
yangman: agd5f: what was the URL of your powerplay branch again?
MostAwesomeDude: yangman: http://gitweb.freedesktop.org/?p=users/csimpson/xf86-video-ati.git;a=summary is rebased.
MostAwesomeDude: If you want, I can pull the recent RSxxx fixes as well.
MostAwesomeDude: Oh, use the agd-powerplay branch, of course.
yangman: thanks
MostAwesomeDude: No problem. ;3
Der_Steve: Everytime i execute ./configure i get the NOTE: DRI support is disabled some ideas?
MostAwesomeDude: Der_Steve: Got Mesa 7.1?
Der_Steve: do you know the right pakage?
libv: Der_Steve: you're missing some dri or xorg devel packages
Der_Steve: i just installed libgl1-mesa-dri and libgl1-mesa-dev
MostAwesomeDude: Der_Steve: No distros are shipping Mesa 7.1 right now.
libv: Der_Steve: i'm not sure, but i think our wiki mentions some things
libv: hrm... no... nothing there
libv: PKG_CHECK_MODULES(DRI, [libdrm >= 2.2 xf86driproto],, [USE_DRI=no])
libv: so pkg-config either finds too old a libdrm, or lacks xf86driproto
Der_Steve: this is so hard for me ive got no experience in building and installing foreign packages
Der_Steve: do you think this could help me? http://wiki.x.org/wiki/radeonhd%3ADRI
LoneTech: you want x11proto-dri2-dev
LoneTech: there were new enough mesa and xorg in debian experimental
libv: Der_Steve: what distribution are you using anyway
Der_Steve: debian etch
libv: drm is 2.0.2-0.1
libv: libdrm that is
libv: too old
Der_Steve: and how can i fix this?
libv: by upgrading packages or doing a distupgrade
libv: Der_Steve: what hardware are you using anyway?
Der_Steve: especially the Graphicscard?
Der_Steve: or everything?
libv: no, just the graphics card
Der_Steve: Radeon X1550
Der_Steve: AGP with 512 MB
libv: ok... so you will benefit from running dri
libv: Der_Steve: there's nothing on backports.org
libv: well, you don't really need dri
libv: you need drm mostly
Der_Steve: okay
Der_Steve: my problem is that i installed this debian just 2 days ago but for the moment i am using the default vesa drivers an i got very few fps
libv: Der_Steve: then run the driver without dri for the time being
libv: Der_Steve: it's more sluggish, but you probably don't want to bother just now
libv: Der_Steve: in future, when you want to, you can upgrade some packages still and then recompile the driver to still get dri
Der_Steve: okay
libv: Der_Steve: but for the time being, just stick with MMIO :)
Der_Steve: would you mind helping me with the installation?
libv: Der_Steve: the wiki should explain most of it, it's in /topic
Der_Steve: okay
Der_Steve: Thank you very much
Der_Steve: :)
yangman: what's going on with the atombios_support branch right now? hasn't been much activity there lately
egbert: yangman: right. i hope it will get some more testing.
surfer: anybody else have problems with radeonhd, xvideo, and compiz?
egbert: i myself need to do some more tests.
surfer: i get just a black window when playing videos
surfer: vo x11 and gl is ok
yangman: I wouldn't mind testing it out, but the recent changes to master isn't part of it, is it?
egbert: yangman: no.
yangman: if it's possible to merge those, then that'd be great. I wanted to poke at atombios myself a little bit, but not too keen on having to go back to shadowfb
surfer: compiz is broken on the cs branch
surfer: actually its just all around broken for me
surfer: corruption
Gatonegro: Hello. I'm trying to get my Radeon Mobility X1600 working on Debian. I've installed the package xserver-xorg-radeonhd, and things work fine with 2D, but I can't get DRI in 3D to work. Can anyone help?
Fefe: hey
MostAwesomeDude: Yo.
Fefe: anyone know what holds back xvideo on rv770?
airlied: Fefe: no specs
Fefe: but texturedvideo works on other chips, right?
MostAwesomeDude: Fefe: No 3D register information yet.
bridgman: Xvideo uses the 3d engine on 5xx and up, and we haven't been able to release the specs for 6xx/7xx 3d yet
Fefe: oooh
Fefe: crap
Fefe: I see
bridgman: but textured video works nice on 5xx, rs690 and lower
MostAwesomeDude: Trust me, we're all anxious to get docs and start writing code. :3
Fefe: I have an X1600 in my notebook and it works there
Fefe: so I assumed I could just #ifdef out an if statement and see if it works :)
MostAwesomeDude: Fefe: Well, there's literally no code path for it.
bridgman: $10 says it won't work ;)
MostAwesomeDude: bridgman: I'd take that if I had $10.
bridgman: I mean "won't work now", not "won't work once you get your hands on docs" ;)
bridgman: I'm sure it will work "soon"
Fefe: so, uh, atombios only abstracts the 2d stuff?
Fefe: there is no way to use atombios to do 3d on the newer chips?
MostAwesomeDude: Yeah, 2D modesetting only.
bridgman: Yep -- initialization, output control, modesetting -- all the stuff that doesn't have to run fast
MostAwesomeDude: And dynamic gating/powerplay, but that hasn't been written out for r6xx yet.
Fefe: how is it that radeonhd has good 2d acceleration on my rv770?
Fefe: that is not through atombios then, right?
MostAwesomeDude: Fefe: Well, the acceleration is through the shadowfb, which can get pretty fast on modern CPUs.
bridgman: in case osiris reads backlog, what I found so far is that the s16e7 format is defniitely what we use in 3xx pixel shaders, but the values are always stored normalized so it's really s17e7 but the leading 1 is not stored
Fefe: oh really? it's not actually hardware blitting when I solid-drag a window around?
Fefe: wow
Fefe: why is vesafb so slow then? don't they have a shadowfb, too?
bridgman: If you're on 770 then you're running with shadowfb, so the CPU is blitting the stuff around in system memory which is really honkin' fast,
bridgman: then periodically stuff gets blitted to the screen so you can see it
bridgman: periodically being "faster than the eye can see" normally, of course
airlied: vesafb goes direct to VRAM, it has no shadow
bridgman: I think the other IEEE floating point formats allow denormalized numbers and so do not chop off the leading 1 -- although I don't remember how you store "0" in the case where you are always normalized with a hidden leading bit
bridgman: time for another sacrifice to the Google Gods
MostAwesomeDude: Hmm.
Fefe: it's the other way around
Fefe: IIRC
Fefe: IEEE floating point is always normalized with an implicit one
Fefe: bit
Fefe: but for zero they have a special bit pattern
Fefe: just like they have one for "infinity"
Fefe: you need specialness for normalized storage, not for denormalized
bridgman: I have seen that too. That's why I'm a bit confused -- but s16e7 is always talked about as being different from the rest because it does not support denorm...
MostAwesomeDude: Hm.
MostAwesomeDude: Yeah, I was wondering why osiris' code looked so clean compared to normal float generation code.
Fefe: lemmi google s17e7, never heard of it
Fefe: oh it's non-ieee
Fefe: apparently there is no real standard for it
Fefe: so whether the exponent is biased is implementation dependent
Fefe: why would you use a format with 17+7+1=25 bits per number?
Fefe: wtf?
Fefe: why not just use ieee 32-bit floats?
bridgman: the stored format is s16e7
MostAwesomeDude: Fefe: One of the bits is implicit.
Fefe: ah ok
Fefe: still strange, does alignment not matter for graphics cards?
MostAwesomeDude: Well, the thing is, Radeons are always 32-bit aligned.
bridgman: there's a big difference in transistor count between 24 and 32 bit shader core, and r300 was made when transistors were a lot bigger ;)
MostAwesomeDude: But sometimes there's registers marked by "Reserved" or "Unused", which usually means "This has a use, but we couldn't really tell you, so you're gonna hafta guess at it until you figure it out."
bridgman: the r300 converts from 32-bit to 24-bit on input and back to 32-bit on output for most things, it's just a few specific register settings where you have to explicitly use s16e7
MostAwesomeDude: And then there's registers that are marked, but that don't work as expected, like AA_CONFIG.
bridgman: I think we only flagged a few fields as Reserved; we didn't actually change much
bridgman: but damn we spent a long time working out what the smallest # of fields we could chop out was ;)
MostAwesomeDude: bridgman: Yeah.
MostAwesomeDude: And really, it's not that big of a deal. The really strange ones, like DXTC and aniso, were guessed from fglrx dumps a long time before docs were ever available.
bridgman: looks the other way
MostAwesomeDude: XD
MostAwesomeDude: Forget I said anything.
bridgman: I just learned something useful -- searching for "fp32" and "demoralized" does not get the same results as "fp32" and "denormalized"
Fefe: wasn't DXTC semi-public?
bridgman: funny that
MostAwesomeDude: Anyway, um, we *do* have an r300PackFloat24 in Mesa, and that appears to be what we use to pack the consts for r3xx HW.
Fefe: hahaha
MostAwesomeDude: Fefe: It's completely public, and completely patented. Go figure.
bridgman: yeah, Microsoft licensed it for DX
Fefe: so why the need to reverse engineer anything?
MostAwesomeDude: Anyway, going to go ahead and port this over, then try and find some r3xx/r4xx person to test it.
MostAwesomeDude: Fefe: Well, gotta figure out where on the card it is.
MostAwesomeDude: Anyway, it's not terribly important right now.
MostAwesomeDude: What's important is finding food, and then going to experiment on a SPARC box my friend picked up from a dumpster.
MostAwesomeDude: Oh, and making r3xx bicubic work.
Fefe: hehehe
bridgman: The sparc box might have an rv370 in it...
Fefe: well good luck to all of you, and godspeed :-)
MostAwesomeDude: bridgman: ?!
MostAwesomeDude: Who knows.
Fefe: will continue waiting for xvideo support
MostAwesomeDude: That'd be cool.
bridgman: Yeah, what Sun calls an XVR300 is an RV370
MostAwesomeDude: bridgman: ...In all honesty, the docs aren't gonna be here for another month, are they?
MostAwesomeDude: Sorry, don't mean to sound accusatory.
MostAwesomeDude: :c
bridgman: No, it's a fair question. I think we're 2-3 weeks away but we're having a heck of a time getting 2-3 weeks of time to actually spend
bridgman: I'm hoping to be mostly freed up from other stuff before I go on vacation, and I'll be off the grid for a week, so a month is probably about right
bridgman: Think you can finish Gallium 5xx by then ?
bridgman: ;D
MostAwesomeDude: XD
MostAwesomeDude: Hopefully, I'll be able to make a good start by then.
MostAwesomeDude: We're going to try to make the pipe part work first, so commands sent down Gallium will create state that we can echo to the card.
MostAwesomeDude: And then we just have to hook up the pipe with some winsys glue, to connect the pipe to DRM.
MostAwesomeDude: It *should* be a lot easier than Mesa-style DRI.
MostAwesomeDude: Since it maps to card abilities, and not to OGL features.
bridgman: cool... I was afraid someone was going to write an x86 emulator for r5xx shaders and run softpipe ;)
MostAwesomeDude: Eek.
bridgman: I have already had a few questions about writing an atombios parser for shaders
MostAwesomeDude: Actually, I'm VERY interested in whether or not XvMC can be done reasonably fast with shaders.
MostAwesomeDude: I'm confident in the ability of r6xx+ to do it, but r5xx, I'm not so sure.
MostAwesomeDude: On the other hand, we might write MC support into Gallium's core, to support cards that have MC/iDCT blocks.
bridgman: I think so... it's just that you're using a 32-bit floating point engine to do logic ops
bridgman: sorry, I was thinking h.264 stuff.. xvmc is no problem, especially since even the proprietary driver does MC on shaders and there are special rounding modes in the docco for MPEG2 use
MostAwesomeDude: Yeah, this is true.
bridgman: there is no mc block, just idct; AFAIK the xvmc protocol allows mc-only acceleration so that would seem like a real good place to start
MostAwesomeDude: Yeah.
bridgman: ... and if we can ever get the 6xx/7xx 3d stuff out I don't *think* the IDCT block will be hard
MostAwesomeDude: checks the GSoC guy's progress on Gallium XvMC
marcheu: MostAwesomeDude: he's currently fixing the driver side :)
MostAwesomeDude: Hmm, lookin' nice.
bridgman: I think he's in Toronto, isn't he ?
MostAwesomeDude: marcheu: Yeah, he's doin' good work.
marcheu: bridgman: hey, leave him alone !
agd5f: I though ajax added shadowfb support to vesa at some point
marcheu: MostAwesomeDude: yeah I think we've mostly settled on an efficient idct implementation after hurting our head sa lot
airlied: agd5f: to vesa yes, not vesafb.
MostAwesomeDude: marcheu: IIUC it would be possible to add dedicated MC/iDCT without much hassle, if it's on the cards, right?
bridgman: MAD: you probably wouldn't want to go through Gallium if using dedicated HW though, would you ?
marcheu: MostAwesomeDude: hmm ATM it relies on the gallium driver only
bridgman: I don't think Gallium wants to know "ooh ooh, I'm working on video" :)
agd5f: MostAwesomeDude: we do mc on the 3d engine and idct has dedicated hw
MostAwesomeDude: Well, I mean, if we have all of these other features described in Gallium, then I would think it might be possible to use dedicated HW for this, too.
marcheu: MostAwesomeDude: as I told him, we're getting real time out of it so we won't probably be bothering with dedicated hw
MostAwesomeDude: Hm, 'k.
marcheu: MostAwesomeDude: what I want is xvmc for all cards, without having to rewrite the code each time
bridgman: yep, that sounds like a real good idea
MostAwesomeDude: marcheu: Right. I'm just wondering if it's possible for the XvMC in Gallium to get faster if certain HW happens to be present.
marcheu: MostAwesomeDude: and also we're more interested in flexibility (supporting more codecs) which the fixed pipe cards (that usually do mpeg2) can't do
marcheu: MostAwesomeDude: today mpeg2 is mostly useless, you want h263/h264, even though most hw still does mpeg2
bridgman: MAD: I think you would optimize by using a different xvmc implementation; how that would happen is a good question though
MostAwesomeDude: It just seems to me that if only Radeons have MC/iDCT available, that would eventually lead to a different Radeon-only library, which isn't what we want...
MostAwesomeDude: Or we ignore HW abilities, which is also not what we want.
MostAwesomeDude: Or maybe I'm silly.
marcheu: well we decided to ignore the wh caps. we might lose a little performance, but we have only 1 impelmentation and it's more flexible
MostAwesomeDude: 'k.
agd5f: MostAwesomeDude: it's probably be useful on r1xx/r2xx hw, since no shaders, but gallium is the way to go the new stuff
marcheu: additional stages could be done on dedicated hw, but that'd mean extend gallium in new ways
marcheu: anyway as I said, my opinion is that codecs move so fast we'd better have something that works at 90% of the max performance, but for all cards, instead of spending a huge amount of time to get to 100% but for only 1 card
marcheu: and then 6 months later there is a new codec...
MostAwesomeDude: Makes sense.
MostAwesomeDude: Now all I have to do is write some Gallium/Radeon pipe.
marcheu: yeah that'd be a good start in any case
MostAwesomeDude: And then rip off nouveau's winsys.
marcheu: I don' think you want to base anything off nouveau, better look at i915simple
MostAwesomeDude: XD
marcheu: because it is simple :)
marcheu: we're supporting 5 families of cards in the winsys, you get lost quickly
marcheu: sorry 6 families
MostAwesomeDude: Mm.
MostAwesomeDude: Oh, are all the nV cards different in terms of register layout and such?
MostAwesomeDude: I'm not too familiar with how nV stuff goes.
marcheu: no, it's not the ATI craze if that's what you'r asking
MostAwesomeDude: Ah.
marcheu: but things move sometimes, yeah
MostAwesomeDude: Yeah, I was thinking that we might only need one radeon pipe, with switches in a few places to switch between families. I don't know, after looking at the radeon Xv stuff, if there's really enough differences to justify three or four different pipes.
marcheu: I can't say
airlied: MostAwesomeDude: probably need a r300 then r600 pipe
airlied: MostAwesomeDude: and if marcheu does his legacy support, an r100/r200 one
marcheu: what I'm sure is how we had to split for nouveau
MostAwesomeDude: airlied: It is decided for sure that it's not going to be possible to do Gallium on r2xx?
airlied: MostAwesomeDude: the frag shader is probably not good enough to work with gallium
marcheu: doesn't matter, you're not merging r200 an r300 anyway...
airlied: marcheu: well the plan is to merge the bottom layers with bufmgr if we can
MostAwesomeDude: True.
airlied: like intel have done for i915/i965
marcheu: airlied: that was obvious :)
marcheu: airlied: nouveau has a single one for all cards
airlied: marcheu: yeah it should be mostly the winsys in the end
marcheu: funnily the winsys "cuts" would not be the same as the 3d component "cuts"
MostAwesomeDude: Hm.
MostAwesomeDude: Stuff worth thinking about.
MostAwesomeDude: Food now, code later. Also if anybody wants, they can pull and test r3xx bicubic; I think I fixed the const emit.
bridgman: ok, I confirmed that IEEE FP32 etc are all normalized as well, so presumably osiris was doing the same for the s16e7 values
bridgman: I guess the only difference from "no denorm support" would be at underflow, guess maybe the 3xx shader output goes straight to 0 on an underflow