dawid: can a/o point me to a list of typical mistakes or even setup dri/xorg configs?
nike: So KMS depends on in-kernel memory management...
nike: Because 2.6.31 will have radeon KMS, that also means radeon driver can use GEM-ified TTM? And that the GEM-ified TTM exists in 2.6.31 for radeon?
nike: So now radeon driver in git uses TTM, EXA by default, textured video, and can handle KMS if 2.6.31 is used?
nike: oh bridgman could've answered my questions...
nike: probably.
sgcb: lol
bridgman: dawid; can you pastebin an xorg log ?
bridgman: nike; hold on, let me find the backlog ;)
bridgman: yes, kms depends on in kernel memory management
nike: The whole GEM vs. TTM thing kind of confuses me. i understand the rough differences but "GEM-ified TTM" is somewhat confusing.
bridgman: GEM API over TTM internals is probably easier ?
nike: Yeah, okay.
bridgman: in other words, everyone has standardized on the GEM API, but only Intel is directly using the initial GEM implementation
bridgman: everyone else is wrapping the TTM guts in a GEM API
nike: bridgman: So radeon in git uses EXA by default, textured Xv, and uses TTM for memory management (even though GEM API is on top), as WELL as KMS
nike: ?
bridgman: so EXA by default and textured Xv always
nike: Well I was just using Debian unstable and EXA wasn't default.
bridgman: if KMS and kernel memory management are present, I believe it uses GEM API
nike: I had to generate an xorg.conf file just to configure it to use EXA
bridgman: TTM is invisible
nike: Oh... okay but both GEM and TTM must exist in the kernel.
bridgman: let me check the commits; EXA by default is really recent AFAIK
nike: bridgman: let me check sid version I was using
bridgman: yes, although you could say "the GEM implementation uses TTM"
bridgman: TTM is not exposed anywhere
nike: 6.12.2
nike: bridgman: Is TTM entering into Linux at 2.6.31 or is it already there in 2.6.30?
bridgman: only in 2.6.31 AFAIK
dawid: bridgman: http://pastebin.com/m74ca38f8
nike: And does KMS support have to be put into the kernel for every driver individually?
bridgman: 2.6.30 picked up acceleration support for 6xx/7xx for x server, not for mesa etc..
yangman: EXA by default isn't in a release yet
bridgman: it has to be put in for every GPU family, but then if there are multiple X drivers each driver can be modified to use the same KMS code
bridgman: although in most cases there's only one driver per GPU family ;)
bridgman: here we go.. EXA by default was May 4
bridgman: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=2c8e130f73c680d4a7381b2ef37982b82c6ee478
bridgman: 6.12.2 release was April 8
bridgman: initial power management is also post 6.12.2
dawid: bridgman: sry? o.O
dawid: bridgman: You mean the radeon driver is old?
bridgman: well, it's not ancient or anything, just a couple of months old, but there has been a lot of change in the last couple of months
bridgman: not sure how much would affect rv280 though
bridgman: I don't see any obvious problems in the log, is everything slow ?
bridgman: I didn't pick through screen info; are you running 1 or 2 screens ?
dawid: bridgman: i talked to some more advanced user on #gentoo who uses a similar card, the 9250 and with this mesa and impossibly a newer driver gets a far better result
dawid: bridgman: 1 screen
dawid: bridgman: my flat graphics performance was so bad i really couldnt do a thing in kde4, also enabling EXA makes 3d bout 5% slower than w/o
bridgman: ok, there's a question; is your performance problem with 2d or 3d ?
bridgman: are you using GL or XRender for compositing ?
nike: bridgman: Okay so git has EXA, TTM, KMS, will all be part of next radeon driver + 2.6.31
nike: Which leaves... textured Xv which I don't really understand th different between normal Xv.
bridgman: TTM and KMS are actually in the drm (kernel) driver; EXA is in the radeon driver; radeon will *use* KMS and GEM/TTM if it's available (assuming all the changes are merged, don't think they are yet)
bridgman: Xv can either use a dedicated hardware overlay block (which "floats" the video image over top of the normal framebuffer display) or use the 3D engine to draw the video image right into the framebuffer
nike: And what about XvMC or VDPAU?
bridgman: the former is overlay, the latter is textured video
bridgman: XvMC, VDPAU, VA-API, XvBA etc.. are all higher level
bridgman: they may use Xv to display the decoded frames
bridgman: basically Xv and down is what we call "video render acceleration", XvMC and up are "video decode acceleration"
nike: bridgman: Ah, okay, so XvMC and up handle hardware decoding of specific video formats on the GPU...
nike: And Xv and down handle general video rendering, no matter the format?
bridgman: generally, although sometimes a different mechanism might be used for rendering, eg OpenGL
nike: bridgman: Also, does UXA offer any benefits at all to the radeon driver, or will it just be useful for the Intel driver?
bridgman: render acceleration is basically scaling, colour space conversion, de-interlacing, filtering etc...
spstarr: hello bridgman :)
bridgman: hi spstarr
spstarr: enjoying the funnel clouds (if you've seen any)
bridgman: I haven't really looked at UXA so just going from others comments here; might potentially be useful with the integrated graphics parts but not for the rest
nike: Ah, I see.
nike: bridgman: Are you an AMD employee?
bridgman: I missed the funnel cloud; the problem with going outside is that I don't get the Internet ;)
bridgman: nike; yes
nike: So AMD pays you, and a couple others, to code on just stuff in the radeon driver? or do you also get paid to work on in-kernel stuff, such as TTM and KMS?
spstarr: bridgman: expect same today, the cold core low won't get leave til friday or so
bridgman: I haven't actually touched the code much, I mostly ask questions ;)
spstarr: nike: bridgman is our specs man, our untanglethelegaleezestuff demangler :)
nike: Right, I remembered that whole period waiting painfully for r600/r700 3D docs
bridgman: my role is mostly on the IP side; figuring out what is safe to release, working with the devs to find a combination of stuff that works for everyone
bridgman: yeah, although a lot of that time was figuring out which bits of the docs we had were actually correct ;)
nike: bridgman: How many developers work only on radeon driver and not fglrx at AMD?
nike: And how many work on both?
spstarr: sighs that hes still using the intel GPU mode not the r6xx GPU yet
bridgman: three I guess
bridgman: we don't have any developers working on both, although we do have some testers who work on both
DanaG: odd... my desktop on karmic is now black under compiz.
nike: bridgman: Do those 3 work on KMS and TTM, stuff in Linux kernel as well as the radeon driver?
DanaG: But only at 1280x1024.
spstarr: bridgman: I was curious, what did legal say wrt switchable graphics info?
bridgman: the reason I say "I guess" for radeon is that only Alex and Cooper are actually working on radeon; Richard has been working entirely on mesa
DanaG: If I set the thing to a lower resolution... my desktop comes back.
DanaG: It's also giving really high CPU usage.
spstarr: has been busy in KDE land for the last few weeks
bridgman: agd5f helped with KMS and GEM/TTM and does other work in the kernel
bridgman: richard and cooper have mostly worked on userspace stuff
bridgman: DanaG; memory limitation maybe ?
DanaG: yeah, but it worked fine with an older radeon driver.
bridgman: spstarr; it's not like I "ask legal about switchable graphics" and get a yes/no answer
DanaG: Oddly enough, my panels are fine. And a window that fits within them (32px top and bottom), is fine too.
spstarr: i figure it's more complicated then that :)
nike: bridgman: What are cooper's and richard's full names?
spstarr: bridgman: just trying to cut though the layers, 'someone' has to grant permissions somewhere :)
bridgman: we're trying to collect all the agreements related to switchable graphics so we can try to make a proposal, but that's nowhere near top priority yet
spstarr: bridgman: not concerned
spstarr: bridgman: more of a curiosity, as i can just switch the GPU in bios once r6xx is ready for mass testing
bridgman: http://cgit.freedesktop.org/mesa/mesa/log/src/mesa/drivers/dri/r600?h=r6xx-rewrite
nike: And do they only work on the radeon driver, not in-kernel stuff?
bridgman: nike ^^
bridgman: Cooper has probably done some drm stuff, but mostly mesa and radeon
spstarr: hmm? fireworks @ 2am?
bridgman: Richard mostly mesa
spstarr: i doubt gunshots :)
nike: bridgman: When you say mesa... do you mean gallium3d as well?
bridgman: all my guns are locked up
spstarr: heh
spstarr: bridgman: I'll be mindful that you _have_ guns now ;)
bridgman: not gallium3d yet, but we're going to switch to gallium3d once we get the classic mesa up to rough parity with 5xx non-mm
MostAwesomeDude: nike: No AMD people have worked on Gallium yet.
bridgman: no worries, I always had guns ;)
bridgman: although they sure wanted to ;)
spstarr: bridgman: that will be some real interesting fun
MostAwesomeDude: Well, when infrastructure's in place, we'll all have Gallium work to do. :3
nike: So when you say mesa, you mean like getting 3-D rendering working for r300-r700?
bridgman: r300-500 is already there; we're working on 6xx-7xx now
spstarr: it really is nice to see the light appearing on the graphics stack
MostAwesomeDude: nike: Yes. r300 and r600. Only r600 is receiving new work from Richard and Cooper right now.
nike: bridgman: I know it's already there but it doesn't support the latest OpenGL version that the hardware supports, as x.org/wiki/RadeonFeature indicates
bridgman: the "r300" driver handles 3xx-5xx, "r600" handles 6xx-7xx
bridgman: nope; a lot of the higher levels of GL functionality needed a memory manager first
MostAwesomeDude: nike: It's a lot of work to add support to cards these days.
bridgman: that's why you're just seeing 2.x support show up on the Intel parts
MostAwesomeDude: Rule of thumb: If it came out after DNF, adding OpenGL support is non-trivial.
bridgman: is DNF out ?
MostAwesomeDude: *DNF was announced, sorry. :3
MostAwesomeDude: I hear that a few 3D Realms people are still carrying on the work. Maybe we'll see it in a few years.
MostAwesomeDude: (Or maybe I'll put out *my* game first. Not to mention Shatter, r600-gallium, etc.)
airlied: thinks he's bricked his rs690 :(
MostAwesomeDude: But yeah. Most Radeons and all GeForces are not easy to set up for OGL.
MostAwesomeDude: airlied: Flashrom?
MostAwesomeDude: Also, good work on bricking an x86. :3
airlied: MostAwesomeDude: yup the BIOS is confused
airlied: I can put a bios on a floppy and it reads and makes noises
airlied: but it doesn't boot afterwards
spstarr: bricked!
spstarr: airlied: i didnt think you could flash those?
airlied: the bios even had a cool builti in upgrade utiltiy
airlied: I just had to put the new image on a usb disk and it rea dit
airlied: of course it then bricked it
ssieb: MostAwesomeDude: what is DNF? and why does that affect OGL support?
spstarr: i dont think my HD 3650's bios is upgradable, let alone the laptop FireGL 5600 (r6xx)
airlied: this is an IGP
airlied: I was upgrading the BIOS on the motherboard
bridgman: Duke Nukem Forever
spstarr: oh
bridgman: it's announcement marks a point in time, roughly when GPUs moved from fixed function hardware to shader-based hardware
MostAwesomeDude: Yep. After DNF was announced, the entirety of the Radeon line and GeForce line were crafted.
ssieb: ah, ok :-)
spstarr: airlied: the mobo has no backup bios to fail over to with some jumper?
bridgman: and became a lot harder to support with drivers
DanaG: Hmm...
DanaG: VRAM is 64M... AGP Aperture is 64M.
DanaG: I wonder if the latter is what's making it go black.
MostAwesomeDude: r100 still looks kind of like the OGL pipeline, but r200's ATI_fragment_program and later are tough. GeForces are even further out there; they've had four or five iterations of shader engines.
yangman: airlied: LVDS signal is all out of wack after coming out of suspend with KMS. known issue?
bridgman: yep; r200 was tricky because it had both the old fixed-function and early shader hardware
airlied: yangman: not that I know off
nike: If r300-r500 chips use 'r300' driver and r600 and r700 chips use 'r600' driver... then do r100 and r200 chips use 'r100' driver? or separate drivers?
airlied: my laptops are okay
airlied: nike: for 3D r100 driver is radeon, r200 is r200
nike: Okay so... radeon, r200, r300, and r600
yangman: hm. I'll have to run some tests on it then. it's a M54
MostAwesomeDude: r300 is tricky because its shader engine is bonghits in a few ways.
MostAwesomeDude: r500 is fun to me, but I can understand the issues with it.
bridgman: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri?h=r6xx-rewrite
MostAwesomeDude: r600+ are really straightforward and simple and Galliumy.
DanaG: handy thing on HP business laptops: BIOS recovery.
DanaG: As long as boot block is good, you can hold up+down+left+right while powering the thing on, and it should flash the BIOS, given the right files in the right place.
DanaG: Would AGP Aperture SIze fix that black desktop?
airlied: DanaG: this box has bios recovery
airlied: I just can't find a working one to recover to :)
DanaG: ah.
DanaG: anyway, bedtime. Perhaps I can try to help puzzle that BIOS thing out tomorrow?
DanaG: Tue Jun 30 23:15:39 PDT 2009
airlied: I'm oging to find the CDs that came with it hopefully
airlied: they must be in a box at home
DanaG: yeah, bed. G'noight.
ssieb: airlied: I don't know if you saw my earlier comment. I tried my other card now. it's an RV515 / X1300 and it seems to perform reasonably well as long as I don't use KMS.
bridgman: MostAwesomeDude; believe it or not there are multiple hits on Google for "Galliumy"
ssieb: so I can relax for a while and not have to worry about the computer locking up all the time...
bridgman: mostly bad puns though
yangman: Galliumy sounds like a candy
MostAwesomeDude: Heh, yeah.
MostAwesomeDude: But yeah. r600 needs one shader compiler and a bunch of shader linking and relocation.
MostAwesomeDude: Very very similar to Gallium's ideal of one shader language.
yangman: oh boy. something during the suspend/hibernate sequence is doing bad things to signal timing :\
nike: So now that EXA, textured Xv, KMS (almost done), and TTM implementations are more or less finished up...
nike: That leaves mesa in r600/r700
nike: and what of DRI2?
airlied: nike: lots of optimisations to do
airlied: DRI2 is done as well
MostAwesomeDude: nike: DRI2 just kind of happens once KMS+GEM works.
nike: okay, good to know.
bridgman: we need GEM/TTM for 6xx/7xx as well
spstarr: DRI2 is very nice :)
airlied: pretty much r100->r500 all the code is nearly in place.
MostAwesomeDude: Right.
airlied: but lots of optimistation to be done
airlied: esp around EXA and low mem cards
MostAwesomeDude: Once KMS+GEM is working, I can add the softpipe for r600 in Gallium.
MostAwesomeDude: We need CS for r600 before real r600-gallium work can start, though.
spstarr: nike: if you use compiz/kwin cube mode, if you have glxgears the textures are properly rendered onto the primitives with DRI2
airlied: yangman: might need to get some reg dumps, we generally reprogarm the whol mode on resume
ssieb: MostAwesomeDude: CS?
airlied: command submission
MostAwesomeDude: CS is just a unified way of sending commands to the card.
bridgman: is it fair to say that bufmgr/cs is an abstraction over the pre-mm and post-mm mechanisms for managing memory and submitting commands ?
airlied: bridgman: pretty much
yangman: airlied: getting a *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD), followed by [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22)
airlied: yangman: on resume?
yangman: yeah
airlied: if so ouch.
MostAwesomeDude: bridgman: Definitely.
yangman: yeah. CAFEDEAD is bad :\
airlied: I tihnk the resume code might need some looking
airlied: it works for me one time :)
yangman: it actually borks on hibernate before it finishes shutting down
yangman: which is bizzare
spstarr: loves primitives
MostAwesomeDude: Entire point of CS is to eliminate the need to know anything about the software managing the card, just the card itself.
yangman: and I'm going to guess it shouldn't be trying to initialize r100 cp on a r5xx
airlied: yangman: no thats fine
airlied: the cp is r100->r500
yangman: ah. ok
spstarr: MostAwesomeDude: your passing packets (stuffed with command sequences) right? like ROP { some colours, some position info, etc} .. depending on what you need to tell the GPU to do?
spstarr: is that why there are different packet #'s ?
spstarr: into a ring buffer
spstarr: i believe its FIFO?
spstarr: or first in last out
yangman: airlied: is [drm:radeon_bo_move] *ERROR* CP is not ready use memcpy. also expected?
bridgman: first in first out
spstarr: almost like mini function programs
MostAwesomeDude: It's a FIFO, and I just send commands that I want it to take.
airlied: yangman: maybe if we do a copy after the CP shutsdown
bridgman: spstarr; download the 5xx or 6xx 3d guide; those have more info on cp & ring buffer
spstarr: getting...
bridgman: some packets just write data to registers, others do things like drawing
bridgman: might as well get 6xx now that you have a shiny new laptop
spstarr: ya
spstarr: I have 2 r6xx now
bridgman: scratches head
spstarr: bridgman: 2 HD 3650s one in the quad core, the other is a FireGL 5600 or 5700 (which actually is a mobile HD 3650)
bridgman: scratches head some more ;)
spstarr: hehe
bridgman: I don't understand the "one in the quad core" part
spstarr: oh its a PCIe card in the quad core box
bridgman: D'oh !!
bridgman: carry on
spstarr: looking at PDF
nike: Will XvMC be implemented pre-gallium, or will that likely be implemented post-gallium via an XvMC state tracker?
airlied: unless some community member does it I would guiess gallium
MostAwesomeDude: nike: There's an XvMC state tracker already.
MostAwesomeDude: Doing it in the DDX instead would not really be helpful, because Gallium code is already further ahead.
airlied: unless I want it on r200 :)
airlied: tries the 6th bios
airlied: maybe my floppy has bad sectors :)
MostAwesomeDude: airlied: Better bug marcheu for his super-secret non-shaderful-Gallium plan then. :3
airlied: home I think, tomorrow I will try new floppy drive
airlied: &
bridgman: nike; XvMC is a tricky one to discuss because the place it's most needed is really old systems, and the older GPUs had dedicated hardware blocks for IDCT and MC accel
bridgman: modern systems can decode full res MPEG2 without any trouble; it's H.264 and VC-1 that really need the decode assist, and XvMC won't handle those in its current form
spstarr: bridgman: so stuff like DRAW_INDEX is like a mini 'program' that you fill out with parameters when passing a DRAW_INDEX packet to the GPU?
spstarr: they are opcodes basically
spstarr: mov axe, cxe [opcode] [parameters]
bridgman: sort of; you set up vertex and index buffers in memory, then set other state registers in the GPU, then submit a DRAW_INDEX command to actually draw the primitives
bridgman: yep, think of type 0 packets as mov reg, value
spstarr: aha!
bridgman: and type 3 packets as more complex things like rep movs
spstarr: so there's setup packets, register manipulation packets, and gpu operations packets
bridgman: pretty much, although the lines are blurred these days
spstarr: I see
bridgman: most setup is done by manipulating registers
bridgman: but some of the type 3 packets are used for setup as well on 6xx/7xx
MostAwesomeDude: bridgman: I was thinking about the pkt3 in r5xx guide for blits. Is there any reason those can't be used? Are they unsafe in any way?
MostAwesomeDude: Ag.
MostAwesomeDude: airlied: ^^
bridgman: shouldn't be a problem; they use the 2D engine so there are synchronization funnies
bridgman: I think you have to flush 2d pipe before using 3d & vide versa
spstarr: bridgman: so if im right, you basically are pushing information to vertex and index buffers, and then at the end perform the micro drawing/rops to the GPU on a specific primative?
bridgman: so might be a performance hit if you mix 'em
spstarr: primitive
yangman: yeah, signal's definitely being messed up as kernel's engering hibernation :\
yangman: *entering
spstarr: since there is no more 2D engine, everythining is now treated as primitives?
bridgman: yep
spstarr: ah ok
bridgman: here's the whole sequence :
bridgman: set up the drawing stuff (type of primitive etc.)
bridgman: set up texture engines
bridgman: (where you read from)
bridgman: set up render target (where you write to)
bridgman: set up vertex shader program (what gets run on every vertex)
bridgman: set up fragment shader (what gets run on every pixel)
bridgman: set up vertex buffer and (if used) index buffer
bridgman: submit draw command; GPU runs each vertex through the vertex shader, takes the processed vertices and assembles them into primitives (eg 3 points make a triangle), converts each primitive to a bunch of pixels, runs the pixel shader on each pixel (which may include texture reads), does a depth check to see if the pixel from that primitive is visible or hidden, then if visible blends the colour from the pixel shader into the render
spstarr: but every primitive drawn is represented as an object to the GPU? you can get the handle of the primitive it is all delt with by coordinates of the primative's (x,y,z)
spstarr: dealt
bridgman: you basically say "dude, now you're drawing triangles" and send it a list of vertices
bridgman: each group of 3 vertices is a triangle
bridgman: now vertices are big, since they also have colour info, texture coordinates etc.. as well as position
spstarr: so it's always pushing .. never pulling
bridgman: driver writes into the ring, GPU pulls the packets out
bridgman: then GPU reads shader programs and textures from video memory, and writes updated colour/depth info into video memory
bridgman: GPU also pulls the vertex info and index info if you use it
spstarr: ok so it is storing the contents of the visuals like a C struct for example in memory but with a pointer to the right verties per primitive?
bridgman: if you do a regular draw then you just send the vertices
bridgman: if you do a draw index then you send an index buffer as well; the index identifies which vertices to use for each triangle
bridgman: that helps a lot when triangles are touching, since the same vertex might get used 6 times
bridgman: so you might have 10 vertices and 50 triangles; index buffer might have
bridgman: 1,2,3,4,2,3
bridgman: two triangles, both using vertices 2 and 3, but first triangle is 1,2,3 and second is 4,2,3
bridgman: vertices are big so take time to move and memory to store
bridgman: indexes are small
bridgman: do you have a good OpenGL book ?
spstarr: what im saying is once you have completed a gpu activity to draw say a triangle with some shading for example, what alerts the driver to send the next ROP operation to the GPU? or does the GPU just know what to do with the primitive once its been drawn to screen? other than the driver needing to something to that area the primitive is being drawn on (say a window moves over the primitive for example)
spstarr: I just have URLs for OpenGL info
bridgman: ROP is done per pixel, don't use it the way you did
spstarr: oh per pixel
bridgman: one "draw" command might point to a vertex buffer with enough info for 1000 primitives
bridgman: the GPU draws them all from that one command packet
bridgman: then it just reads the next command packet
spstarr: ah ok
bridgman: I'm just downloading the 6xx/7xx 3d guide so I can look at the same diagram
bridgman: should be about 4 minutes
spstarr: :/ no high speed
EruditeHermit: bridgman: did you ever get that satellite connection?
bridgman: nope, need to sell the old house before I have $$ for anything like that
bridgman: need to cut down a lot of trees first, and don't want to cut the trees down until I'm ready to build something in the spot
bridgman: so I cut the right trees down ;)
bridgman: spstarr; it would be good to do some opengl programming; that would make understanding the GPUs more intuitive
EruditeHermit: save the trees!
spstarr: yeah I should look at OpenGL... GL_BEGIN() [ setup your stuff GL_END()
bridgman: and all the different ways to set up your stuff; those different ways generally correspond to specific GPU commands
spstarr: so OpenGL just passes vertices and other info from userspace libGL to the DRM driver (be it swraster or hwaccel)?
bridgman: I think my acrobat reader is corrupted, ixnay on the doc
spstarr: but that underlining OpenGL the raw information is understood by the driver
bridgman: in principle, yes
bridgman: sorry, swraster doesn't use drm
spstarr: thats just sw rendering
bridgman: yep, so it's all done in mesa
bridgman: but for hw rendering, opengl calls go into mesa and then get translated to a set of command packets; those are sent through drm to the GPU
spstarr: bingo thats what I was wondering
spstarr: so a glClear() ---> translated into command packets for specific GPU in drm to the GPU
spstarr: or a glRotate etc
bridgman: yep, although glclear is a lot easier than glrotate ;)
spstarr: and OpenGL is just a generic layer of standard drawing, manipulation, shading/shadows, etc...
bridgman: anything related to coordinates etc.. either gets translated into a vertex shader program or a new set of constants that get loaded with the shader program
bridgman: yep, as is OpenVG, Direct3D etc..
bridgman: brb
spstarr: neat
spstarr: bridgman: neat, I clearly see the relationship from these simple primitives
bridgman: oh good; the next thing to understand is what gets interpolated and what doesn't ;)
spstarr: gl() setup things glBegin(type or primitive) vertex info stuff glEnd()
spstarr: heh
spstarr: all of the operations in OpenGL are performed in sequence it seems and drawing a primitive everything inside the glBegin/glEnd() blocks is queued into one operation until you finish with glEnd()
spstarr: so what I mean is ... a glRotate of a quad primitive for example must be done in sequence to the respective primitive
bridgman: pretty much; or when internal buffers fill up, or when you do SwapBuf, or glFlush etc...
bridgman: yep, you're really saying "here's how everything should be rotated, now draw stuff"
spstarr: ok that is what I wasn't sure of from the perspective of the visual
spstarr: im used to thinking of things as objects
spstarr: but these are not.. because you cannot specify which primitive to rotate you must specify the specific primitive to rotate before drawing
spstarr: this might take a little time for my head to process this concept
spstarr: programming in a sequential operation is different to me
bridgman: think about "setting the rotater" then drawing a bunch of primitives, really
MostAwesomeDude: And the card driver doesn't see most of this. Mesa does a great job of breaking it down into simple stuff that cards can understand.
MostAwesomeDude: (Gallium does an even better job, of course.)
spstarr: GL programming is a different concept, it almost reminds me of assembly but in more readable form
spstarr: these are all micro operations
spstarr: just like in assembly you have to setup registers, stacks *before* you create a mini operation
bridgman: yep, if you want to understand modern GPUs it wouldn't hurt to do a bit of hands-on GL programming; write a shader program, load an image as a texture and scale it etc...
spstarr: then draw it :)
spstarr: http://nehe.gamedev.net/lesson.asp?index=02
spstarr: im looking at the tutorials just now
spstarr: these ones are rendering the texture onto a primitive
bridgman: you have to actually write programs yourself if you want it to sink in ;)
spstarr: true, but I'll need to know the API also
spstarr: bridgman: what I didn't realize was how easy OpenGL is when you look at it, as long as you understand the concepts
bridgman: agreed, but it gets tricky as you get further into it, just like a GPU ;)
spstarr: glVertex2d glVertex3f .. the function names are logical
spstarr: sure
gadnio: hello, folks
spstarr: bridgman: complex is fine with me, if i know the concepts the rest can fall into place
gadnio: i'm having a radeon hd rv 770 card and fedora 11. this seems to be the only working driver at the moment for fedora 11 and i just want to thank you guys for that :)
gadnio: no 3d, but i still can have graphical experience, which is unbelievable
gadnio: i wanted to add something: some bios-es apparently don't set memory with sane enough preferences and people experience slow refreshes (when graphical things are flushed to the card)
spstarr: bridgman: a lot of this will require me looking up what each of the #defines do and what the gl() function does (manpages)
gadnio: moreover: i'd like to dedicate some time to this driver development so we can get proper 3d...
gadnio: i have no driver development experience, though
spstarr: :)
spstarr: gadnio: time to learn OpenGL ? :)
spstarr: like me heh
bridgman: gadnio, we're just coming up to the point where getting test feedback will be useful
spstarr: bridgman: should I build mesa git master w/ r6xx-rewrite branch?
bridgman: if you don't need to use 3d right now (ie you don't mind losing the software renderer) it's probably a good time to learn how to download and build the 3d code and the drm from agd5f's repo
spstarr: i can begin testing on two fronts
gadnio: spstarr: ya, would be nice
gadnio: spstarr: what about gallium? they are supposed to bring 3d, right?
bridgman: gadnio; only catch is that the kernel in F11 may be too new for the 6xx/7xx drm code
spstarr: bridgman: hmm, the drm part might be messy w/ fedora kernel unless his drm is just module part only vs whole kernel
gadnio: bridgman: if it won't brick my card, i'm willing to help
bridgman: gallium is a new driver model inside mesa, sort of a different driver API
gadnio: i cant get kms in fedora 11
spstarr: kms doesnt work for r6xx in f11
bridgman: it hasn't been written yet for 6xx/7xx (actually KMS has but GEM/TTM hasn't)
gadnio: what's easier? gem/ttm || opengl stuff?
spstarr: bridgman: newttm? :)
EruditeHermit: is it possible to run the gallium code but simply use softpipe?
EruditeHermit: right now
bridgman: gem/ttm is probably the hardest
spstarr: im just gonna wait til airlied backports to f11 kernel or when he begins using f12 kernel I'll selectively get from rawhide
spstarr: rawhide is so unstable i had to reinstall laptop it fscked up bad
bridgman: it's smaller and conceptually simpler but practically really hard
bridgman: opengl stuff is mostly userspace so that makes it a lot easier already
bridgman: EruditeHermit; AFAIK yes
gadnio: bridgman: harder by what standards? algorithms?
gadnio: i'm not afraid of hardcore c programming and/or algorithms :)
spstarr: bridgman: I assume there is a way to turn on debug in mesa to see OpenGL translated to say, software rasterizer or even a drm driver?
EruditeHermit: bridgman: how would one enable that?
MostAwesomeDude: EruditeHermit: Yes.
MostAwesomeDude: The catch is, we need KMS+TTM on the target chipset.
EruditeHermit: MostAwesomeDude: is your gallium code at a state where it is usable with software fallbacks for stuff that hasn't been done yet?
EruditeHermit: well I have kms kernel installed
MostAwesomeDude: EruditeHermit: RADEON_SOFTPIPE=1 glxgears
MostAwesomeDude: Works like a charm.
spstarr: bridgman: that would make understanding how a glCommand is represented in the r6xx [setup/draw operations etc]
MostAwesomeDude: gadnio: The HW that you have to talk to is very complex, that's all. Requires a lot of deep trickery.
spstarr: since agd5f and others are testing the redbook hello thing the would be able to see what OpenGL is passing to the driver from the drm side
EruditeHermit: MostAwesomeDude: does it fallback to sw after whatever hardware stuff you implemented yet?
EruditeHermit: or is it still not that far
spstarr: sleep, will read log bridgman :)
gadnio: okay, so opengl will be it then, but aint opengl being done after kms?
MostAwesomeDude: EruditeHermit: Nope.
gadnio: that is, should i wait for the kms part to be ready and then try to find out how to do opengl stuff?
MostAwesomeDude: It's either all hardware, or all software.
EruditeHermit: is the all hardware part usable?
MostAwesomeDude: EruditeHermit: Only for some small simple things.
EruditeHermit: would say compiz run on it yet?
EruditeHermit: or even glxgears
gadnio: MostAwesomeDude: you work on gallium?
MostAwesomeDude: gadnio: Yes.
MostAwesomeDude: EruditeHermit: glxgears works-ish.
bridgman: EruditeHermit; we're getting all the basic plumbing worked out now; once that is done the rest of the work should be easier/faster
gadnio: MostAwesomeDude: is that the way to go for 3d for radeon? that is, will it be default one it's done?
MostAwesomeDude: gadnio: Eventually.
bridgman: um, no ;)
EruditeHermit: MostAwesomeDude: what kind of performance are you getting at this stage compared to classic mesa?
bridgman: first priority is redbook hello (white square), but that exercises about 60% of the driver code
gadnio: if so, i'm willing to help, i want 3d on my box more than i want kms :)
gadnio: but i have no experience, so it will be harder than an experience driver developer
gadnio: i know c pretty well, though
yangman: if you want something to do *right now*, read through EXA and Xv code and understand how to work the shader engine
gadnio: i'd better start with helping you guys finish something than just creating some brand-new code
bridgman: also pull down the 6xx-7xx-accel doc from www.x.org/docs/AMD
gadnio: my experience shows me this way one starts faster :)
bridgman: well, first step is to understand how the chip works ;)
gadnio: and is safer from getting design-time errors :)
gadnio: bridgman: okay, so what are the first steps? i have these two downloaded: R6xx_R7xx_3D.pdf R6xx_3D_Registers.pdf
Breadcultist: hi, I'd like to know if this is possible: to force a 1280x800 screen into a 4:3 resolution (800x600) without stretching (i.e. with black bars), using radeon mobility x300
MostAwesomeDude: EruditeHermit: Well, I haven't gotten any benchmarking tool to run yet.
bridgman: read r6xx_r7xx_3d.pdf ;)
EruditeHermit: MostAwesomeDude: I meant in gears
EruditeHermit: I know its not a benchmark
bridgman: then maybe look at mesa/r600_demo
EruditeHermit: but is it running comparable to classic mesa speed?
EruditeHermit: as an indicator that there aren't major performance problems
yangman: I don't think there's much someone new to the code base can just jump in and help finish up related to 3D. if there were, one of us would have already done it ;)
Breadcultist: no wait I actually do want streching, just also while preserving the aspect ratio
bridgman: yeah, unfortunately a lot of our time is being spent learning mesa
bridgman: we know how to program the chip but that isn't helping as much as I had hoped
MostAwesomeDude: EruditeHermit: It's a *lot* slower than classic.
gadnio: bridgman: :)
MostAwesomeDude: And that'll get fixed later.
EruditeHermit: I wonder if after all this work it will be usable
EruditeHermit: =p
bridgman: Breadcultist; do you want 800x600 stretched up to 1066x800 or would you rather have 1066x800 native ?
bridgman: put "ish" after each use of 1066
bridgman: EruditeHermit; sure it will
bridgman: but new driver architectures *do* take a lot of work to get ready for use
Breadcultist: bridgman: I'd like to try either, whichever's possible/easier
bridgman: if there were something fundamentally flawed in Gallium3D I think we would have heard some whining from MAD-land ;)
yangman: ... are we gonna need to write another shader compiler for gallium? or can we recycle the mesa one?
DanaG: hmm, I "fixed" my black desktop by adding (manually, grr!) a 1280x960 modeline -- because for some reason, radeon doesn't give me all the modelines that tdfx does).
Breadcultist: or just, something to automatically preserve the aspect ratio when a program (like a game) forces a resolution change, I've heard that was in an old version of the windows ATI driver, then they removed it (now it's back again I think)
bridgman: yangman; I imagine a lot of the code generation part can be re-used, but the front end will have to be different if only because the IL is different
DanaG: now, if only I could fix that damned CPU usage.
DanaG: odd... metacity was eating some CPU time, despite me having it set to use compiz. =P
MostAwesomeDude: Some of the shader compiler might be reusable. We'll see.
MostAwesomeDude: $ sleep 6h
Breadcultist: this ratio thing was definitely a feature of a nvidia driver http://www.ldso.net/tronfaq/images/Nvidia_ControlPanel.jpg (I guess that does what I'm looking for)
bridgman: yangman; I think it will depend a lot on whether the person writing the new shader compiler is the same one who wrote the old shader compiler ;)
yangman: Breadcultist: I don't know if the scaler in x300 support this, but it is something that's doable
yangman: bridgman: the shader compiler looked scary. scarier than the macro shaders, actually ;)
bridgman: good compiler code is usually scary
bridgman: doesn't necessarily mean that scary code is good though ;)
yangman: heh
yangman: I'll have a crack at it eventually
bridgman: there may be some decent compiler tools that can handle VLIW packing
bridgman: that would make writing the back end easier
bridgman: I think gcc has some VLIW support and LLVM is supposed to get it at some point
yangman: yeah, hopefully LLVM will pick up good VLIW support
Breadcultist: how would I fix this ratio thing, would xrandr be any use? or some editing of xorg.conf?
DanaG: Breadcultist: try 'man radeon', perhaps?
bridgman: Breadcultist; it's either supported in the driver or it's not; agd5f would probably know
bridgman: I checked the man page; no mention
DanaG: I know VLIW (very long instruction word).... but not LLVM.
yangman: it's sort-of supported in radeonhd, but I'm not sure if it does exactly what you want there either
bridgman: but this is one of those awkward times when developers all around the world are either sleeping or having dinner ;)
yangman: or should be sleeping ;)
bridgman: I guess
bridgman: have to finish laundry first
yangman: ah yes, midnight laundry
yangman: always fun
bridgman: note to self; don't put all sets of sheets into laundry at the same time
DanaG: I wonder why radeon doesn't offer as many modelines as tdfx does.
mcgreg: heh
yangman: hm... I guess the aspect thing is radeonhd only atm
bridgman: Breadcultist; what happens when you force 800x600 now; does it get stretched to 1280x800 ?
Breadcultist: yes, it covers the whole screen
yangman: if the scaler is capable enough, it's something that can be ported fairly easily from rhd
yangman: it's mostly plumbing
bridgman: I think the scaler is completely different in 5xx and up
Breadcultist: unrelated: can this driver + my x300 do dual head?
yangman: that's what I'd guess. seems like another one of those someone-would-have-done-it-already-if-reasonably-easy things
bridgman: Breadcultish; should be no problem
bridgman: you might need a "Virtual" line to make room for the two displays in whatever arrangement you have in mind
bridgman: there are some limits on total size though, not sure if x300 trips at 2048 or 2560
bridgman: so if your other screen is wide as well you might end up having to place one above the other in the virtual framebuffer
bridgman: randr gives you a single big frame buffer then places the screens on that framebuffer
Breadcultist: that's good to know, I don't think I'll bother with it today though, thanks
yangman: I wish my old laptop with the X300 in it weren't so dead :\
yangman: well, bedtime for me
bridgman: are we talking "coffee in the keyboard" dead or "something broke and let all the smoke out" dead ?
yangman: "power regulator bit the dust" dead
bridgman: same here, it's starting to get light out ;)
bridgman: bye
debio264: ssieb: so would it improve anything if I did use KMS?
nanonyme: Aww, seems bridgman was right. ;)
nanonyme: Commit message "this allows redbook hello to render correctly mostly."
nanonyme: (That is, he said that when things start working, the particular commit message will be pretty obvious ;)
nanonyme: agd5f: Great going. :)
nanonyme: Hmm.
nanonyme: Apparently it still doesn't like doing anything useful on a 2.6.29 though. Guess I should compile a 2.6.28 test kernel.
debio264: ssieb: I set up KMS, gotta go see if it works
Zajec2: some time ago I was told by agd5f radeon supports scaling
Zajec2: how can I enable it?
Zajec2: because after standard X start (radeon git) I don't see scaled modes
agd5f: Zajec2: it's enabled by default
Zajec2: ok, i'll create bug report with log
bridgman: nanonyme; Cooper also has a patch that seems to fix the remaining errors in hello and some other tests as well
Zajec: bridgman: wow, interesting :)
bridgman: if you get 6xx-rewrite working with the earlier kernel, try deleting line 3979 in r700_assembler.c
bridgman: "pR700AsmCode->number_of_exports = export_count;"
Zajec: bridgman: do you have contact with some technical ppl in AMD?
Zajec: bridgman: asking for meaning of flags in PowerPlayInfo table seems like 5 min job...
Zajec: and wonder how it looks in reality :)
bridgman: Zajec; there's a header file for them, it's on the list for review etc..
bridgman: now that we have 3d out the door I'm catching up with some non-open source stuff that got piled up behind it
Zajec: bridgman: ok, good to know, thanks
bridgman: I didn't see anything wrong with Matthias' interpretation though, don't think he was misreading the numbers
Zajec: bridgman: he did for HD2x00 actually
Zajec: but not a big issue probably
Zajec: bridgman: anyway we have no idea what for are there groups of modes
Zajec: sometime we see 2 groups, sometimes 5..
Zajec: 0 and 1 group seems easy to understand but the rest...
Zajec: :)
bridgman: they're going to differ from system to system anyways
bridgman: depends a bit on how many power modes the vendor is willing to test
bridgman: sometimes not many ;)
bridgman: laptops tend to have more modes than desktops
Zajec: bridgman: actually modes are less important :)
Zajec: bridgman: there are groups, 3 modes each
Zajec: bridgman: i think it's something we should understand (groups)
Zajec: bridgman: and yes, that testing and notebooks sounds reasonable, right
Zajec: still no clue what group is what for after reading a lot of BIOSes
agd5f: for the scaler you have to select the scling mode you want using xrandr. it's an xrandr output property called scaler
agd5f: the choices now are center, full, and aspect
agd5f: the default is full I think
agd5f: Zajec: there are about as useful right now as the powerplay tables for older asics. I.e., there's nothing magical about them per se
glisse: agd5f: i got the feeling that vsc is not always initialized to some safe default value (1 i guess) in ddx
bridgman: nanonyme; btw current thinking is that deleting that line is not necessarily the correct fix (which is why it hasn't been pushed), but it is a powerful clue
agd5f: glisse: could be.
agd5f: glisse: seeing problems with the watermarks?
glisse: agd5f: no i am porting it to kms
agd5f: glisse: cool
Zajec: agd5f: not sure about that center/full/aspect... but ok, will experiment with xrandr, thanks
agd5f: Zajec: e.g., xrandr --output LVDS --set scaler full
agd5f: or xrandr --output LVDS --set scaler center
bridgman: is anyone else having trouble opening the r6xx-r7xx-3d.pdf doc in acrobat reader ?
bridgman: all the other docs open ok but I get errors on the 6xx 3d doc
Zajec: agd5f: just don't understand difference between full and center :) will just try, thx
agd5f: Zajec: center is 1:1 pixels with borders
bridgman: ie no scaling
agd5f: e.g. 800x600 centered in a 1024x768 display
bridgman: I guess we could call it "none" but then that leaves the "where does the image go" question unanswered
bridgman: "center" answers both
agd5f: bridgman: also, if you want to use the monitor's scaler
agd5f: I think you need a separate off or none
bridgman: thinks about that for a minute
bridgman: I had assumed that "center" on an LCD impled huge blanking periods, ie timing for (say) 1024x768 but only 800x600 active
bridgman: but using the monitor's scaler would mean outputting at 800x600 with normal timing
agd5f: while center isn't scaled per se, you aren't feeding the actual requested modeline to the monitor, it's still sending native mode timing
agd5f: right
bridgman: yeah, I see what you mean; it's not the same as "no scaling" because the timing is different
agd5f: yeah
bridgman: good point
stuckey: Hello
stuckey: I have the x1300 card with 7.4 mesa. I'm trying to run a game but the textures just show up grey.
stuckey: adamk: Hello
agd5f: stuckey: file a bug
stuckey: agd5f: Hi. How do I do this?
agd5f: stuckey: https://bugs.freedesktop.org
glisse: stuckey: first try a newer version
glisse: of mesa
stuckey: glisse: Okay, so there's the "radeon" package that comes with xorg, and then there's this libmesa which does the 3d stuff?
stuckey: Is this how this works? What's the radeon thing do? Why isn't there just one driver? Sorry, but I'm just interesed in how this all works.
glisse: stuckey: sadly there is 3 different software involved
stuckey: Why is this?
glisse: kernel module radeon, ddx xf86-video-ati which has the X accel code and also DRI stuff to communicate with the mesa radeon driver
stuckey: Complicated
agd5f: stuckey: for 3d, it's most likely the mesa 3d driver
agd5f: stuckey: r300 in your case
stuckey: How can I try the newest version to see if it works?
glisse: easiest way is to upgrade your distribution
stuckey: I'm really interseted in using a free driver, but my entire purpose for having 3d is to be able to play spring (foss game), but if it can't do that, I'm going to have to go back to nvidia :(
stuckey: glisse: already did that
agd5f: stuckey: your distro may provide packages or you can build from source
stuckey: So how is it that the 3d works, but then there's like a map in a game that just looks grey?
agd5f: stuckey: bug int he 3d driver or game
stuckey: I see
stuckey: What's the current stable version of mesa?
jcristau: 7.4.4
stuckey: okay then I already have that
agd5f: stuckey: the latest and greatest radeon code isn't in a release yet
agd5f: 3d code
stuckey: agd5f: is it buggy though?
agd5f: stuckey: fixes a lot of issues in the old code
agd5f: but there may be other bugs
stuckey: I see 7.5, which is the current "testing" or "unstable"?
stuckey: I mean, which one should I try?
agd5f: stuckey: I don't think that has it either. the radeon changes weren't merged until after 7.5 was branched
agd5f: so you'd need mesa git master
daum: hey guys - so i have everything setup with x except when i vnc into my computer (via Load module vnc) my screen looks like this: http://img9.imageshack.us/img9/3562/myscreenh.jpg , i can move the mouse, and the mouse on the remote screen shows up(and changes cursosrs over links), any guess why it might be doign this?
stuckey: agd5f: are there instructions on how to do this posted anywhere?
agd5f: stuckey: there's probably pre-build packages for debian somewhere
jcristau: there are packages for ubuntu, that would probably work.
stuckey: What's the version?
jcristau: https://launchpad.net/~xorg-edgers/+archive/ppa has mesa packages from git
stuckey: jcristau: what exactly do I need from there?
jcristau: stuckey: libgl1-mesa-{glx,dri} i guess
choad_: my kernel is 2.6.30-ARCH is this not compatable with fglrx ?
dawid1: choad_: afaik support is for .28 max
choad_: oh ok thax.
dawid1: choad_: but i dont check this very often i dont use it
dawid1: choad_: it will be in the relese info/changelog i think
adamk: There are patches floating around for newer versions. You might want to ask on #ati, though, since this is the channel for the open source radeon driver.
phercek: hmm, I did not follow it but if there are more arch linux users here and are interested the catalyst driver for arch then it is available in aur repository, it compiles and kind of works for me (for almost pure 2D it is better than radeon now, since there are no terible slowdowns because of some program using a bit of 3D); but it is unstable with real 3D apps (at least for me, having 2.6.30 kernel too)
soreau: agd5f: Did you ever get a chance to look at the register dumps I sent you? (the ones for 1024x768 tvout)
agd5f: soreau: not yet
soreau: I was curious if they have the info needed to make it work properly
agd5f: soreau: doesn't have any of the pll regs. you need a newer version of radeontool
agd5f: soreau: nevermind
agd5f: I see them
agd5f: soreau: yeah, looks like it should have everything you'd need
soreau: agd5f: Which lines are you seeing for the relevant pll regs, and in which file?
agd5f: soreau: regdump.1024x768@60.fglrx
agd5f: look for the lines with CL:
agd5f: those are the pll regs
agd5f: or some of them anyway
soreau: How do I know which ones to use and where?
agd5f: soreau: also doesn't matter what the refresh rate is, tv uses a fixed mode
soreau: ok
agd5f: soreau: although it looks like you are missing ppll_ref_div
agd5f: and p2pll_ref_div
soreau: hmm
agd5f: and PPLL_DIV_3
agd5f: and p2pll_div_0
agd5f: although all you really need is the pll info from the crtc driving the tv
agd5f: which you can figure out from the crtc routing in disp_tv_out_cntl
soreau: Now that I have the stuff in front of me *takes a look*
agd5f: which seems to be missing as wel
soreau: huh
soreau: agd5f: How can I get these missing regs?
agd5f: soreau: have to add them to radeontool
agd5f: or use radeondump
soreau: It's been almost a year since I've used either of those, but I still have both here..
agd5f: http://cgit.freedesktop.org/~glisse/radeondump/
soreau: agd5f: I have copies of both radeontool and radeondump but the other partition I had fglrx installed on is now using the open driver so I'd have to reinstall it
soreau: guess I'll be back later
soreau: "usage: ./radeondump -d
agd5f: soreau: the prefix for the file name that gets dumped IIRC
soreau: agd5f: Which file is the one that contains the interesting information though?
soreau: or is it like /dev/video0
agd5f: soreau: when you run radeondump it creates a file
agd5f: with the dump in it
soreau: So that is the output target
agd5f: the file is named after the pci id or something like that. the prefix is prepended to the file name
soreau: ah ok
soreau: yea, it's the device_id
soreau: agd5f: Thanks
soreau: Now to see if fglrx is gonna come easily and quietly or if I'm going to have to break it until it works again ;)
DanaG: "ati radeon ve/7000 qy"
DanaG: interesting... so that's what's in that Dell. Also happens to have a "DVO controller"
soreau: facepalms when he suddenly remembers recent version of fglrx won't even allow X to start with svideo hooked up
MostAwesomeDude: Just updated http://wiki.x.org/wiki/RadeonFeature. If there's errors, let me know. :3
nanonyme: MostAwesomeDude: Hmm, aren't most of those things in Gallium section supposed to be state trackers?
MostAwesomeDude: nanonyme: Yes.
nanonyme: Just pondering.
MostAwesomeDude: Even though the core driver is mostly complete, it doesn't actually work with most of those state trackers.
nanonyme: Ah, righ.
MostAwesomeDude: The WIP trackers are the ones I actually give a shit about, so they'll work sooner. (In theory, of course.)
nanonyme: Well, EXA and OpenGL would already make people worship the ground you stand on, I guess. ;)
MostAwesomeDude: People *do* worship the ground I'm on.
nanonyme: Anything after that is a bonus. :)
nanonyme: Right. ;)
MostAwesomeDude: Until they realize I'm not L. Ron Hubbard.
MostAwesomeDude: (I don't get it. Personally, I don't think I look like him at all!)
nanonyme: wouldn't know, has seen neither
MostAwesomeDude: Anyway, OGL is getting there, slowly. So is EXA.
nanonyme: Hmm, RS690 is the only radeon chipset that can't do hardware TCL?
nanonyme: Must've missed that bit of information.
damentz: hey MostAwesomeDude, thanks for creating that page
damentz: now i don't have to ask, is it done yet? :P
MostAwesomeDude: nanonyme: RSxxx are IGP, nearly all of them lack HW TCL.
MostAwesomeDude: IIUC R600-based IGP have fully unified shaders so they have HW TCL too.
nanonyme: Hmm, right.
MostAwesomeDude: damentz: Yeah, just thought I'd update it.
MostAwesomeDude: I remember being able to just point people at that page for a few months.
MostAwesomeDude: And now I can point them at that page for a few months more. :3
DanaG: hmm, what's the right channel to discuss the Intel driver?
MostAwesomeDude: DanaG: #intel-gfx
DanaG: Thanks.
nanonyme: MostAwesomeDude: Btw, wouldn't marking XvMC as N/N in the upper section be the correct course now that it'll get implemented through Gallium3D?
MostAwesomeDude: nanonyme: No, because at least airlied mentioned doing it for r100/r200 using the UVD once we get docs.
nanonyme: Doesn't really sound like to me someone would implement a non-Gallium3D XvMC at this point so keeping it as TODO might not be very fair. ^^
nanonyme: Oh, right.
MostAwesomeDude: I'll cross it out if devs agree that it's not gonna happen in DDX.
MostAwesomeDude: But I just don't think that's likely.
nanonyme: Right. But how about N/N for r300+?
nanonyme: (Or pretty much everything that can do Gallium3D)
MostAwesomeDude: nanonyme: Maybe. I'll leave it open for now, once we get UVD docs it'll probably get done in DDX first anyway.
agd5f: UVD only applies to r6xx+
agd5f: all the old chips use the 3d engine
agd5f: could be done now
MostAwesomeDude: agd5f: Aw, really? I thought there was a UVD and a UVD2; the latter was the r600+ chip...
nanonyme: There's actually afaik UVD, UVD+ and UVD2 at least. >.<
agd5f: MostAwesomeDude: yeah. r6xx and rv550 were UVD, r7xx is UVD2 IIRC
nanonyme: UVD+ bringing some minor changes to UVD.
agd5f: r1xx/r2xx have a spcial bit that switches the 3d engine to MC mode, r3xx-r5xx use shaders for MC
MostAwesomeDude: learned something today
MostAwesomeDude: agd5f: Do we get to know that special bit at some point? :3
MostAwesomeDude: Okay, so XvMC will probably be done with the g3dvl thingy ymanton wrote last year, then.
agd5f: yeah, it's pretty trivial to setup. I don't see any problems releasing that old stuff
nanonyme: agd5f: Does that imply no OpenGL compositing while doing movie playback with MC on?
agd5f: nanonyme: no you can mix and match
AndrewR: agd5f, hey, i was kiking Dave's patch (colortiling-on-kms) and looked at mesa ... something like this will work with kms? http://pastebin.ca/1481302 (simply restrict check to old rm and update comment)
nanonyme: Oh, right.
agd5f: all separate command packets
AndrewR: *kicking (?)
nanonyme: Cool.
dawid1: hi, is there somewhere a reliable info about what glxgears fps a specific card with the radeon driver can/should achieve?
agd5f: AndrewR: looks good
agd5f: AndrewR: should probably fix radeon and r300 as well
agd5f: if they do similar checks
MostAwesomeDude: dawid1: It's not just dependent on the card, so no.
AndrewR: agd5f, i think there was no hyperz on r300 and up ...
dawid1: MostAwesomeDude: i know its not, but with 2-3 values one does at least know what he can achieve with a given card; i think i have probs with performance on my radeon 9200 se,this is a 1,6ghz athlon,with 1,2gb ram and i get only 700-720fps while not much more powerful machines with this card get much much more
agd5f: AndrewR: hw is there, just not implemented yet. however there may be other features that check drm versions
MostAwesomeDude: dawid1: Unless you're playing glxgears on a LAN with your friends, and you keep on getting fragged due to low FPS, I really don't see why framerate matters. :3
AndrewR: dawid1, gearmarks recently fail down, at least with kms. from 750 to 182 fps on my machine
nanonyme: Wasn't it be synced somehow with refresh rate anyway?
MostAwesomeDude: nanonyme: Yep, 60FPS should be enough for anybody. :3
AndrewR: nanonyme, i don't think my crt monitor can do 182 at 1024x768
DanaG: oh yeah, is there anything interesting you can do with an RV100 that's not part of the DirectX version, for example, that it's compliant with?
nanonyme: AndrewR: Not that directly. :)
dawid1: no,its not gear-lan-party im worried about, i just found that specific value 2-3 times lower than others report and in fact i do observer very slow drawing of 2d elements on my desktop, another thing that worries me,is performance falls when enabling exa
dawid1: AndrewR: i didnt set the kms flag,because i dont understand what it does
MostAwesomeDude: dawid1: Are you certain that you're accelerated?
dawid1: MostAwesomeDude: glxinfo says direct yes
nanonyme: AndrewR: Hmm, might be a bug in glxgears too. Afaik it at least at one point wanted to sync to vertical refresh.
suokko: dawid1: glxinfo | grep renderer
nanonyme: (Bug/behaviour change)
dawid1: suokko: mesa dri r200
MostAwesomeDude: dawid1: Hm. Not sure why it's low; I'd wager that something on your system is different, either Mesa version, DRM version, X server version, AGP bridge, etc.
suokko: dawid1: with DRI1 you should get 1800-3000 in gears. With DRI2 it is somewhere around 800. (agpmode will give only 150-200)
dawid1: suokko: didnt enable dri2 and i dont see it load in the log
suokko: Is gears using a lot of CPU when it runs?
dawid1: mesa is 7.4.4, 20-30%
dawid1: X makes another 5-10
suokko: dawid1: you should pastebin Xorg.0.log and check ifyou have changed values with driconf
dawid1: suokko: this is my actually running log http://pastebin.com/m1ce5858b
dawid1: suokko: i did mess mith driconf, ill check the values
dawid1: suokko: so driconf recreates a config for root all the time, but by trial i tested it seems not to affect what i set in global conf,for all apps i set
suokko: dawid1: You can try to enable page flip from xorg.conf. It should boost performance gears
suokko: Also enabling HyberZ gives some performance boost
dawid1: suokko: doubling the result? :D i mean i dont have a problem with low values, the problem for me is they just show how mediocre the performance in reality is, i've enabled hyperz in /etc/drirc
suokko: Are you using compiz?
dawid1: suokko: no, i want a very fast and lightweight desk
dawid1: suokko: s/o told me either gtk or kde based compiled with cairo should do good
DanaG: hmm, #intel-gfx people aren't as helpful as the people in this channel.
bridgman: RadeonFeature looks good
bridgman: but the 6xx/7xx 3d code is having colour and texture issues fixed as we speak
bridgman: so probably "STALLED" is the most correct status ;)
bridgman: •"STALLED" means that whatever code has been written is accumulating color and texture similar to that 3 week old slice of pizza in your fridge.
suokko: gtk is not the fastest toolkit for 2D so you might want to test kde. You could try to set MigrationHeuristic "smart"
dawid1: suokko: but i'll have to use it anyway since its the only toolkit firefox supports,isnt it?
dawid1: suokko: set that where?
suokko: In xorg.conf
suokko: like EnablePageFlip
suokko: and there exists some qt port for cairo but I don't know how it works.
dawid1: suokko: ok,thx googled it had issues with kde :(
MostAwesomeDude: bridgman: I'm loathe to use STALLED since most of the code is under some sort of maintainence.
MostAwesomeDude: Even r300g gets the occasional patch or two.
suokko: stupid firefox locking :(
bridgman: sorry, I meant "stalled" because we're working on colour and texture ;)
dawid1: suokko: firefox is the app i have the most performance problems with
bridgman: bad joke
MostAwesomeDude: bridgman: XD
dawid1: switching tabs,not even complex sites in, can take loading cpu to 90-100 for upt o 10 secs
suokko: dawid1: that migrationheuristic did help me with firefox having lagging interface
dawid1: suokko: ok,im throwing it in for a test run, my conf is growing and will make a good soup or a graet boom in just a minute :D
MostAwesomeDude: bridgman: MOSTLY is for code that is more working than not-working, so I wouldn't classify r300g or and r600 code as MOSTLY yet.
suokko: thinks firefox 3.5 is going dangerous path.
dawid1: suokko: y that?
suokko: It is giving full multithreading to extension writers without making everything multithread safe
dawid1: sounds bad :D
dawid1: ok im killin my x,brb i think, if the pc doesnt explode or so
agd5f: AndrewR, airlied: http://www.botchco.com/alex/xorg/mesa_fix_drm_checks.diff
MostAwesomeDude: agd5f: Looks fine to me, don't have HW to test though.
AndrewR: agd5f, i will test as far as my kernel compiles.
nanonyme: Hmm, I'll seriously compile the 2.6.28 now... The new commits in r6xx-rewrite seem to have improved rendering to almost right but cause a lockup on my kernel. >.<<
airlied: agd5f: we shouldn't get createscreen on major 2
airlied: since dri2
agd5f: airlied: is the drm major version still 1 when kms is off?
airlied: yes
agd5f: ok, then the createscreen part can go
agd5f: airlied: http://www.botchco.com/alex/xorg/mesa_fix_drm_checks.diff
airlied: agd5f: we don't really support hyperz or microtile with ttm :-(
agd5f: that's what I was worried about :)
MostAwesomeDude: airlied: Yet, right?
MostAwesomeDude: How does TTM interact with HyperZ?
airlied: we probably need to asign hyperz use to a single app
bridgman: finally figures out why anyone would want to read and write the compressed z buffer
MostAwesomeDude: airlied: I thought HiZ was a combo of early-out Z buf and Z compression, right? I'm not quite seeing how it would confuse TTM. :T
MostAwesomeDude: Or is the Z buf compression not a predictable size?
bridgman: it's three things not two; early out, z compression, and hierarchical z (sorta like bounding boxes for z)
bridgman: the hierarchical z stores stuff on chip
bridgman: when you swap z buffers to support a different app you need to swap the meta-stuff as well
MostAwesomeDude: Oh.
MostAwesomeDude: The first two can be used without the third, though, right?
bridgman: AFAIK yes
MostAwesomeDude: I mean, I see the utility of pre-marking buffers as compressed, and how TTM and CS could interact to ease the pain of that.
MostAwesomeDude: But I don't think it's necessary.
bridgman: in section 8 I think "HiZ RAM" is on chip
MostAwesomeDude: Ah, so the early out of HiZ is different than Z top.
bridgman: actually I suspect they work together (as I cheerfully contradict what I just said a minute ago)
bridgman: early z probably uses the HiZ RAM; it's rejecting primitives/quads which have no hope of being visible
bridgman: I don't think it would do pixel-by-pixel checks in the depth buffer for that
bridgman: not sure though
MostAwesomeDude: Hm.
bridgman: 9.4.5 is kind of vague on this; it kinda reads that the entire z buffer operation is at top of pipe, which hadn't occurred to me before now
MostAwesomeDude: Ah.
bridgman: I may be confusing early z with z top; always thought they were the same but maybe not...
MostAwesomeDude: Yeah, I think that HiZ is a coarse-grain early-out right before the actual Z test, and the entire Z test setup can be moved to the top of the pipe.
bridgman: early out is always before the frag shader though, but z test might move ?
MostAwesomeDude: Oh. Hm.
suokko: Just a tough. Would it be possible to implement zero cost Z buffer clearing if just swapping between -1/Z and 1/Z modes? This would waste a bit for sign.
MostAwesomeDude: suokko: Possibly, but that's a rarity, I bet.
bridgman: I think you can get zero cost Z buffer clearing with HiZ anyways, can't you ?
suokko: I don't know about card details but that is jsut something that came to my mind after remember the trick to clear the 1/z buffer only every 4th frame.
suokko: That was using 2 bits for index of frame which was added to Z value
suokko: (Just for software 3D engine)
MostAwesomeDude: Well, that's an app-specific optimization, really.
spstarr: evening bridgman
airlied: MostAwesomeDude: sorry was afk, but yeah HizRAM use needs to be a single app or we need to swap it which might lose the benefit
spstarr: bridgman: caught a funnel cloud towards Markham, but not enough time to capture it on camera, it fizzled out
MostAwesomeDude: airlied: I take it there's not enough RAM in that chip to allow for multiple apps?
airlied: MostAwesomeDude: I don't think so.
MostAwesomeDude: Ah. Figures.
bridgman: spstarr; cool
MostAwesomeDude: So how do we arbitrate it? Who gets to have it?
bridgman: MostAwesomeDude; there's usually just enough to cover a big monitor
bridgman: if you had a smaller display/fb you could probably fit two copies in the ram, but that's getting pretty tricky
MostAwesomeDude: bridgman: So we only enable it once a depth buffer is above a certain size, and first come first serve.
bridgman: yeah, first come first serve might work, although you'd probably want to app detect compositors
bridgman: I imagine compositors don't need Z but you never know; if they don't use Z then I guess the first app to use Z gets it ?
suokko: What about desktop cube with 3D windows? :)
bridgman: next question ;)
MostAwesomeDude: bridgman: We could have a driconf option for it, and then use the app-specific ability of driconf to toggle it.
MostAwesomeDude: For example, compiz could have a force-disable HiZ.
airlied: yeah I think first full screen app that isn't a gl compositor
MostAwesomeDude: (Of course, what'd be *really* cool is if CS could automatically control HiZ without userspace intervention, but even glisse might balk at that. :3 )
airlied: I think he mentioned doing something like that
bridgman: or just reserve it for glxgears, the One True ThreeDee App
airlied: its also apparantly useful to use Z stuff for clearing the CB
airlied: but again I've no idea if that needs the special RAM (shouldn't think so)
bridgman: that would make gears go faster
bridgman: I think it does but not sure; somewhere there have to be magic bits saying "ignore what's in RAM under this tile"
MostAwesomeDude: airlied: Ooh, you could answer my question from yesterday. Do the blitter restrictions (need new CS, must flush) also apply to the pkt3s that control blits?
airlied: MostAwesomeDude: yes
airlied: the packet3s just translate to the packet0
MostAwesomeDude: Wanting to make my surface_copy not suck horribly on blitter fallbacks.
airlied: in theory we can shove 2D and 3D stuff in one CS
airlied: but I got better behaviour on certain gpus by not doing it
MostAwesomeDude: airlied: I can reserve two CS objects. One for 3D which is nice and big (like 64kb) and one for rare 2D ops (like 1kb).
MostAwesomeDude: No, wait. That's stupid.
MostAwesomeDude: 'cause glCopyPixels doesn't happen on its own.
MostAwesomeDude: Never mind.
MostAwesomeDude: Screw it. I'll stick with the 3D engine only, and revisit the PIPE_CAP_BLITTER idea for signalling to st that we can't do overlapping blits.
agd5f: fast z clear is another feature of hyperz
MostAwesomeDude: agd5f: Does that clear 16-bit and 32-bit buffers to an arbitrary value?
agd5f: MostAwesomeDude: yeah
MostAwesomeDude: So why aren't we using that instead of point clear? :3
agd5f: MostAwesomeDude: probably could
agd5f: I think there are some limits though
agd5f: also, the buffer has to be tiled
bridgman: microtiled IIRC
airlied: and since we can't blit a microtiled buffer that'll suck without pageflipping
MostAwesomeDude: Tiling is per-pixel IIRC, which means that tiling would not matter for a clear.
MostAwesomeDude: (I could be very, very wrong.)
agd5f: MostAwesomeDude: tiling is per buffer
bridgman: I think tiling is per surface/buffer
bridgman: note to self; searching for "micro" in a document written by Advanced Micro Devices is stupid
MostAwesomeDude: agd5f: No, I mean, the way that the swizzle works... But I just realized why it wouldn't be efficient.
MostAwesomeDude: Theoretically, would work without tiling, but I guess we should probably make tiling work at some point anyway.
agd5f: MostAwesomeDude: it would only work for buffers that were a multiple of tiles if the buffer was non-tiled
agd5f: wouldn't work for shared buffers
bridgman: would it hurt if we just made all buffers a multiple of 2k ? (haven't checked 6xx/7xx yet)
MostAwesomeDude: agd5f: Right. Which would waste a few dozen to few hundred pixels per buffer.
MostAwesomeDude: So it'll have to wait until tiling works.
suokko: How about using fast clearing up to multiple of 2k and remaining would be done with slow one?
MostAwesomeDude: suokko: Because the "slow" clear is still an extremely fast clear, and has the advantage of working on any renderbuffer.
airlied: wasn't going to blame kms for a post-resume hang but realised he wasn't running it
airlied: MostAwesomeDude: with TTM at the moment we don't do the point clear thing
airlied: MostAwesomeDude: we just draw a tri
MostAwesomeDude: airlied: *I'm* doing a point clear right now, and it seems to work.
airlied: yeah I just got lazy when doing r100/r200/r300
MostAwesomeDude: Point clears are easier IMO. Fewer coords, less chance to fuck up. But whatever.
MostAwesomeDude: (Of course, it took me like a week to get point clear working that first time. :3 )
airlied: MostAwesomeDude: we have some generic mesa clear code, I stole from intel.
MostAwesomeDude: Tomorrow's Phoronix: "AMD Radeon code stolen from Intel: Dave, what have you done?!"
airlied: MostAwesomeDude: most of the code is from intel :)
airlied: MostAwesomeDude: so is a lot of my displayport support ocde :)
MostAwesomeDude: airlied: Oh, I know. I have a rename.py script I used to create r300g from i915simple. :3
Veerappan: airlied: that post-resume hang. actual hang, or just a corrupted screen with the kernel still responsive?
AndrewR: airlied, there was also mesa/libdrm patch (for kms-colortiling testing). because X comes up really well tiled, but i can see Eterm and type glxgears into it, and it quits with -22
airlied: Veerappan: whole laptop locked up about 5 mins after resume
Veerappan: ahh, different than my issue then.
airlied: AndrewR: there is a mesa patch for it
airlied: it just emits relocs for pitch regs
MostAwesomeDude: Righty. Well, gonna reboot into dev, maybe do more r300g. I need to do more shatter; there's a midterm eval next week. :3
AndrewR: airlied, can't find it
airlied: AndrewR: oh I probably didn't post it :)
airlied: since I was most interested in discusson on the kernel bitys
AndrewR: airlied, i think for testing on rv280 i need to modify radeon_legacy_crtc.c ?
airlied: AndrewR: oh I didn't do that bit either
airlied: yeah you need to do tiling on those buffers.
AndrewR: airlied, strange, i have X but radeondrmfb console busted
AndrewR: airlied, not really. (gtk2 apps works, but most apps very well tiled again)
AndrewR: sorry (i broke something really badly)
AndrewR: airlied, i think i have *something*
AndrewR: airlied, http://pastebin.ca/1481456
airlied: AndrewR: the old crtc modeset doesn't have the tiling setup code, it all inthe -ati DDX
airlied: it probably only 5-10 lines of code I think
airlied: oh the code was already therre :)
airlied: if you can get the fbcon with tiling working, then the DDX should work okay
AndrewR: airlied, i have only X working. Strange, drmfb was worked before ..looks like swapped flag somewhere?
airlied: maybe you have micro tiling on when you shouldn't or something
AndrewR: i mean right now i'm in X, and everything renders correcly, but drmfb all sliced into pieces. Before (when i tested your initial patch) drmfb was ok. But there always was " *ERROR* setting tiling on object 1 4096"
AndrewR: airlied, anyway, this is just playing around with code from my side .... i think i will go to bed soon
airlied: yeah ERROR in that case means debugging :)
AndrewR: airlied, it is possible what initially (and now) framebuffer bo actually not tiled? and only X frontbuffer correctly tiled, but because CRTC thinks they both tiled, i get correct result only in X
AndrewR: X frontbuffer and radeondrmfb buffer are separate for now?
airlied: yes
airlied: and my patch should set the drmfb buffer to macro tiled
airlied: hmm have a clean DDX, just no fonts :(
airlied: okay DDX KMS support patch pushed (still off, can't get any AA fonts with it :(
airlied: woot fonts
MostAwesomeDude: airlied: Woot. What was it?
airlied: MostAwesomeDude: missing DRM vresion checks
airlied: I should have looked at dmesg :)