Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2008-11-02

Search This Log:


agd5f: spstarr: the basic pipeline states with vertex buffers which can contain coordinate and color data for primitives and textures
agd5f: s/states/starts/
agd5f: vertex shaders are used to transform those vertexes
agd5f: in arbitrary ways
agd5f: some of the results of the vertex part gets fed into fragment shader which is used to determine the color of the pixel that gets rendered to the render buffer
agd5f: the fragment program can be used to sample textures to transform vertex colors, fog, etc.
agd5f: the result in then rendered to the render buffer
agd5f: s/in/is/
agd5f: that's of course very simplified
spstarr: is there a reason there is this distinction? a pixel itself can be 2D or 3D rendered depending on the information of that pixel
agd5f: vertexes can be a mix of color and geometry data
agd5f: fragments are all color
agd5f: what do you me 2D or 3D rendered?
agd5f: s/me/mean/
spstarr: well, how the data of a pixel is stored
spstarr: its geometry, colour RGB
agd5f: a pixel is just color
spstarr: right
spstarr: its quite technical, i still need to get my head around vertexes
spstarr: i gather this is the data representation of properties, plotted points
spstarr: you feed it in the pipeline to build the representation of the pixels that will be seen on screen
z3ro: a vertex just specifies a point in the coordinate system. you can make primitives (triangles/quads/etc) out of vertices.
agd5f: yeah. a mix of coordinates for primitives and textures and/or colors
z3ro: eg a triangle will require 3 vertices
spstarr: 3 points
z3ro: yeah
z3ro: each vertex specifies it's position in space, along with other attributes (color etc)
spstarr: but if it's just a point, how does it define the colour for the whole primative?
agd5f: is you wanted to represent a triangle with a different color at each vertex, each vetex would look like X, Y, Z, color
z3ro: for 3d, you specify a vertex with 3 values (X, Y, and Z)
agd5f: you usually define a color for the vertex
agd5f: or you map a texture to the primitive
spstarr: z3ro: but thats just going to plot a dot in 3 places in 3D space
spstarr: per vertex
agd5f: textures have coordiantes as well since you need to know what coordinate on the texture maps to a what coordinate on the primitive
z3ro: spstarr: if you tell opengl you want to render triangles, it will interpret these 3 points as the vertices for a triangle.
spstarr: because it knows 3 points represents a triangle always?
z3ro: yeah
agd5f: spstarr: you say what primitive you want to render
z3ro: opengl knows it needs 3 vertices for a triangle, 4 for a quad, etc.
z3ro: and you can use glBegin to say what you want to render.
spstarr: ok so when you pass into the pipeline you give it the coordinates of each point (X, Y, Z) a fragment for the color of the whole triangle and then pass it
agd5f: spstarr: you can also render rectangles with 3 vertexes since the 4th one can be interpreted
agd5f: spstarr: usually a color per vertex
spstarr: thats confusing me
spstarr: i know we're viewing the scene as 3D in this case
spstarr: OH
spstarr: per each side?
spstarr: of the triangle?
agd5f: so you might define a triangle as x1,y1,z1,c1, x2,y2,z2,c2, x3,y3,z3,c3
agd5f: a color per point
spstarr: but when rendered GL will fill in each side (from each point) that color?
agd5f: dependig on the shading, but in a simple example you will get a 3 way gradient
spstarr: excluding altering effects like light, dithering, etc.. which you can perform on the primative in the pipeline
spstarr: right
spstarr: agd5f: assuming no shading, (if thats by default)
spstarr: I would get a 3D triangle with 3 different colors if i didnt set shading
agd5f: so point 1 would be color1 fading to color 2 and 3, point 2 would be color 2 fading to color 1 and 3, etc
spstarr: so this is done by default? unless you dont want fading?
spstarr: http://www.anandtech.com/video/showdoc.aspx?i=2044&p=3
z3ro: spstarr: here is a quick example that shows drawing a single triangle with immediate mode: http://pastebin.ca/1242938
z3ro: note the values there are bogus... but it shows how you specify the 3 vertices of the triangle (glVertex)
z3ro: each vertex having 3 values (X, Y, Z)
z3ro: and specifying a color for each vertex (glColor)
agd5f: spstarr: http://www.nuclex.org/system/files/images/nodes/101/triangle-rotating.png
spstarr: ok
spstarr: so it is from the point
agd5f: yeah
z3ro: agd5f: heh I was just trying to find a picture like that. :)
spstarr: each point stores a color
spstarr: i understand now
z3ro: cool :)
spstarr: and when rotated the top point surrounding the 3 sides would be green, blue for the other 2 sides, and red for the other 2 sides?
spstarr: er 2 sides for green since we see one
spstarr: but something i don get from that image is how is the color distributed
spstarr: the fading between them or is that due to lightning
z3ro: opengl interpolates the colors specified at the vertices.
agd5f: spstarr: that's why you have fragment programs :)
spstarr: it just looks like red is the more dominate color
spstarr: aha
spstarr: "Color and depth values are assigned for each fragment square."
spstarr: and in a fragment program you can adjust the shading
spstarr: but you call it a program
spstarr: this is basically a small 'micro' routine?
agd5f: spstarr: they are little programs that transform either vertex data (vertex program) or pixels (fragment or pixel shader)
spstarr: or a instuction set in a buffer
agd5f: they actually are little programs written in a GPU specific language that the GPU loads and executes on some set of data
spstarr: but OpenGL interprets this in a universal form when passed to the GPU via graphics driver?
z3ro: from the users perspective, the programs are written in either ARB_vertex_program
agd5f: yeah you write your program in glsl or ARB_fp/vp and the driver translates it into GPU specific code
z3ro: or fragment program
spstarr: ah
z3ro: (sorry, pastes extension name including a newline :P)
z3ro: *pasted
agd5f: that's why you hear so much about shader compilers
agd5f: high level code is compiled into GPU specific instructions
spstarr: the DRI drivers (some) have a GLSL?
spstarr: and or a ARB_fragment_program / ARB_vertex_program?
z3ro: iirc intel has glsl
z3ro: r300 just supports arbfp/vp
z3ro: r300 as in the driver named r300.
spstarr: but from writing GL code from userspace it is not for the user to care about how that is interpreted in the driver level?
agd5f: yeah
spstarr: since it is common representation from OpenGL
spstarr: ok
agd5f: that's the point of the driver
agd5f: to convert a common API to a hw specific one
spstarr: right
spstarr: so each primitive that is drawn must be done with glBegin() glEnd() and only one primitive at a time?
spstarr: or you can draw multiple primitives per program
z3ro: thats where you can use arrays of vertices and indices to draw multiple primitives at once.
z3ro: which is often much faster than immediate mode.
spstarr: as long as its the same kind of primitive such as 4 triangles?
z3ro: right
spstarr: ok,make sense
z3ro: but you could draw multiple triangles with immediate mode, too. just glBegin (GL_TRIANGLES), then specify 6 vertices.
z3ro: that will cause opengl to draw 2 triangles.
spstarr: right, because there's 3 verticies per triangle
z3ro: exactly
spstarr: but OpenGL does not deal with 2D planes does it? just 3D?
spstarr: or you can draw a triangle without depth
z3ro: you can still do 2d with opengl, yes.
spstarr: ok thought you can
spstarr: so basically, the DRI/gallium driver is just storing the representation of what OpenGL returns in memory in tiles or linear memory?
spstarr: and that is split up into different segments where needed to store vertex/fragment programs the driver will implement
z3ro: the driver takes the opengl state and translates it into something the hardware understands.
spstarr: so then if we want to write a ddx state for gallium, that has nothing to do with opengl
spstarr: i would need to take what EXA does and reinterpret this state into the driver
spstarr: so over my head right now thinking about this is way out there
agd5f: gallium has a front end and a back end
agd5f: the front end could be GL or EXA or XvMC and the back end generates gpu specific instructions
spstarr: ah, ok
spstarr: so how would X load that frontend? the same as EXA is loaded now except this would be hooked into gallium instead?
airlied: with a gallium driver it already has the AIGLX driver loaded, so probably just needs a call to init the accel stuff
spstarr: so then i would just need to figure out how gallium frontends pack their data so the backend can get it rendered via the gpu?
airlied: you would need to translate the EXA or X render ops into TGSI
airlied: and connect pixmap to buffer allocations.
airlied: you could probably do it all using the sw backend.
spstarr: TGSI?
airlied: without ever writing a hw driver.
spstarr: as a start yes
spstarr: in fact, that would be the natural progression of EXA
airlied: would be quite easy to validate the code was working before touching a hw implementation.
airlied: thats what the XvMC guy did...
spstarr: it would be like XAA actually for gallium :)
airlied: http://www.tungstengraphics.com/wiki/index.php/TGSI
spstarr: well, the sw rendering anyway
airlied: it really would replace the exa/fb/pixman using the gallium sw renderer.
airlied: not like XAA at all.
airlied: EXA/XAA both use the same sw renderer. fb/pixman
airlied: my main worry would be getting the same perf from a gallium sw renderer as the fb/pixman ones.
spstarr: there would be an overhead
spstarr: but even then it would be a good intro exercise
airlied: there is already an Xrender to GL conversion library.
airlied: so doing render to TGSI might not be that bad.
spstarr: so what driver would use this EXA frontend? or it could be used by any gallium driver? the would just load the frontend needed?
spstarr: i assume I need a gallium driver initially so that it can load the frontend?
airlied: the frontends are generic.
airlied: so the sw backend is fine for writing the code.
airlied: as I said xvmc did it that way, used sw to initially write it and then backended onto nouveau when testing it on real hw.
soreau: agd5f: FWIW I got it to display with 1024x768 but there were obvious timing problems I could not solve. xrandr still reported 800x768 though it was running at 1024x768, but artifacts and all everywhere (on the tv)
spstarr: airlied: where is his code?
spstarr: that would be a good help for me to see how this is done
spstarr: http://www.bitblit.org/gsoc/g3dvl/index.shtml ?
airlied: spstarr: http://cgit.freedesktop.org/nouveau/mesa/log/?h=gallium-0.1
airlied: yup thats the project.
spstarr: thats the hw backend, is the sw one somewhere?
airlied: the frontend is the same code, the backends are the drivers so its all in there.
airlied: thats the whole point of frontend/backend splits
spstarr: ah
spstarr: looking at it
agd5f: soreau: you should be able to fix the randr side in radeon_modes.c (where the mode gets added) and in radeon_output.c (radeon_mode_valid())
agd5f: but the rest is the hard part
soreau: agd5f: Unfortunately as I stated before, this is way over my head. I just tinkered with radeon_tv.c and skimmed through some of the other source
spstarr: http://cgit.freedesktop.org/nouveau/mesa/commit/?h=gallium-0.1&id=c11a7ec821d41b91a3825c5abfb4687c98b5bf98
soreau: agd5f: The only other driver coding I've done was for my custom hw; now it works with gamecon driver ;)
agd5f: soreau: probably your best bet is to dump regs using the vbe to set the mode you want on the tv. or convince benh to add them using his macos dumper
agd5f: :)
soreau: agd5f: Yes, you said that and I glanced at the bios code, but I really have no idea what you mean :P
agd5f: soreau: use a program like vbetool to use vbe (vesa bios extensions) to set a mode on your tv. then use radeontool to dump the radeon registers after that mode is set
soreau: I'm not very convincing and not qualified for this. I'll just accept the hard coding as it is and hope someone with the appropriate skills will fix this eventually
soreau: So basically, i'm just stopping in to say 'hi' :)
agd5f: soreau: IIRC, if you create the dump, I can code it up :)
soreau: I can't (don't know how) TBH
agd5f: soreau: I wrote some instuction on this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=12007
soreau: Ok, I will definitely have a look
spstarr: ok, i will need to study the EXA code and then map it to what a gallium frontend needs
benh: agd5f: anybody else with a powerpc mac can use my dumper btw :-)
z3ro: hmm I thought updating my torrent client would be pretty quick... so it just finished compiling boost after like an hour. :(
z3ro: could have probably got a movie by now. =/
tlp: hehe
tlp: so is the DRI stuff between radeon/radeonhd pretty much the same?
airlied: tlp: the 3D driver is the same driver, the setup code in the DDX is also pretty close.
tlp: ah
tlp: gave it a try to see if I'd get different results with programs--that would explain why there are none
MostAwesomeDude: soreau: Strange to see you in here. What's up?
soreau: MostAwesomeDude: Hi, what's up man?
MostAwesomeDude: Nothing much, just taking a break from homework.
MostAwesomeDude: airlied: Is it possible yet to allocate a page of video memory using GEM? I've been thinking about OQ work, and I think I could write it out.
spstarr: tomorrow i need to finish my stuff for KDE then look at an EXA frontend for gallium
soreau: MostAwesomeDude: I just installed Intrepid (using the open drivers) and after discovering (here) tv-out is hard coded for 800x600 I figured I'd do some hacking
soreau: MostAwesomeDude: I would like to see 1024x768 tv-out work with the open drivers
MostAwesomeDude: We'll need a version bump for the getparam change. If we don't find radeon drm 1.30 or whatever, then disable arb_o_q.
MostAwesomeDude: soreau: Tried xrandr mode adding?
MostAwesomeDude: Not sure about TV-out status.
soreau: MostAwesomeDude: Uh...
soreau: yea
soreau: MostAwesomeDude: It's hard coded
airlied: MostAwesomeDude: version bump is fine or a new getparam.
MostAwesomeDude: Icky. Well, good luck.
airlied: I dislike linear versions.
airlied: MostAwesomeDude: you want a page of VRAM or a page of main memory?
MostAwesomeDude: airlied: I *think* a page of VRAM. The r5xx docs aren't super-clear. I want a page of whatever ZPASS_ADDR points to.
soreau: MostAwesomeDude: I'm mostly stopping in to say hi, I failed at doing anything truly productive :P (I got 1024x768 to work but there are major timing issues)
airlied: MostAwesomeDude: it can be either I think, the memory map covers everything.
MostAwesomeDude: soreau: Don't worry, I too am not productive. :3
airlied: probably makes sense to us a page of GART>
soreau: hehe
airlied: however I stull think there is enough space in the current ring read ptr page
soreau: MostAwesomeDude: Don't worry, I never had high expectations :D
soreau: (of anyone for that matter, including myself)
MostAwesomeDude: airlied: Either or, really. I'm assuming that we're just going to have DRM emit cmdpackets for the EndQuery stuff, so we should be able to do multiple queries at once.
airlied: so currently the ring_rptr buffers is allocated in GART.
MostAwesomeDude: How big are these pages? We're gonna want room for at least a few dozen OQs at once.
airlied: we reserve the first 32 dwords for ring bits, then we have 8 dwords for scratch regs
airlied: possible safe to say 16 for scratch
MostAwesomeDude: And after those 48 dwords, it's just empty space?
airlied: which leaves 3904 bytes
airlied: so I think you should be able to fit some stuff in that at least to start testing.
MostAwesomeDude: 3904/64 = 61 pairs.
MostAwesomeDude: So that's fine for two-pipe setups.
airlied: so for example of ring_rptr see where we program RADEON_CP_RB_RPTR_ADDR
MostAwesomeDude: 'k.
airlied: or look at the RADEON_SCRATCH_ADDR chear
airlied: chea
airlied: which just reads back what we told the card to use for RB_RPTR_ADDR
MostAwesomeDude: And this will work on non-GEM setups, too? Should I be working from my 2.6.26 tree or my 2.6.27 GEM tree?
airlied: MostAwesomeDude: no need for GEM for any of this
MostAwesomeDude: Cool.
airlied: ring_rptr is in the drm for ever.
airlied: on the GEM kernel we use GEM to allocate the ring-rptr
airlied: otherwise the DDX allocates it.
MostAwesomeDude: 'k.
MostAwesomeDude: Well, I need to go do stuff, but I'm gonna work on that tomorrow afternoon.
MostAwesomeDude: I mean, it can't be harder than fog.
tlp: I don't suppose the driver spits out errors/verbose info anywhere?
rmh3093: airlied, ping
soreau: I even *tried* to make it spit out kern log messages and I couldn't :p
soreau: tlp: Maybe 'dmesg' ?
airlied: rmh3093: pong
MostAwesomeDude: 'k, can't sleep.
MostAwesomeDude: airlied: getparam seems like the best place to do EndQuery. I know both you and glisse agree that we shouldn't add more ioctls, so I wanna piggyback on one of these...
z3ro: MostAwesomeDude: yeah, sucks not being able to get to sleep... on the plus side, I usually end up getting a lot of work done.
z3ro: at least until I crash. =/
MostAwesomeDude: z3ro: Indeed. I am learning more about the DRM than I ever thought I'd (want to) know. :3
z3ro: heh :)
MostAwesomeDude: airlied: RING_LOCALS; BEGIN_RING(); OUT_RING_REG(); ADVANCE_RING(); right? And use CMDPACKET0() to make cmdpackets?
icewaterman: are the specs for r6xx available and the driver is just not finished yet or are the specs on them (2d/3d) still closed?
z3ro: icewaterman: only the ISA is public at the moment.
icewaterman: hm, doesnt seem like amd was serious, as these cards are already 2 generations behind and older than amds promise to release the specs. at least they did release the specs on r5xx
icewaterman: but looks like a one-time-shot to me
z3ro: icewaterman: it's still being worked on by bridgman and agd5f afaik.
z3ro: iirc there are still some IP issues to sort out, and I think bridgman was on holiday for a bit, too.
MostAwesomeDude: icewaterman: Trust us when we say that stuff's on the horizon.
icewaterman: btw. is there some sort of jit compiler for opengl commands?
MostAwesomeDude: How so?'
MostAwesomeDude: It's already written in an unholy mixture of C and assembly...
icewaterman: MostAwesomeDude: i meant for the driver to order the commands given in order to prevent pipeline stalls in the card
MostAwesomeDude: icewaterman: Well, OGL docs mandate that things be done in a certain order in the stack.
MostAwesomeDude: As for state emission, yeah, we try to not re-emit state if it's not dirty.
MostAwesomeDude: But if somebody wants, say, an occlusion query, we *have* to drain the z pipe. There's just no other way.
icewaterman: hmm ok
MostAwesomeDude: And when used properly, an occlusion query is still cheaper, even though it causes stalls, then drawing several hundred vertices instead.
MostAwesomeDude: *than, even.
icewaterman: hm, ok, another question then: why is the closed driver much faster than the open one? is that because not all of the opengl command set is yet supported by the open driver?
MostAwesomeDude: Well, there's a few reasons.
MostAwesomeDude: Biggest one is memory management, especially buffer and texture management.
icewaterman: from what i understand someone is already working on that at intel, right? (GEM)
MostAwesomeDude: Second one is certain features that we must fall back on. Specifically, occlusion queries, two-sided stencil bugs, no compressed textures...
MostAwesomeDude: Memory management is being worked on, yes.
icewaterman: ok, last question: there is no specific reason that opengl 2.0 is not supported other than mesa is not yet supporting it, right?
MostAwesomeDude: Wrong both ways.
MostAwesomeDude: Mesa supports OGL 2.1.
MostAwesomeDude: OGL 2.0 has a ton of things that we don't have.
MostAwesomeDude: First, we're not even at 1.5 yet. We're missing fog coords and occlusion queries.
MostAwesomeDude: And then we need shader management, a crapload of shader instructions that simply don't exist in hardware, and certain kinds of framebuffer objects.
icewaterman: ok, sounds like a lot of work to be done
MostAwesomeDude: A bit, yes. But it's doable.
bobbens: didn't you have fog coords done or near completion?
MostAwesomeDude: bobbens: Yes, quite a few times.
MostAwesomeDude: But fog is my evil nemesis, and has defeated me soundly each time.
icewaterman: MostAwesomeDude: maybe you should plan all your steps before implementing them :)
icewaterman: that way you do not get defeated near the end but at the beginning, which saves you a lot of time each approach :)
MostAwesomeDude: It depends.
MostAwesomeDude: airlied: First cut. http://pastebin.ca/1243091
MostAwesomeDude: getparam's value should eventually return a number which is an offset into the page, so multiple queries can run simultaneously.
enouf: Just want to say a hearty Thank You to all who do all this hard work .. (you know who you are)
MostAwesomeDude: Bedtime now.
z3ro: lol, just had a what the fuck moment. walked out into the kitchen and heard "turn left, then turn right"
z3ro: took me a second to realize someone left a GPS on. :P
rmh3093: airlied, ping
rmh3093: does anyone know how I can use gdb to debug the ati driver, i am getting this horrid memory leak that I want to track down
otaylor: rmh3093: To do, that you need two computers
otaylor: rmh3093: Since attaching to your X server from within the X server is a bad thing
otaylor: rmh3093: But beyond that, it's pretty much like gdb'ing any other program these days.
rmh3093: yeah i noticed once i try attached gdb to the process things get nasty
otaylor: rmh3093: gdb -p `/sbin/pidof Xorg` /usr/bin/Xorg to attach to it or whatever
agd5f: rmh3093: http://wiki.x.org/wiki/Development/Documentation/ServerDebugging
CartoonCat: hellos
CartoonCat: is it me, or does the radeon driver not support the RS485/1100 IGP chipset? It is identifing mine as xpress 200m
rmh3093: run
rmh3093: ok so now that I have gdb connect i should just try and crash it right
rmh3093: of course im sure I wont be able to make it crash when i want it to
agd5f: CartoonCat: should work fine. all the rs4xx variants are pretty similar
CartoonCat: agd5f: well I have it working. Then a kernel recompile and poof, fglrx and radeon both went all to crap
CartoonCat: now ive got radeon installed again, but can not get 3d working
CartoonCat: can I force the chipset ID or would that be bad mojo?
rmh3093: well not the bug that I expected
rmh3093: but when I tired switching to a different vt
rmh3093: i got some error in XkbDDXSwitchScreen
CartoonCat: whats painful, is this RS485 underperforms my 9100 IGP =(
CartoonCat: oh this is odd, i have no ati_agp module on this box?? no agpgart in lsmod
CartoonCat: ! ok I just found a entry on freedesktop.org that says "full suport for .... hardware 3D (except R300 and IGP series cards)
CartoonCat: does that mean there is NOT 3d accel for the RS485/ 1100 IGP ??
otaylor: CartoonCat: More likely, it measn that your system is misconfigured
agd5f: CartoonCat: it will detect the card properly
agd5f: probably you need a newer drm or something
CartoonCat: otaylor: well thats what I assumed and why I came here, im sure its some stupidly simple thing I missed
CartoonCat: how to I find what version DRM i have?
agd5f: CartoonCat: check your xorg log and see if direct rendering is enabled
agd5f: or run glxinfo
CartoonCat: (WW) RADEON(0): Option "DRI" is not used
CartoonCat: xorg log has dri loading
agd5f: CartoonCat: can you pastebin the full log?
CartoonCat: sure
agd5f: CartoonCat: the rs4xx chips are not agp, so no agp module is required
CartoonCat: ah that adds up lol
agd5f: brb
CartoonCat: http://pastebin.com/d3edb8373
adamk: (II) RADEON(0): Direct rendering broken on XPRESS 200 and 200M
adamk: That's not been the case for a little while now, so I'm assuming you need newer drivers.
CartoonCat: mmm, ok thats weird/odd cause gentoo keeps fairly up todate
mcgreg: with current xserver/mesa/xorg-ati (radeon) git stuff .. should stuff like googleearth work? it used too, but I havent updated a looong time now
mcgreg: using r500 card (x1300)
adamk: mcgreg, Works here.
adamk: I built everything about a week ago.
mcgreg: well, when I tested googleearth 10 minutes ago it freezed X.. I had to hardreboot
mcgreg: wine World of warcrat also used to work ... but it didnt when I treid it as well
mcgreg: perhaps I missed something important?
adamk: Do you have "disable low impact fallbacks" enabled in driconf?
mcgreg: well, wow works but it seems like unaccelerated 3d
mcgreg: driconf reports (the gui) that it is disabled (yes to disable...)
mcgreg: easy games like quake3 work
mcgreg: war warctaft3 is unaccelerated as well .. and that used to work too
mcgreg: well, I wonder whats wrong here
mcgreg: the only from dmesg is "[ 3901.065687] Too big adjustment 32"
mcgreg: perhaps too old drm modules?
mcgreg: Initialized radeon 1.29.0 20080528 on minor 0
adamk: 1.29.0 is what I have.
adamk: Run your apps with 'LIBGL_DEBUG=verbose' and see if you get any errors from the library.
mcgreg: oha
mcgreg: libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: wrong ELF class: ELFCLASS64)
adamk: You're trying to run 32 bit apps on a 64 bit distribution, and you don't have the 32 bit libraries installed?
adamk: Just a guess :-)
mcgreg: but it was always like this and it worked fine
CartoonCat: mmm, is there any known issues with 6.9.0 on amd64??
adamk: mcgreg, Well apparently it's not working fine now. It's looking for 32 bit libraries in /usr/lib/dri/r300_dri.so and it's finding the 64 bit versions... At least that's my understanding.
rmh3093: what is libtxc_dxtn.so,
rmh3093: when i run glxgears I see something about not being able to find it
adamk: http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html
soreau: Does anyone know where the source to vbetest might be found? Or a tool that can do what's described in comment #35 of https://bugs.freedesktop.org/show_bug.cgi?id=12007
rmh3093: soreau, http://distfiles.gentoo.org/distfiles/lrmi-0.10.tar.gz
glisse: is swtcl know to be broken ?
spreeuw: hi, I'd liek to report the prey-demo isnt working
spreeuw: it renders the models gray and textureless
xnguard: spreeuw: Is the full Prey port working any better?
soreau: rmh3093: Thanks, but seems it only builds using the ebuild, that source alone I cannot get to compile
rmh3093: so u need a patch for >2.6.26
rmh3093: 1 aec
rmh3093: sec
rmh3093: soreau, http://rafb.net/p/HoLT4t42.html
soreau: rmh3093: You're absolutely right. Thanks a lot :)
rmh3093: np
CartoonCat: mmm, ok, well, http://pastebin.com/d6d0924a4
CartoonCat: welp still in the same boat, no dri/glx
CartoonCat: running radeon 6.9.0 on amd64 btw
soreau: compiled with dri flag?
CartoonCat: mm, one sec
CartoonCat: yup, as module
CartoonCat: and its loaded, drm 82856 1 radeon
soreau: Not in your kernel.. I mean for x11-drivers/xf86-video-ati
CartoonCat: oh oh, yea Installed versions: 6.9.0(09:01:44 11/02/08)(dri -debug)
CartoonCat: went from 6.6.3 to 6.9.0 today cause someone here pointed out some bugs that effect 200M chipsets (whick, I ahve RS485 but keeps being detected as a 200M)
CartoonCat: any ideas?
CartoonCat: is there a idiots guide to installing the radeon driver? I do not remember it being this hard heh
robokopp: ask your distribution
MostAwesomeDude: Mornin'.
CartoonCat: robokopp: yea already did those intructions, thats how i got here
MostAwesomeDude: I'm guessing nobody's looked at my DRM patch?
MostAwesomeDude: airlied: I know you're asleep... Is it safe to return pointers to that GART page to Mesa, and let Mesa poll them, or do we need another getparam to have the DRM poll and return the value?
airlied: MostAwesomeDude: you should use a setparam to setup the OQ I think
airlied: what do you need to return the sum of all the values from each pipe?
airlied: if that just use a getparam to return that value.
MostAwesomeDude: airlied: Okay. Am I allowed to take the pointers to GART back into Mesa, or will I need a getparam to check them?
airlied: don't expose the pipe internals to userspace.
fbred: hey, i'm having trouble enabling tv-out on a ati 9600 card. xrandr says the screen is 0mm x 0mm, any ideas?
airlied: I don't think the ring_rptr has a userspace mappin
MostAwesomeDude: 'k.
MostAwesomeDude: I'll move what I've got now to setparam, and then write a getparam to get them.
airlied: otaylor: https://bugzilla.redhat.com/show_bug.cgi?id=469556 any ideas? :)
otaylor: airlied: Give me a few mintes, I don't want to run a web browser (opossibly crashing my r300 driver) on this machine, while I have X on my other machine under gdb :-)
airlied: hehe no worries... it looks EXA related, I'll try and test it on r300/r500 they are only looking at r200.
MostAwesomeDude: Doing all those little gradients in HW seems kinda spendy.
You_: airlied: I had similar problems with RV570 and packagekit a few days ago.
You_: I blamed it on packagekit and it went away after a few days, so I assumed it was fixed there
You_: https://bugzilla.redhat.com/show_bug.cgi?id=468608
MostAwesomeDude: airlied: How to distinguish different query numbers when doing a setparam? Kinda need to be able to get the query number back from DRM...
MostAwesomeDude: So, like, getparam that sets up the addrs to read from, and that returns the query number, which we put into the Mesa query obj.
MostAwesomeDude: Then another getparam that takes the query number, and returns the query results.
You_: airlied: you may want a confirmation from the reporter if the report is still valid after update to latest rawhide
airlied: MostAwesomeDude: ah in that case you'll need to use getparam.
airlied: MostAwesomeDude: can one context have more than one query running?
MostAwesomeDude: airlied: Right. I just need to come up with two different names. END_QUERY and NUM_SAMPLES, maybe?
airlied: start query and end query :)
MostAwesomeDude: airlied: Yeah, there's no real limit. Begin/EndQuery pairs, and then userspace can check them whenever they want.
airlied: why two stage?
airlied: why not return the query results?
MostAwesomeDude: We'd have to stall and poll for the results. The OQ spec is designed to be async; clients should do queries, then go off and do some maths and come back later.
MostAwesomeDude: And we don't get the results until at least that part of the ring buffer gets read.
MostAwesomeDude: So doing it all in one go would mean letting the ring run dry too.
airlied: so the app polls?
MostAwesomeDude: Yeah. They have IsQueryAvailable, which is non-blocking (EAGAIN, etc.) and WaitQuery, which blocks for it.
airlied: ah cool... yeah so a query ID is probably what you want.
MostAwesomeDude: So apps can while(!IsQueryAvail()) { do_maths(); }
MostAwesomeDude: Mesa's already got internal query IDs; I was going to attach the pointer offset in our page back to userspace as the DRM-side ID.
airlied: agd5f: how complete are the pre-atom bootup table handlers?
MostAwesomeDude: airlied: Also, queries are begun in Mesa, with a state atom, so no need to call into DRM for that. Only for ending query, and getting results.
airlied: MostAwesomeDude: cool.
agd5f: airlied: you mean the asic init stuff?
agd5f: that should be pretty complete
tlp: has noticed his room is warmer since he installed this radeon card
airlied: agd5f: yup the old tables, it might just be bios posting busting things.
agd5f: airlied: what card? I've hrad rn50's can be problematic
airlied: agd5f: I think its an r300 of some sort in a Dell.
airlied: but just trying to track down if the s3 resume quriks are causing issues.
agd5f: you also need to set the mode afterward.
airlied: yup doing that, I reset all the modes.
airlied: agd5f: actually disnable qui4rks works.
airlied: so it seems fine.
spstarr_coding: airlied: I tried suspend to disk, w/ kms it locked up, non-kms it works
agd5f: cool
mentor: "disnable qui4rks" sounds like military jargon
airlied: spstarr_coding: hmm suspend to disk ftl, no reason it should act much different though.
airlied: except I probably don't need to post the BIOS.
spstarr_coding: airlied: the thinkpad needs a bios quirk
spstarr_coding: s3_bios
airlied: spstarr_coding: it doesn't any more.
airlied: with kms.
airlied: the problem is hal doesn't understand that.
spstarr_coding: hmm, well,it just hangs when i tried last time
spstarr_coding: blames agp
airlied: spstarr_coding: try pm-suspend --quirk-none
spstarr_coding: i can try again in future,for now im just staying in non-kms, the DDX changes you made keep my exa working right now
soreau: agd5f: Now how exactly do I need to perform the dumps to get the information you would need to make an attempt at getting 1024x768 tv-out? I have vbetest and radeondump (looks like the radeondump patch no longer need apply)
esthar: So I have a Radeon X1900 and I want to know if radeon or radeonhd will work better with my card. I would like to have video playback acceleration and OpenGL/3-D support. Can I use projectm visualiser and 3-D games like Nexuiz or QUake 3 better in radeon or radeonhd?
jcristau: esthar: they'll both use the same 3d driver
esthar: jcristau: So my card should work fine with radeon then...
esthar: and I'llg et 3D because it's R500?
jcristau: yes
esthar: What extra things should I put in my xorg.conf?
jcristau: none
esthar: jcristau: so compositing window managers will work without that setting in xorg.conf
MostAwesomeDude: esthar: I've got compiz running with no special settings in xorg.conf.
MostAwesomeDude: Just set your driver to "radeon".
esthar: ok
esthar: here I go.........
esthar: Okay so I am using radeon driver
esthar: but I have no direct rendering
esthar: so compositing is completely broken
esthar: direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
esthar: OpenGL renderer string: Mesa GLX Indirect
MostAwesomeDude: esthar: Odds are, you need to upgrade your Mesa.
MostAwesomeDude: Also, non-compiz compositing should work fine.
esthar: Well Kwin 4 is broken
esthar: I can't use KDE
MostAwesomeDude: KDE4 is perpetually broken. Anyway, upgrade your Mesa to 7.1 or better.
esthar: I have mesa 7.0.3
esthar: d'oh!
MostAwesomeDude: We didn't start supporting cards like yours until 7.1 :3
esthar: MostAwesomeDude: Would Mesa 7.1 fix Inderect Rendering in fglrx as well?
MostAwesomeDude: esthar: No. fglrx has its own DRI driver, and its own set of rules.
esthar: Okay so mesa is not in Debian sid
esthar: mesa 7.1 anyway
esthar: weird
MostAwesomeDude: Oh, you're not on Ubuntu?
MostAwesomeDude: scrolls up
esthar: Debian unstable, with experimental packages
MostAwesomeDude: Huh, go figure. Anyway, yeah. Grab it from experimental. Sorry 'bout that.
esthar: I see Mesa 7.2 is in experimental
esthar: Weird
esthar: okay
esthar: MostAwesomeDude: Do I just need to restarty X11?
esthar: Or whole computer?
jcristau: just X should be enough
MostAwesomeDude: ...I hope he's gotten the recent kernel update to 2.6.26...
MostAwesomeDude: esthar: Is it all workin'?
esthar: jcristau, MostAwesomeDude: Nope, still indrect
esthar: 2D works
esthar: 3D is broken and no compositing and indirect rendering says glxinfo
esthar: OpenGL renderer string: Mesa GLX Indirect
esthar: OpenGL version string: 1.4 (2.1 Mesa 7.0.4)
esthar: weird is says 7.0.4... why would it say that?
esthar: I upgraded the packages: libgl1-mesa-dri and libgl1-mesa-glx and libglu1-mesa and mesa-utils to 7.2
MostAwesomeDude: esthar: Looks like 7.2 isn't properly installed for some reason...could you run with "LIBGL_DEBUG=verbose glxinfo" and pastebin the output?
glisse: MostAwesomeDude, airlied: for occlusion query i would rather do it in userspace either alloc gart area or vram through texture buffer
esthar: MostAwesomeDude: http://pastebin.ca/1243583
glisse: as you can have an unknown number of pending query you might end with heavy infrastructure in kernel
glisse: it's way better to keep kernel knowledge to the minimun in my opinion
MostAwesomeDude: glisse: I have no idea how to do that; patches welcome? :3
glisse: MostAwesomeDude: doing it with bocs or bufmgr branch should be as easy as bo_alloc() then bo_validate
glisse: and put the addr in the stream
glisse: best it to alloc one page and to manage it from userspace to stack result in this page
jcristau: esthar: make sure glxinfo picks libGL.so.1 from /usr/lib/, and that comes from the libgl1-mesa-glx package, not fglrx or whatever
esthar: jcristau: How do I do that?
glisse: well it's really zzzZZZzzz time over here, once i find out why vbo are partly broken in my bo branch i can adapt your patch to use that and so avoid any kernel infrastructure
MostAwesomeDude: glisse: I've already got nearly all of the setparam and getparam stuff typed out.
esthar: I mean I have fglrx installed is that messing things up?
jcristau: yes, it is
MostAwesomeDude: esthar: Yep.
esthar: Ohh that sucks
esthar: I can't switch between them easily?
MostAwesomeDude: esthar: The Gentoo folk have developed some tools, but for the most part, no.
glisse: MostAwesomeDude: it's just that i am on crusade to keep complexe/rendering stuff outside of the kernel
esthar: I'm guessing I should restart X11 after uninstalling fglrx?
glisse: cu l8r
MostAwesomeDude: The fglrx kernel module does some weird stuff to the kernel, so if you've had it loaded, you'll need to blacklist it and then restart.
MostAwesomeDude: glisse: Later.
esthar: MostAwesomeDude: I have no kernel module for glrx loaded
MostAwesomeDude: esthar: Hm. Well, either way, you'll need to remove your fglrx packages and then reinstall Mesa.
esthar: oh damn reinstall mesa eh
esthar: ok
MostAwesomeDude: It's not as bad as it sounds. :3
esthar: brb
esthar: Hrrmmm
esthar: Error: couldn't find RGB GLX visual or fbconfig
esthar: That's what glxinfo tells me now
MostAwesomeDude: Arg.
MostAwesomeDude: You updated to kernel 2.6.26 yet?
esthar: no
esthar: I'm on 2.6.18
esthar: =P
MostAwesomeDude: 'k. Go do that update. It's been in testing for a while.
esthar: well
esthar: I can't get 2.6.26 working with dm-crypt
MostAwesomeDude: Hm.
MostAwesomeDude: Okay, your options:
MostAwesomeDude: - Kernel 2.6.26. Has DRM for r500 builtin.
esthar: Ohhh that sounds nice
MostAwesomeDude: - Go grab DRM and build it against 2.6.18. Might not work.
esthar: that doesn't
airlied: agd5f: pushed all the new kms bits to modesetting-gem
esthar: I have 2.6.26 installed but unfortunately it cannot read my root partition
MostAwesomeDude: The big reason we try to mainline this stuff is so that endusers (you!) can just grab a current kernel and have everything automagically work. :3
MostAwesomeDude: airlied: Have you slept at all? :3
MostAwesomeDude: esthar: Hm. That sounds like quite the problem. I have no idea how to solve it; I assume you've asked the Debian folk?
esthar: Sort of
esthar: Haven't strongly pursued it
esthar: One fellow seemed to not be hopeful
MostAwesomeDude: AFAIK nothing's been broken in the crypto side, since all my drives still work. OTOH I don't know your setup.
MostAwesomeDude: At any rate, that should be the only thing standing between you and direct rendering. Compiz might not work until you upgrade to Xserver 1.5, but YMMV.
agd5f: soreau: boot up with tv connected. use vbetool to set 1024x768, run radeondump or radeontool to dump the regs
soreau: Yes, you explained that part already
soreau: But I do not know exactly how to use vbetool
agd5f: soreau: I don't know if I remember :P
soreau: agd5f: I assume it's vbetoll blah blah and then radeondump -d r300
agd5f: yeah
soreau: But I can't find a good example of the gray blah blah part :/
agd5f: soreau: hold on I can find I think
soreau: and whether it is better to use vbetest or vbetool, I guess each is capable of performing the same task?
agd5f: IIRC either should work. I think vbetest
agd5f: vbetest -m 1024x768
soreau: And that should set all connected screens?
agd5f: yeah
soreau: Okay, maybe I can return with something useful
agd5f: if you run vbetest without any arguments it should list all the vbe modes
soreau: bbl
soreau: I just wanted to check first because I don't know exactly what it is you will need..
soreau: Hopefully this will work though
soreau: agd5f: Thanks
agd5f: soreau: you might want to use radeontool rather than radeondump
soreau: Oh?
agd5f: as radeondump seems to only dump regs up to 0x3c0 or so
agd5f: and a bunch of the tv regs are in the 0x8xx range
agd5f: http://cgit.freedesktop.org/~airlied/radeontool/
soreau: Ok, then I will use that.. vbetest and then radeontool
agd5f: yup
soreau: I'll login on to my other pc just in case
soreau: brb
soreau: agd5f: This is the results from starting X regularly, then stopping gdm, running vbetest -m 1024x768 and then radeontool --debug regs http://pastebin.com/m2f19efb6
soreau: Both screens went black on the vbetest command, not sure if that matters, and if I cold booted without starting X and just loading the radeon module, vbetest would fail with 'this program needs to be run from a console' or so
rmh3093: airlied, ping
airlied: rmh3093: pong
rmh3093: the im using the ati driver from your git repo
rmh3093: and it has shit terrible memory leak
rmh3093: and i see here: http://koji.fedoraproject.org/koji/buildinfo?buildID=68224
rmh3093: that mem leak was fixed recently
rmh3093: and i was wonder what the patch was that fixes it
airlied: rmh3093: I just pushed the updated tree
rmh3093: lol
rmh3093: figures
rmh3093: thanks
airlied: rmh3093: I hadn't turned the laptop on over the weekend to push it :)
rmh3093: airlied, which repo did u push to, git://people.freedesktop.org/~airlied/xf86-video-ati, or the main repo
airlied: rmh3093: that one in the radeon-gem-cs branch
MostAwesomeDude: Dang, I fail.
rmh3093: airlied, when i pull from that, the last commit is oct 27
rmh3093: c0660495080719c052d6393ede707755929102cd
airlied: rmh3093: http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=radeon-gem-cs
soreau: MostAwesomeDude: Randomly, or always?
soreau: :)
MostAwesomeDude: soreau: Right now, I think it's due to being completely new to this particular adventure.
MostAwesomeDude: airlied: My test runs keep getting sniped out of existence due to SEGV on ioctl.
soreau: A new roller coaster, yay!
MostAwesomeDude: I'm pretty sure I'm doing everything right, though.
airlied: MostAwesomeDude: nice... sounds like the copy back to userspace is failing.
airlied: throw the drm patch somewhere and mesa one.
MostAwesomeDude: airlied: Hm. That's *really* bad, because it's dying on a SETPARAM. :3
airlied: also see if drm debugging helps.
MostAwesomeDude: DRM fail: http://pastebin.ca/1243664
MostAwesomeDude: Mesa fail: http://pastebin.ca/1243666
MostAwesomeDude: Gonna reload DRM and turn on debugging, BRB.
MostAwesomeDude: XD, found it. Oops.
agd5f: soreau: preferably run without X active and you want radeontool regmatch '*'
MostAwesomeDude: airlied: I'm not completely sure how to parse BUG, but I think it's improper RING*?
soreau: agd5f: I suspect X loaded some module I'm not aware of.. but for radeontool, well I guess I did it wrong
agd5f: well, doing vbe when X is running doesn't always work well
soreau: Ok, I will do it again
MostAwesomeDude: airlied: Boatload of fail. http://pastebin.ca/1243668
MostAwesomeDude: I have exactly zero idea what it all means, except I think it's a null pointer dereference. :c
agd5f: MostAwesomeDude: got patches?
MostAwesomeDude: agd5f: Scroll up, or http://pastebin.ca/1243664 and http://pastebin.ca/1243666.
agd5f: ah ok
MostAwesomeDude: I'm confident in the actual writing to the card, but really, I am *not* a kernel person (yet.)
soreau: agd5f: Doing radeontool regmatch '*' just displays --help
agd5f: soreau: did you download radeontool from airlied's repo?
agd5f: the one most distros ship is useless
soreau: No I did not
soreau: Ok, where is this?
agd5f: http://cgit.freedesktop.org/~airlied/radeontool/
agd5f: git clone git://people.freedesktop.org/~airlied/radeontool/
soreau: Ok, will do
MostAwesomeDude: Hmm. Staring at bad code makes me crave food.
agd5f: MAD|munchies: I'm getting hungry myself
spstarr_coding: stuck looking at C++ code
spstarr_coding: in KDE world
soreau: agd5f: Before http://rafb.net/p/i8nZKv95.html and after running vbetest -m 1024x768 http://rafb.net/p/0km6tQ35.html
soreau: Looks a lot more useful than the other output I gave :P
soreau: agd5f: I still had to load X and then kill it, and the screens still went black when running vbetest, but I made sure X was not running with 'ps ax|grep -i x' (I'm hioping that was enough)
soreau: (hoping)
airlied: MAD|munchies: you can't write to that ptr there.
agd5f: soreau: I'll take a look. it'd be better if you could confirm that the tv-out was working. Why did you have to load X?
airlied: the value returned is a GPU address not a CPU one.
soreau: agd5f: Like I said, if I just boot without X into root, load radeon and then try vbetest, it says needs to be run from a console
airlied: MAD|munchies: have a look at dev_priv->scratch assignment
agd5f: soreau: you don't have to load radeon
airlied: for how to get the CPU address.
soreau: o rly?
agd5f: yup
agd5f: vbe runs code in the bios
agd5f: nothing to do with drivers
soreau: I think I tried without loading radeon, but can't remember now :p
MostAwesomeDude: airlied: Okay. I'll try that. Thanks.
soreau: agd5f: Ok, guess I'll try again then. The values I see for TV stuff look interesting though, the same ones I was hacking on
soreau: (in radeon_tv.c)
agd5f: soreau: yeah, they might be ok
soreau: But AFAICT, a lot of the tv code values are hard coded
soreau: So I probably would be able to get it working how I want, but maybe not for switching tv res modes
agd5f: soreau: once you find a working set of registers we can work backwards to sort out the rest
soreau: That was my thought pretty much
soreau: agd5f: Thanks for all your help so far, as always
agd5f: soreau: no problem. thanks for tackling this
soreau: yuppers ;)
MostAwesomeDude: airlied: Okay. So. Basically it just spins a whole bunch. Doesn't actually read anything.
MostAwesomeDude: I'd be okay with an IRQ. Dunno how to do it, though.
airlied: MostAwesomeDude: so is the OQ bits working?
airlied: throw up your latest drm patch
MostAwesomeDude: airlied: Well, the second ioctl, the getparam, keeps returning 0xFFFFFFFF, so that works, yes. :3
MostAwesomeDude: But the value doesn't change. :c
MostAwesomeDude: http://pastebin.ca/1243767
spstarr_coding: airlied: about the only thing thats bugging with EXA + DDX and no kms, is flash videos are corrupt
MostAwesomeDude: My guess is that in my sleep-deprived state, I messed up some pointer math... :c
spstarr_coding: airlied: http://www.sh0n.net/spstarr/corruption.png
spstarr_coding: you can see the gory corruption ;/
spstarr_coding: some clipping?
airlied: MostAwesomeDude: you seem to have some pointer size mixups.
airlied: you add values to a u32 * and to a void *
airlied: which would end up in different places.
MostAwesomeDude: airlied: I'm not surprised. Lemme bash my head against the wall a bit more. Those should all be u32?
MostAwesomeDude: No, wait, they are already u32?
airlied: you are doing pointer additions on top of the handle
MostAwesomeDude: Right. Are those wrong?
airlied: handle is a void *
airlied: adding 0x30 + offset to a void * isn't the same as adding it to a u32 *
MostAwesomeDude: checks header
MostAwesomeDude: Ag.
MostAwesomeDude: bashes head against wall
MostAwesomeDude: Righty. My pointer-fu is weak. BRB.
MostAwesomeDude: Arg. I'm sucking too much.
MostAwesomeDude: Gonna go nap a bit, I think.
spstarr_coding: notices X eating 50% cpu all of a sudden
spstarr_coding: brb
tlp: It's too bad you can't virtualize driver development to prevent a thousand reboots.
soreau: Fail. I can get output with color at 1024x768 to tv, but ultimately I'm groping in the dark with the values in radeon_tv.c
soreau: The changes I make definitely affect the outcome, and I can see enough to know it's 1024x768, but the h v timings are way off