MostAwesomeDude: Pushed DDX and DDY opcodes to master, if anybody cares.
airlied: goes crazy differentiating.
MostAwesomeDude: XD
MostAwesomeDude: I'm gonna see if we need anything else for NV_f_p, as long as I'm on the subject.
MostAwesomeDude: And then I'm gonna read up on the noise insts.
MostAwesomeDude: Okay, so noise is icky.
airlied: MostAwesomeDude: relative to fog icky? :)
MostAwesomeDude: airlied: Worse.
airlied: MostAwesomeDude: do fog first then ;-)
MostAwesomeDude: Noise needs to be pseudo-random beyond the capabilities of the cards.
MostAwesomeDude: I would completely and totally believe that fglrx just uploads a grayscale helper tex preloaded with the noise.
moondrake: do you need mesa 7.1 for 3D stuff?
moondrake: on r500 that is
bgoglin: moondrake: yes
moondrake: bgoglin: was afraid so, just upgraded my distro, but guess i still should keep running git stuff.
RTFM_FTW: the only viable approach for noise in the fragment shader on older ASICs is indirect texture fetches using a noise texture generated offline or as needed via the CPU
RTFM_FTW: for newer ASICs you have the ALU power to execute procedural noise algorithms in the fragment shader but this still isn't necessarily viable for real-time interactive applications...
MostAwesomeDude: RTFM_FTW: And since noise needs to be pseudo-random but predictable, I'd much rather just generate it before-hand.
RTFM_FTW: here is a good paper to read on the subject (concerning Ken Perlin's Simplex Noise algorithm): http://staffwww.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf
MostAwesomeDude: XD, by no short coincidence, that's one of the papers I read last night. :3
RTFM_FTW: Stefan has a fairly optimal implementation for both Classic and Simplex noise variants in 1D, 2D, 3D and 4D
RTFM_FTW: which runs on the GPU
RTFM_FTW: via the programmable fragment pipeline
MostAwesomeDude: O RLY? Sounds sweet.
RTFM_FTW: really... and this research was done years ago :P
MostAwesomeDude: Awesome.
MostAwesomeDude: I know how to do Fog Options. I think.
MostAwesomeDude: I'm trying to decide whether or not to just do them in HW.
RTFM_FTW: I'd recommend contacting him if you needed more information on this (or if the licenses are compatible with your own work)
MostAwesomeDude: Mm.
MostAwesomeDude: I've got a prior commmand, though.
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
RTFM_FTW: those implementations can be found here: http://staffwww.itn.liu.se/~stegu/simplexnoise/
MostAwesomeDude: So I'm gonna fix fog coords so we can finally go to OGL 1.4. :3
RTFM_FTW: in any case all consumer GLSL implementations currently either return zero *or* transparently fall back to the software rasterizer for noise operations
MostAwesomeDude: Yeah, not surprised.
MostAwesomeDude: We're gonna be slightly more awesome than that, I think.
RTFM_FTW: meh personally I'd leave it up to the client
RTFM_FTW: since the client tends to know far more about their use cases then you do :)
MostAwesomeDude: Arg. Okay, so I need better control of the fog HW. What do you guys think would be the best way to consolidate fog ops?
MostAwesomeDude: RTFM_FTW: Yeah, true, but OGL doesn't have any commands for that. Maybe driconf?
RTFM_FTW: commands for what? ...I'm simply suggesting that you guys follow the rest of the vendors and just (currently) fall off to SW for noise
MostAwesomeDude: Ah.
RTFM_FTW: since there aren't *any* applications currently shooting for RT procedural noise generated in the fragment shader
MostAwesomeDude: Well, but SW is slow....hm....
RTFM_FTW: and those which *do* need this happen to implement it via texture sampling
RTFM_FTW: and in those cases its not viable for the server to do this internally (AFAIC)
MostAwesomeDude: Well, I say we follow their lead, and just have noise texes that we can upload if needed.
MostAwesomeDude: Gonna be slow either way, really, on pre-r6xx.
RTFM_FTW: I mean RT procedural algorithms like the one(s) I linked above aren't going to be terribly fast (even in lower dimensions) on older ASICs (i.e. R5xx, R4xx, R3xx) to begin with...
MostAwesomeDude: Right. So options are:
MostAwesomeDude: 1) Do it in the FP. (slow)
MostAwesomeDude: 2) Use a helper tex. (slow)
MostAwesomeDude: 3) SW fallback. (slow)
RTFM_FTW: so anyone looking for noise on that level of HW would be looking at indirect texture lookups using an existing noise texture
MostAwesomeDude: 4) Be pansies and return 0. (fast, but somehow not fulfilling)
RTFM_FTW: 2 isn't slow
MostAwesomeDude: ...Thought you said that it wasn't fast enough, when it was tried before?
RTFM_FTW: in fact for *most* ASICs (including the three listed above) (2) is the only viable option concerning performance
RTFM_FTW: 1 is slow
RTFM_FTW: with (1) you are literally generating noise via ALU operations (hundreds of them) in the shader
RTFM_FTW: on a per fragment basis
RTFM_FTW: that is slow
MostAwesomeDude: Yeah.
RTFM_FTW: fetching from a (1D, 2D, 3D, ...) noise texture is way cheaper
RTFM_FTW: that is effectively nothing more than another texture load
RTFM_FTW: and sample operation
MostAwesomeDude: 'Specially if we pre-generate the textures.
quicksilver: of course you can pregenerate the textures ratehr quickly using texture modes
quicksilver: but still it's a bit weird as a GLSL feature
quicksilver: because when would you do it? at app start time?
quicksilver: at the first time a shader which uses noise is compiler?
quicksilver: compiled...
quicksilver: how big do you make the textures?
quicksilver: would really be better as a library than a core feature.
RTFM_FTW: let the client generate their own noise textures... specifically since you aren't going to come anywhere close to satisfying all of them :P
RTFM_FTW: I mean how many possible texture combinations are you going to generate? how many different properties (octaves etc.) will those texture(s) have? ...can the client adjust these to meet their needs? ...this sounds like a nasty can of worms to open up :D
MostAwesomeDude: RTFM_FTW: Yeah, you're right, but it just seems rather sad that this isn't addressed in the standard.
MostAwesomeDude: All the standard says is "implementation-dependent method" and that's the end of that.
sharp15: last time this is where i got help with fglrx removal. so here goes.
MostAwesomeDude: sharp15: Which distro?
sharp15: gentoo.
MostAwesomeDude: 'k.
MostAwesomeDude: First, remove ati-drivers.
MostAwesomeDude: $ sudo emerge -Cav ati-drivers
MostAwesomeDude: Then, remove the fglrx kernel module.
sharp15: does that install any other modules that would not be removed from /lib/modules? other than fglrx itself?
sharp15: that = ati-drivers
MostAwesomeDude: $ find /lib/modules -name fglrx.ko -exec rm {} +
MostAwesomeDude: Oh, sorry.
bobbens: updatedb && locate fglrx and then go on a killing spree
MostAwesomeDude: $ sudo find /lib/modules -name fglrx.ko -exec rm {} +
MostAwesomeDude: sharp15: Gentoo's ebuild for ati-drivers is very well-designed; after removing the ati-drivers package you only have to find the fglrx.ko files and remove them.
MostAwesomeDude: Or, if you're feeling lazy, blacklist fglrx in modules.autoload.
sharp15: my framebuffer is not configuring itself correctly and last time i used radeon it did. so i figured there is a module still present.
sharp15: MostAwesomeDude: for the blacklist do you mean /etc/modules/autoload.d/kernel-2.6 ?
MostAwesomeDude: sharp15: Well, I just use /etc/modules.autoload, but yeah, whatever.
MostAwesomeDude: It's a lot easier to just use that find command I posted before.
sharp15: oh. so i can just creat that file?
sharp15: *create
sharp15: was just curious because i know of it but never seen the blacklist done.
sharp15: ok. thanks i'll be back in a minute.
sharp15: well that wasn't the problem. oh well.
sharp15: thanks for the help.
MostAwesomeDude: agd5f: Specific question; is fog always done in HW with fglrx, or is fog done in FP sometimes?
agd5f: MostAwesomeDude: it's all hw :) I don't know though, probably both, but I don't have access to fglrx src
MostAwesomeDude: Hm.
MostAwesomeDude: Alright.
agd5f: MostAwesomeDude: if you ahve specific questions about a partuclar extension I can run it by some internal folks and see if I can get an answer
MostAwesomeDude: Well, basically, I wanted to know if fog options are done in the FP or in the fog HW.
MostAwesomeDude: Fog HW is a bit faster, but FP means a lot less code.
MostAwesomeDude: Hm. So what do we need to move to DRI2? Bufmgr?
airlied: MostAwesomeDude: dri2.
MostAwesomeDude: airlied: So a bunch of largely non-backwards-compatible rewrites of the DRI?
airlied: MostAwesomeDude: so far we've got nothing the driver can target until krh finishes it up
airlied: most likely we need EXA pixmaps and a GEM bufmgr backend
MostAwesomeDude: If I'm reading the wiki correctly, it's just a small change in the way framebuffers are created?
MostAwesomeDude: WRT DRI.
MostAwesomeDude: And then the rest is in X and DRM?
airlied: not really..
airlied: the 3D driver needs FBOs really..
MostAwesomeDude: Ah.
MostAwesomeDude: So, basically, bunch of stuff I don't understand?
airlied: you can learn it all :)
MostAwesomeDude: Alrighty. :3
airlied: I've avoided doing a GEM backend to bufmgr..
airlied: so far.
airlied: I've just emulated all the old memory manager stuff on the new one.
airlied: but I have gotten EXA pixmaps working, but they needs a lot of optimisation
MostAwesomeDude: Pushed fog options to master.
MostAwesomeDude: So now you can be all "OPTION GL_fog_linear;" in your ARB_f_p, and it'll work.
damentz: MostAwesomeDude: so have you guys decided between ttm or gem?
MostAwesomeDude: damentz: Not my call, but GEM+TTM IIUC.
damentz: iiuc?
MostAwesomeDude: If I Understand Correctly. :3
damentz: ah
damentz: that's cool
MostAwesomeDude: damentz: airlied could explain better. It's GEM, plus some TTM stuff needed for Radeon/GeForce stuff.
damentz: ah
branan: I'm seeing an odd performance issue in X.org 1.3.0. I have an IBM T40, with a radeon 9000, 1400x1050 native resolution. When I set up an xorg.conf with the radeon driver, no matter how I try to optimize, I get crummy 2D performance (in KDE4). Drop-down boxes take a visible amount of time to render, and moving windows is just plan horrible. If I remove xorg.conf and let X use whatever it decides to use (which may or may not be the radeon
branan: driver, I don't know how to check that at runtime) The performance is much better. The problem is that in this mode, while I have great 2D performance, I have no GLX. I was hoping someone who worked on developing the radeon driver could help me get good performance with GLX enabled.
branan: running gentoo 32-bit, so cflags advice is OK too
MostAwesomeDude: branan: Pastebin your X log, please.
branan: with the xorg.conf, or without?
MostAwesomeDude: With, sure.
branan: OK. Need to restart X to get that. I'll be back
MostAwesomeDude: opens mouth
MostAwesomeDude: closes mouth
branan: alright, back
branan: http://pastebin.com/m52840b39
airlied: branan: it might be worth trying Option "AccelDFS" "true"
branan: OK. Just for my own curiosity, what exactly does that option do?
MostAwesomeDude: branan: Looks like GLX should work fine.
MostAwesomeDude: Are you talking about direct rendering, perhaps?
branan: MostAwesomeDude: That log is with my own xorg.conf, rather than letting X autodetect, so GLX with DRI work in that
MostAwesomeDude: Hm.
branan: It may just be DRI that fails without an xorg.conf, I don't recall exactly
branan: I can make a dump of Xorg.log with autodetection too, if you'd like
MostAwesomeDude: Well, I mean, GLX looks fine.
MostAwesomeDude: Are you talking about GLX direct rendering?
branan: MostAwesomeDude: It should look fine in that log. My problem in this configutation is poor 2D performance
branan: MostAwesomeDude: When I rename my xorg.conf to something else, my 2D performance gets much better, but I either lose GLX or maybe just DRI - I'll have to double-check
MostAwesomeDude: Hm.
branan: So my goal is to boost my 2D performance with my custom xorg.conf, so I can use 3D without sacrificing 2d performance too badly
branan: airlied suggested I enabled AccelDFS. I Still need to restart X to see what that does, then we can go from there.
branan: Adding AccelDFS seems to have done the trick to fix the performance problem with my own xorg.conf
branan: Background redraws quickly when I move windows, the address drop-down in konqueror is fast, and krunner is just as smooth as without an xorg.conf
branan: thanks to anyone who helped me that's still in the channel =)
Wally_Dog: Hey guys
Wally_Dog: Anyone know a workaround to get an ATi Mobility Radeon 9000 working at maximum resolution with Compiz Fusion on Ubuntu 8.04?
airlied: Wally_Dog: what maximum resolution?
Wally_Dog: Let me see
Wally_Dog: 1400 x 1050
Wally_Dog: It works at a lower resolution (1024 x 7768)
gentoofu: you can get your X to go 1400 x 1050 without Compiz?
Wally_Dog: Apparently
Wally_Dog: I'm using Metacity and it works
Wally_Dog: Why is it weird?
airlied: ah probably some texture limits..
airlied: ah he's gone