vehemens: ping agd5f
agd5f: vehemens: pong
vehemens: you see my bits about the render index issues?
agd5f: vehemens: no
vehemens: couldn't get engine to run on my system due to incorrectly formatted message. tweaking the index values got it to run.
vehemens: also radeon_screen.c was using the wrong scratch offset, but i don't believe that path is used any longer.
agd5f: vehemens: yeahs, I fixed the scratch offset before I merged to master, it must have gotten broken when I merged it
agd5f: but, yeah, it's not used currently anyway
vehemens: agd5f: to get rid of the engine "[drm:pid1489:r600_cs_packet3] *ERROR* bad DRAW_INDEX_IMMD" problem, i modified r700RunRender to use "numIndices = vb->Primitive[i].count + 1" and "lastIndex += numIndices - 1".
vehemens: that may be the wrong solution, but that's the best i have so far.
agd5f: vehemens: ok. I'll take a look tomorrow
vehemens: took a stab at textures, but didn't get anywhere other then realizing how much code was involved.
agd5f: vehemens: what application?
vehemens: mesa progs demos engine
vehemens: my machine is setup for 64 bit. hopefully that's not a issue.
agd5f: vehemens: doesn't matter
Zayec3: so do we have basic textures working now?
vehemens: the few demos i've run with the fix appear to almost fully functional
boghog: ooh textures are working r[67]xx?
vehemens: his fix was really simple. wonder how many hours it took to find.
airlied: hehe.. its one of those inverse laws
_moep_: hi airlied
boghog: sweet, where is this fix? :p
vehemens: mesa master
boghog: ah I see now
nanonyme: airlied: Then again, if we'd replace the word simple with elegant, the law would suddenly start making perfect sense. :3
nanonyme: Faster to find a hacky workaround than the elegant solution, usually.
_moep_: airlied: whats with this bug: http://bugs.freedesktop.org/show_bug.cgi?id=22562
boghog: hmm, texture color doesn't look right for me
boghog: but other than that it works, yay!
boghog: http://dump.aphax.nl/images/r7xx-tex1.png vs http://dump.aphax.nl/images/nvidia-tex1.png
boghog: i guess i should get a better texture for testing
nanonyme: boghog: Which test was that?
boghog: ah just a toy opengl program of mine
nanonyme: Well, there's maybe five or six texture demos in Mesa.
boghog: ill try one of those
nanonyme: At least.
boghog: hm, demos/projtex doesn't look quite right to me, I think (not sure what it's supposed to look like ><)
boghog: ill take some screenshots
nanonyme: Seems there's still corruption in geartrain too.
virtuald: do you radeon developers use the oops reports submitted by the kerneloops daemon?
mcgreg: nanonyme: any estimation when the drm stuff (r6xx/r7xx) will be availbale for .30 or even .31 kernels?
nanonyme: mcgreg: You mean ported? Patches have been available for a month or so. I don't consider them getting to the tree that essential since r6xx-r7xx-3d is planned for merge to 2.6.32 anyway.
nanonyme: Erm, I mean, not ported, compatted. :)
mcgreg: hmm okay
boghog: hrm, with glsync test my machine slows down and I get a lot of: [ 3657.301262] [drm] wait idle failed status : 0xA0003028 0x00000002
mcgreg: tgx you nanonyme
mcgreg: thx
boghog: anyway it seems most of the texture tests look okay actually, except for a few, not sure why it doesn't look right in my own app
nanonyme: mcgreg: I've been running most of my testing on r6xx/r7xx OpenGL on 2.6.30.1 anyway. :)
mcgreg: so it will probabkly take at least another 2 month till 2.6.32 though
mcgreg: meh
mcgreg: how?
nanonyme: http://kapsi.fi/nanonyme/public/ as I said, patches do exist
mcgreg: ok, you know. I'm a noob. get the drm 6xx/r77 branch and apply the patch?
nanonyme: Yups.
nanonyme: git apply foo.patch # should work.
mcgreg: do I have to apply only r6xx-r7xx-3d-2.6.30.1-compat.patch ? to make it work for .30 ?
nanonyme: Yes.
nanonyme: Those are incremental though so you need both for the newer.
mcgreg: ok
nanonyme: mcgreg: Two months sounds kind of a long time to go from 2.6.31-rc4 to 2.6.32-rc1.
mcgreg: why? 2 weeks between every rc. rc4-rc5 (2w) rc5-rc6 (4w) rc6-rc7 (6w) and 31-rc7-->32-rc1 (8w) ...
mcgreg: I calculate it like that
nanonyme: I guess that's still worst-case though.
mcgreg: there might be a rc8 too ;)
mcgreg: cool, it compiled
nanonyme: There also might be an immediate release after this one. Depends on how many critical isues the kernel still has.
mcgreg: ok, compile drm.ko and radeon.ko ... and now kopied them to the corect locatation in the kernel modules
mcgreg: will reboot the machine and see
suokko: mcgreg: Quite many clones ;) (yes. I know it is netsplit)
nanonyme: mcgreg: Why bother booting?
nanonyme: Oh, you don't hav 2.6.30 running atm?
nanonyme: s/hav/have/
mcgreg: nanonyme: because I could go away and do nothing.
mcgreg: I did
mcgreg: oh stupid me I forgot I need mesa too
boghog: thinks it's time to find a different freenode server
boghog: damn netsplits :/
mcgreg: the drm doesnt work here
nanonyme: Be a little more specific?
mcgreg: [ 28.945475] drm: Unknown symbol init_mm
mcgreg: sry needed a few second to copy paste ;)
chithead: unknown symbol usually means that the module does not match your kernel
nanonyme: Is this stock Linus tree?
nanonyme: Since I only know the patch works when building against and using a stock 2.6.30. No idea about distro versions.
mcgreg: no debiane one
nanonyme: You might want to check though that you don't have an initrd loading the wrong drm.ko.
nanonyme: mcgreg: Are you sure you compiled it against the right kernel sources?
mcgreg: well, I'll check something maxbe I did something wrong
mcgreg: I didnt set --prefix=/usr
nanonyme: configure params are irrelavant for DRM kernel modules.
mcgreg: I'll paste a few lines
mcgreg: schleppi:/home/mcgreg/git/drm/linux-core# make
mcgreg: make -C /lib/modules/2.6.30-1-686/source O=/lib/modules/2.6.30-1-686/build SUBDIRS=`/bin/pwd` DRMSRCDIR=`/bin/pwd` modules
mcgreg: make[1]: Entering directory `/usr/src/linux-headers-2.6.30-1-common'
mcgreg: Building modules, stage 2.
mcgreg: MODPOST 13 modules
mcgreg: WARNING: "init_mm" [/home/mcgreg/git/drm/linux-core/drm.ko] undefined!
nanonyme: Btw, that looks overly excessive wyay to define the stuff.
nanonyme: make LINUXDIR=/lib/modules/2.6.30-1-686/source drm.o radeon.o # should do
nanonyme: Also remember to run make clean before that.
nanonyme: Just to be sure.
mcgreg: wobn't work liek that, I get an error when I do it like thas
nanonyme: What kind of an error?
nanonyme: That's the recommended way to do it.
mcgreg: hmm I alwaqys did it the "make" way .. but I can show you the error
nanonyme: The make way pulls the source tree of the currently running kernel.
mcgreg: http://pastebin.com/m4d1a6761
suokko: mcgreg: Have you tried to use module-assistant? I think that is recommended for debian
mcgreg: suokko: no, never used it before
nanonyme: Well, true, I wouldn't know what's recommended by distro. That's teh way the Makefile advices you to do it though.
mcgreg: make drm.ko radeon.ko is fine though but I strill get WARNING: "init_mm" [/home/mcgreg/git/drm/linux-core/drm.ko] undefined
nanonyme: Are you running 2.6.30 while doing the compiling?
mcgreg: yes
mcgreg: schleppi:/home/mcgreg/git/drm/linux-core# uname -a
mcgreg: Linux schleppi 2.6.30-1-686 #1 SMP Sat Jul 18 14:00:34 UTC 2009 i686 GNU/Linux
nanonyme: Then I'd assume Debian's 2.6.30 is borked.
nanonyme: Either kernel itself, the headers or the sources. Dunno which.
mcgreg: dunno, but I dont have the kernel, just the headers
nanonyme: I would (and do) use upstream kernels for that kind of testing.
mcgreg: sry whats an upstream kernel?
nanonyme: Download the official 2.6.30.1 release from kernel.org. ;)
nanonyme: No distro patches on top.
mcgreg: hmm no thx. I'll rather wait then :)
mcgreg: or bug the debian kernel devs ;)
mcgreg: on my main machien I am using -31-rc3 anyway
mcgreg: it's just my laptop I am playing
mcgreg: +with
mcgreg: would the patches work with rc3 too?
nanonyme: They might.
nanonyme: My kernel markings are not there to show requirements, they mostly mean which kernel I had when I made the patches.
boghog: ok
boghog: looks like textures only look wrong for me if I load them with GL_RGBA as internalformat, GL_RGB works fine
nanonyme: Hmm, as in alpha might be broken?
boghog: yeah
boghog: i need a better test image to figure out how exactly though
boghog: fires up GIMP
nanonyme: boghog: You could also try some alpha tests in Mesa to see if you manage to get the same issue.
nanonyme: (or any issues, whatever)
g-zu: hi, when I run qt4/examples/opengl/textures/textures with the latest mesa (from git) I get this *** glibc detected *** /usr/share/qt4/examples/opengl/textures/textures: double free or corruption (!prev): 0x00007f8ac5902210 ***
boghog: the only test where textures didnt look quite right to me was the projtex one, seems it also uses GL_RGBA as internal format so makes sense
nanonyme: boghog: I meant strictly alpha demos.
boghog: not sure what you mean
nanonyme: Some demos that have alpha in their name instead of eg tex? :3
nanonyme: To find out if the demo fails in alpha altogether or if it's just a texture-related thing.
nanonyme: s/demo/driver/
boghog: well, there's no problems with redbook/alpha, but the problem is really with the texture since I don't actually do anything with the alpha channel (no blending)
boghog: just as soon as I make the internal format RGBA the colors come out wrong
boghog: i think maybe it interprets RGBA as ARGB
boghog: or hmm
boghog: brain explodes
mcgreg: picks all piecxe and puzzles then back again into one brain and puts it back into boghogs head
mcgreg: ;)
mcgreg: --typos
boghog: thanks :D
boghog: it does seem like alpha is being interpreted as red at least
boghog: using http://dump.aphax.nl/images/rgbatest.png : http://dump.aphax.nl/images/nvidia-rgbatest.png vs http://dump.aphax.nl/images/r7xx-rgbatext.png
suokko: g-zu: Can you compile with debug symbols and use valgrind?
suokko: boghog: Looks CMYK colors
g-zu: suokko: I guess I could, can I only compile the app with debug symbols or do I have to recompile mesa and xf86-video-ati too?
g-zu: maybe also libdrm ?
suokko: g-zu: Which distro are you using?
g-zu: gentoo
suokko: Then you need to compile mesa with debug symbols
g-zu: release with debug symbols would do?
suokko: and maybe libdrm if valgrind reports problem in libdrm code (which is not very likely)
suokko: g-zu: yes
g-zu: cause I put -ggdb in my compiler flags
g-zu: ok
boghog: you may need to put FEATURES="-nostrip" in /etc/make.conf, I think portage strips symbols by default
boghog: or FEATURES="splitdebug", then it puts the symbols under /usr/lib/debug
g-zu: I have features=splitdebug already
boghog: ah ok
suokko: boghog: Or RRMY colors :)
boghog: :p
suokko: So maybe some color space conversion error?
g-zu: oh man, this is so verbose
suokko: valgrind is often very verbose even with small memory access errors
boghog: I think it just interpetes RGBA as ARGB, but im not good with mixing colors in my head so ill have to write it downto confirm
g-zu: how can I make it output to a file?, redirection doesn't seem to work
g-zu: ah found it
suokko: 2> filename
boghog: valgrind with new glibc has some issue where it spits out thousands of 'uninitialized value' errors
boghog: was only recently fixed on gentoo
boghog: on amd64 that is
suokko: That should be relative easy to fix with suppression
g-zu: ha, got it
suokko: I got some free error at exit with gears: http://paste.debian.net/42744/
g-zu: here, let me know if you need me to run it with more options http://pastebin.com/d540c6432
suokko: g-zu: Does the double free error happen when you try to close the application?
g-zu: yes
g-zu: suokko: do you think this is a bug in the application?
nanonyme: bog: Hmm, if alpha is interpreted as red, are any other channels mixed/swapped as well?
suokko: I don't know. It could be caused if application tried to free same context twice but it would be unlikely
g-zu: yeah, it's a demo in qt, I would think it was checked pretty well
g-zu: suokko: also the background doesn't always get painted, but I guess that's using something unimplemented for r700 yet
g-zu: I just tried the demo because I saw all the recent texture patches that went in
g-zu: there are 6 view ports in the demo, the first 2 work ok, the last 4 result in this error
boghog: nanonyme, yeah other channels are swapped as well, from my test image i gathered: http://pastebin.com/m55a865b5
nanonyme: Maybe it's an order issue then?
boghog: well yeah
g-zu: suokko: I looked at the code, and all contexts are treates the same, only the clearcolor is different, very interesting how the first 2 don't trigger errors
nanonyme: As in, if r and a are swapped, g and b are swapped, it's likely exactly the wrong way around. :3 (as in, agbr)
suokko: g-zu: http://paste.debian.net/42747/ might be able to work around the double free
boghog: yeah, it just swaps them
g-zu: you want me to try it?
suokko: I don't know code enough to find the real problem
suokko: yes, please
g-zu: it will take a few minutes for me to hack the ebuild...
suokko: agd5f: Are you around? There is some double free problem in r600 mesa code
nanonyme: My summary was borked.
nanonyme: boghog: Might not be a swapping issue at all but some misunderstanding of standard/save format.
nanonyme: I'd rather consider it a likely swapping case if just two channels were swapped. If all are symmetrically swapped, it's a bit more dubious.
boghog: i don't really follow what you're saying, but yeah seems like it's just an endianess swap too many, or too few, when transforming it to the internal format
boghog: there's no problems with GL_RGB as internal format at least
MrCooper: unless you're on a big endian CPU, there should be no endianness swaps... maybe just a format mismatch?
boghog: hmm, wouldn't there be issues when using GL_RGB as internal format as well in that case though?
suokko: What kind of system would include powerpc 4xx? Does anyone have that kind of system?
mjg59: suokko: Embedded hardware, mostly
suokko: I was jsut wondering if unitptr_t would be 64bit in such a system
mjg59: Doubt it, they're PPC32
suokko: But hardware pointers are 64bit and uintptr_t is defined to match pointer size
MrCooper: define 'hardware pointers'
MrCooper: uintptr_t matches the userland pointer size
MrCooper: which can only be 64 bit on a 64 bit kernel
suokko: MrCooper: I just read the commit message from video-ati that changed a few varaibles to long long so there would be enough space to hold hardware pointers
MrCooper: that's not related to uintptr_t
suokko: I just tough if uintptr_t could be used instead of long long
MrCooper: no
MrCooper: the hardware address size is independent from the userland pointer size
suokko: But then here would be problems when long long variable is cast to void pointer, wouldn't there?
suokko: like truncating upper 32 bits of address
jcristau: then you don't do that
suokko: except that ddx driver code does that
MrCooper: where?
boghog: btw, I have a different issue where if I try to draw a VBO (non-indexed) above a certain size, X and my app both freeze until I kill my app, if run it from gdb and interrupt it when it freezes I get: http://pastebin.com/m462c9b3f
suokko: MrCooper: grep LinearAddr *
boghog: oh and on dmesg: [ 9517.018722] [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock
boghog: [ 9742.520602] [drm:r600_nomm_relocate] *ERROR* bad offset! 0x2
nanonyme: would put a wild guess that historically the upper 32bits wouldn't have been used in that context
nanonyme: (usually the easy explanation when things work even when you do stupid stuff)
suokko: But then again that could cause some bugs in case of powerpc 4xx with more than 4G memory (or any other mixed system)
nanonyme: Depends.
nanonyme: If the context is such that the pointer can never point to any memory location above the lower 32bit area, it's safe.
g-zu: brb
nanonyme: (that's a big if)
MrCooper: I think it could, but I think the problem is with some parts of the X server assuming that the size of a physical address equals the size of a pointer
MrCooper: anyway off for lunch, bbl
boghog: ah and just before my app freezes on stdout: Invalid source texcoord for TEX instructions (a bunch of times)
suokko: nanonyme: So it is unlikely to be triggering problems but there is small possibility for it
suokko: and because there is commit talking about it there has been some problems already
g-zu: suokko: the patch works
g-zu: although I had quite a trouble getting portage to accept it
g-zu: I hate live ebuilds
nanonyme: suokko: Doesn't sounds very efficient btw that r600DestroyContext would end up being called twice.
suokko: nanonyme: It sounds like bug somewhere
suokko: But I can't understand where. valgrind backtrace is exactly same for first and second free call ...
suokko: So maybe there is some copy construction in c++
suokko: Which causes 2 objects with same opengl context
nanonyme: Maybe...
g-zu: but 2/6 working is a really strange situation
nanonyme: Have you been able to find the equal code for r300 Mesa driver?
suokko: nanonyme: There is none
nanonyme: Hmm.
suokko: r600 has been done differently
nanonyme: Oh, for God's sake. :(
nanonyme: So it could even be an design bug.
suokko: radeon_common_context.c:285
nanonyme: s/an/a/
nanonyme: Ah, right.
suokko: Evil source browser
suokko: It has too complex js so has to cancel execution
nanonyme: So the "equal" stuff for earlier chips seems to be done in radeon_destroy_atom_list
nanonyme: Since that's the part that gets executed in that function call if you don't have r600 or higher.
suokko: yes. But I think that function shouldn't be called twice but in case of 2nd call it should be protected
nanonyme: didn't actually even know C had a foreach
suokko: It doesn't but it can be done using macros ;)
nanonyme: Sure, I'm just less excited about that answer because it might mean it wouldn't be documented.
nanonyme: (And I'd prefer to actually know what the piece of code exactly does. You can implement foreach in at least two contradictory ways)
suokko: There is foreach and foreach_s in dri code
suokko: and that foreach seems to operate only over linked list
nanonyme: Well, yeah.
suokko: g-zu: I think that there is no easy solution for double free. Can you write a bug report to https://bugs.freedesktop.org ?
nanonyme: suokko: Btw, does valgrind work properly even without -O0?
nanonyme: Just wondering since iirc gdb doesn't. (gcc optimizes stuff away unless you disable all optimization)
suokko: nanonyme: yes. But debug symbols are as good as with gdb so backtrace can be hard to read
nanonyme: suokko: Well, iirc even with -O1 parameters are usually optimized away so you don't see them with gdb. :/
suokko: You can use gdb with optimized build but it just requires a bit more time and better understanding of code
g-zu: I'll try, I don't think I have an account though
nanonyme: With -O0 you see exactly what's happening with the stack call. :)
nanonyme: s/ call//
suokko: But with -O2 you can move in frame and read the variables that you have to know if parameters are optimized
g-zu: man, somebody should update that bugzilla it still says CVS instead of git
suokko: And r600 is missing for components
g-zu: I saw that too, I assigned to radeon
g-zu: should I attach that valgrind log?
suokko: sure
suokko: Also info where to get the demo would help debugging
nanonyme: It's not like developers ever complained of getting too much information as long as it's organized so that they can find individual logs easily...
suokko: That is true. One comment/attachment per log is good idea :)
scarabeus: anyone considered releasing 6.12.3? its been 4 months and the patches count is quite large...
scarabeus: just asking i backport the patches anyway
glisse: .win 1
g-zu: suokko: you sure I should tell where to get the demo? qt source is a pretty big download, I could just attach the demo program, is composed of very few files
suokko: g-zu: sure if you can find all the required files easily
g-zu: done https://bugs.freedesktop.org/show_bug.cgi?id=22964
g-zu: the sources are smaller than the log file :D
g-zu: suokko: btw glxinfo reports OpenGL renderer string: Mesa DRI R600 (unknown 9490) 20090101 TCL - could someone add the chipid somewhere? - it is reported as ATI Technologies Inc RV730XT [Radeon HD 4670] rev 0
suokko: g-zu: That pci id is part of mesa and xf86-video-ati source from master
g-zu: xf86-video-ati reports it ok
g-zu: only mesa/glxinfo says unknown
suokko: yes. get_chip_family_name in mesa is missing all r600+ ids
nanonyme: That shouldn't be a hard fix, should it?
g-zu: I believe it should be trivial
g-zu: but you should really find a way to keep all this stuff in a more "unified" mode. I believe they are kept in libdrm mesa and xf86-video-ati and xf86-video-radeonhd separately... that's a lot of duplication
suokko: But unification is hard job
nanonyme: g-zu: In time radeon won't be using the hardware directly anyway so nto that much of an issue.
nanonyme: suokko: Not exactly, it's already being done.
suokko: anyway. I will create a patch to fix the chip detection for glxinfo
nanonyme: It's called KMS + kernel memory manager.
suokko: nanonyme: But it takes time :)
nanonyme: After that kms-compatible ddx's don't have to know that kind of information.
g-zu: kms doesn't work yet for my card
nanonyme: I said "being done", not "ready". :p
g-zu: for r300 and some select r600 it seams ready :p, anyway thanks for the great work guys, keep it up
nanonyme: Though hmm.
nanonyme: Probably would also want to have get_chip_family_name be a libdrm API function in KMS land.
nanonyme: doesn't know if it is, will have to look
nanonyme: Doesn't seem to be. Not good. :/
JamesLast: hi
JamesLast: has anyone of the devs time to look at http://bugs.freedesktop.org/show_bug.cgi?id=19459 ?
nanonyme: airlied: Poke, is there any compelling reason not to have get_chip_family_name in Mesa ask the information from KMS over libdrm?
JamesLast: same bug in kms case : http://bugzilla.kernel.org/show_bug.cgi?id=13683
kdekorte: whoa.... etracer almost works... the setup screens (while a mess, does display)
g-zu: sorry to disturb the silence again but wouldn't this be faster for get_chip_family_name than a switch? http://pastebin.com/m6f367eb7
suokko: g-zu: Intresting queston is what does compiler generate fro switch :)
g-zu: I compiled with switch and resulted in a 17k .o file, this resulted in a 15k one
g-zu: should optimize it but doesn't
g-zu: although this is not really a very called function so it shouldn't matter anyway
g-zu: please try it too, I'm using gcc-4.3.3 maybe it's something wrong with this version
jstut: I am using a two different ati cards (a power color,and all in wonder 9600). under fc7,9, and 10: I used the 9600 cards with fglrx, since moving on to fc11 I am no longer able to use fglrx. what driver should I use? if I use Xorg default vesa I cannot use two monitors with a stretched desktop. who do I make a request too, to fix the problem. xrandr does not report two ports on the card, lspci does. Is there an ati driver avail
g-zu: you're on the channel for the ati driver
g-zu: the driver is called xf86-video-ati
g-zu: jstut: you should also get working 3D support with that card
jstut: in my xorg file how should I refer to this driver and should xrandr be reporting that I have two ports avaiable
g-zu: jstut: put ati or radeon instead of vesa in your Xorg.conf file
kdekorte: jstut, to get dual head on that card, you just need to make a simple change to the xorg.conf file
g-zu: jstut: if the xorg server has hal support you probably can just remove the Xorg.conf completely (better keep a backup though)
kdekorte: Add 'Virtual 4096 4096' under 'SubSection "Display"'
kdekorte: No he will need the xorg.conf for dual head to work right
jstut: I tried about four variations on getting multiple screens to work all have failed can you recommend a site with great examples with the new driver.
kdekorte: jstut, here is a sample xorg.conf http://pastebin.com/m4b24d27d
kdekorte: you'll just need to change the connector names in that file.. connector names can be found with xrandr
g-zu: jstut: follow kdekorte's advice, but modify vesa to ati in xorg.conf too
kdekorte: That is the same xorg.conf that I use on my r6xx card, but it should work on any radeon
kdekorte: I have two displays
jstut: I'll follow up with your samples and get back if I have problems THANKS!
kdekorte: jstut, oh and make sure that fglrx is completely off the machine... including the kernel driver
jstut: THIS IS f11 there is no fglrx on it.
kdekorte: excellent...
suokko: g-zu: seems like default entry makes gcc to emit slow code
kdekorte: some people try to force it in and then it makes a big mess
g-zu: suokko: so it happens to you too?
g-zu: maybe we should bug-report it to gcc
suokko: yes. And I did read that if default entry would be flagged as unreachable gcc would emit faster&smaller code
kdekorte: suokko, hard to believe that there would be a switch block without a default somewhere, but I guess it is possible
suokko: gcc people would tell you not-a-bug :)
suokko: kdekorte: switch without default is standard way to write fast code and should be prefered way of using switch
g-zu: in that case my "lookup table" is faster :P
kdekorte: but for completeness, I almost always use "default"
g-zu: but switch with default can be optimized too, especially if all the non-default stuff consists of consecutive values
g-zu: kdekorte: that means you write slow code :-P
suokko: yes. It could be but writing that optimization is hard :)
kdekorte: g-zu, probably...
g-zu: you can still optimize it though
g-zu: just put an if in front of the switch, remove the default and put default in else
g-zu: or even better
g-zu: if( chip_family < 0 || chip_family > CHIP_FAMILY_RV740 )
g-zu: return "unknown";
g-zu: and than the switch without default
suokko: default: gcc_unreachable();
suokko: And other non-standard ways to explicitly tell compilers that all switch values are handled :)
suokko: But in case of enum compiler would know it
g-zu: suokko: but you might have problems if you do that the next time you get something "unknown"
suokko: That why there is compiler warnings :)
g-zu: with the if before it should also know
g-zu: not everybody pays attention to warnings, hell, compiling the kernel spits out quite a lot of them
suokko: That why I would like to see -Werror in compiler parameters
g-zu: you want it as default?
nanonyme: suokko: There's also an explicit "turn -Werror off on PPC" switch in kernel config because people tend to break PPC from compiling without warnings while doing something on the x86 side if they're not careful...
g-zu: suokko: stupid me, you don't even need the switch
g-zu: I meant if, just move the default out of the switch
g-zu: put return "unknown" after the switch and it's all ok :D
nanonyme: g-zu: Leave optimization for the compiler, pretty please. ;)
g-zu: nanonyme: the problem is the compiler doesn't do the optimization
nanonyme: Have you tried?
g-zu: absolutely
nanonyme: Asembly instructions with -O0 vs -O2.
nanonyme: Assembly even.
g-zu: I tried with -O2
nanonyme: And then also generated Assembly instructions with your stuff.
g-zu: and I made an array instead of the switch and the compiled binary was 2k less (without any debugging symbols)
g-zu: suokko observed that it says somewhere that gcc can only optimize switches without a default value
nanonyme: Actually computer science wise, length of switch would be pretty much irrelevant, I think...
suokko: nanonyme: I looked to gcc output with objdump and it was using binary search instead of faster branch lookup
g-zu: that's why I suggested to move the default out of the switch, the function returns anyways just after
nanonyme: Since the speed would be at worst a sequence of if clauses which would equal O(1) + (1) + O(1) + ... O(1) = O(1).
nanonyme: + after the ...
otaylor: nanonyme: I remember someone once arguing that linear array scans were O(1) since an array could never be biggre than the size of the computer's memory
nanonyme: otaylor: This is a bit different. We can't have an infinite amount of if clauses.
otaylor: nanonyme: how is it different?
nanonyme: But we can have an array with size N.
suokko: nanonyme: O(1) + O(1) +... = O(n) ;)
suokko: But compiler generates binary search so outputed code is O(lg n)
otaylor: nanonyme: implemneting a switch with a series of if statemnets, is O(n) where n is the number of branches in the switch
nanonyme: N*O(1) = O(1)
nanonyme: Not O(N).
otaylor: nanonyme:
nanonyme: (iirc)
suokko: nanonyme: You are trying to think wrong way of this problem
nanonyme: otaylor: Ah, true.
suokko: runtime is relative to number of chip families
nanonyme: Which is small. :p
MrCooper: now, if you guys spent this much energy on optimizing something that's actually in a hot path... ;)
suokko: for naive compare against all possible values would be O(n), compiler generated binary search is O(lg n) while branch look up table would be O(1)
nanonyme: The argument that you could use N there implies amount of generations would be *big*.
nanonyme: MrCooper: I'm mostly arguing this is premature optimization.
suokko: This is just question why gcc generates bad code for switch statment ;)
suokko: nanonyme: I agree :)
nanonyme: :D
nanonyme: Right, carry on then. ;)
suokko: I already searched the answer to my question why gcc didn't optimize that with table lookup instead of binary searches. ;)
g-zu: MrCooper: true, but I'm not that experienced yet, I'll try to have a look at the whole mesa code and see if anything important can be optimized, maybe in the process, I'll even start to understand how stuff works in there
g-zu: suokko: are you going to share that info? or better the workaround
suokko: g-zu: There is some mailing list conversations about the fact and what I understood from comments gcc is very pessimistic at optimizing switch
nanonyme: suokko: So... Solution is to write it open?
nanonyme: As in, as a sequence of if clauses.
nha: the solution is not to care about functions that are called at most once
suokko: GCC has to be explicitly told a lot to make it optimize
suokko: nha: sure :)
nha: g-zu: get yourself a profiler and look at which functions are actually relevant for optimization
suokko: nanonyme: Solution is to use icc ;)
g-zu: nha I will
nanonyme: suokko: Hrm.
suokko: (If you happen to have cpu that is supported)
g-zu: suokko: or better yet write assembly :)
g-zu: just kidding, don't kill me
g-zu: I know mesa is supposed to run on many platforms, so asm is not an option
nanonyme: g-zu: Sure it is.
nanonyme: There's inline Assembly used in some sections.
suokko: In hot path asm is option but maintance of asm code is way too hard compared to C code so not many places are worth of using it
nanonyme: Yups.
nanonyme: And not only an option but actually used too. :) (dunno how much, I only bumped into some occurrances)
nanonyme: It was iirc on libdrm side though.
suokko: libdrm implements assembly locks to optimize drm locking (at least one case that I know of assembly use)
nanonyme: Yeah, I think that's exactly the case I bumped into it.
nanonyme: Anyway, too much chit-chat, too little Sauna. ->
osiris_: who wants to test VBOs support? (r300 - r500 cards, TCL cards only)
osiris_: check out my repo http://cgit.freedesktop.org/~osiris/mesa vbo branch
adamk_: Can't right now, but maybe later.
adamk_: Does it require KMS?
osiris_: it gives nice performance boost (in sauerbraten up to 15fps depending on the scene)
osiris_: adamk_: nope
adamk_: Oh good. When I reboot, I'll give it a shot under FreeBSD :-)
suokko: Would it be easy to port vbos to r200?
osiris_: suokko: I don't know the r200 code so it's hard for me to say, but I think most of the could code be shared
osiris_: I think even r100 could make use of it
osiris_: maybe airlied will know better
suokko: Does only true benchmark (gears) speed up from vbo support? :)
MostAwesomeDude: Probably.
bobbens: glxgears uses vbos?
bobbens: i thought r3xx already did vbos, or is it sw only
bobbens: ?
MostAwesomeDude: dlists, which should get converted to vbos.
bobbens: well when using vertex arrays and vbos with latest ati drivers (with gamma glitch) I see no perf difference
suokko: bobbens: VBO support was just faked and driver was copying the list every frame to vram
bobbens: mmm, fun
osiris_: suokko: I've tried 3 games and all seem to profit
suokko: So I should test it with r200 then :)
adamk_: What games? :-)
suokko: adamk_: Nexuiz, saubertan, warzone2100, ....
osiris_: adamk_: sauerbraten, painkiller, ut2004
nha: osiris_: sounds very nice; I'll probably take a look later, right now I'm testing the compiler stuff on my R300
nanonyme: osiris_: Btw, is the "TCL-only" thing because it's not possible to implement without TCL or that the implementation just doesn't support those cards?
MostAwesomeDude: nanonyme: I'd guess that it's because most RSxxx chipsets don't have VRAM.
nanonyme: Ah, right.
nanonyme: eeks at one of the r600 driver commits: that's just the thing I was looking at a few days ago >.<
nanonyme: (that is, the scratch stuff)
osiris_: nanonyme: it's because we do vertex shaders in software and we would have to store data for every VBO and vertex shader combination that will be used
nanonyme: Then again, I wouldn't have known why it would have to be changed anyway.
suokko: What did I do wrong? make: *** No rule to make target `depend', needed by `default'. Stop.
nanonyme: osiris_: Sounds good enough a reason to me.
nanonyme: suokko: What are you trying to do?
suokko: Compile vbo mesa :)
MostAwesomeDude: osiris_: Ah, I see. You don't have guarantees about VBO+shader compatibility.
osiris_: suokko: did you run make in top mesa dir?
suokko: yes
osiris_: did you run ./autogen.sh first?
suokko: yes
suokko: I also tried to run make in r200/r300 directories
osiris_: try make realclean, and then autogen again
adamk_: As a possible exercise in futility, I'm trying to compile a newer version of the r300 driver on OpenBSD. ./configure goes fine, but the build dies on libGL: http://pastebin.com/m5b77be24
suokko: Intresting part is that same makefiles in my mesa tree compile without problems
adamk_: Any thoughts?
suokko: osiris_: The symbolic link is missing
ajax: adamk_: if i had to guess, you're building the dispatch code with the assembly enabled in one place and disabled in another
suokko: radeon_buffer_objects.c should be linked to r300 directory
ajax: which is really quite wrong, since you should be building it only once, period.
adamk_: Hmmm.
suokko: and radeon_buffer_objects.h too
osiris_: suokko: aah, right
suokko: osiris_: or you should add them to git if you have them in your local tree :)
adamk_: ajax, should --disable-asm avoid that entirely?
ajax: adamk_: it might!
adamk_: Unfortunately, it doesn't :-)
adamk_: Hmm... Let me 'make realclean' first and try again.
nanonyme: How many clean levels there are? :D
adamk_: Nope.... No love.
adamk_: Oh well, I'll check with oga when I have more time.
osiris_: nha: I've just run some tests on your r300-compiler branch on my rv515. everything seems to be fine so far
nanonyme: Hmm, neat. texcyl works nowadays perfectly, it seems. :)
nanonyme: Hmm.
nanonyme: http://koti.kapsi.fi/nanonyme/public/r600_vs_swrast.png Yeah, only RGBA tests seem to have problems in texenv anymore.
nha: osiris_: thanks; I've found some fail on R300 though, so going to debug
kdekorte: nanonyme, have you tried pointblast... I think that it is only incorrect due to an alpha color
nanonyme: kdekorte: Nope but sounds likely.
nanonyme: Something seems to be quite wrong with RGBA.
kdekorte: dinoshade looks pretty good
kdekorte: and so does reflect
nanonyme: Yeah, texenv is just a pretty extensive test, that's why I compared on that.
nanonyme: (well, not very extensive but much more than single tests often are)
kdekorte: interesting the redbook texgen hardware vs software the main pot is the wrong color
airlied: osiris_: yeah the vbos should be possible across all cards I think
airlied: osiris_: r100 can't do indices out of the cmd stream
airlied: would I need to port the _draw.c code?
nanonyme: kdekorte: It's using RGBA.
nanonyme: It's the exact same issue we've been getting through the day. ;) RGB works, RGBA borks.
osiris_: airlied: I think so, or make it general so all radeon drivers can use it
nanonyme: Iirc the suspection was the green and blue channels would be swapped but I'm not sure.
nanonyme: (assuming rgb means red-green-blue in this context like it sometimes does)
osiris_: s/general/generic/
nha: No more regressions on R300, as far as I can see, pushed r300-compiler to master
nha: this is only the compiler refactoring so far, the gallium changes aren't in there yet
osiris_: nha: great job
agd5f: nha: very cool :)
nanonyme: agd5f: Hmm, are you sure about the order of the params for RGBA in r600_texstate.c?
agd5f: nanonyme: not really. I haven't had a chance to debug that yet
nanonyme: agd5f: I and several others think either those or somewhere else the colour channels are in the wrong order which causes the current incorrect RGBA rendering.
agd5f: nanonyme: could be
kdekorte: nanoyme, which line are you looking at?
agd5f: kdekorte: r600GetTexFormat()
kdekorte: yeah, I'm looking at that
kdekorte: BIG case statement
nanonyme: kdekorte: I actually tried swapping all the params in the RGBA cases. Managed to get a green teapot in texgen with combination Z, Y, X, W with SQ_SEL_Z. I know, I know, this isn't the way you learn anything but it kinda proved the colour channels actually are in the wrong order.
agd5f: the default shader to CB map is X -> R, Y -> G, Z -> B, W -> A
kdekorte: that is what I was gonna do
nanonyme: agd5f: Thanks.
kdekorte: for RGBA_8888 you have W->X, Z->Y, Y->Z, and X->W.... if I am reading it right... this is the first case block
nanonyme: I'll just try the 1:1 mapping with (the original was inverted), let's see what's the output.
nanonyme: s/with //
agd5f: kdekorte: the tes res swizzles define how the data read in from the texel are mapped
nanonyme: Yeah.
nanonyme: Apparently it's supposed to be 1:1 in RGBA
kdekorte: ok for texgen, how can I find out which mesa_format it is using?
nanonyme: (unless there's a bug somewhere else)
nanonyme: goes check if he could find equivalents of older drivers
agd5f: kdekorte: print it out
kdekorte: that is what I am doing.. after a duh moment
kdekorte: MESA_FORMAT_RGBA8888_REV
nanonyme: http://koti.kapsi.fi/nanonyme/public/r600_vs_swrast.png originally, http://koti.kapsi.fi/nanonyme/public/swrast_vs_r600.png now
kdekorte: I got it!
kdekorte: texgen looks right now
kdekorte: agd5f, just sent you a patch via irc private message
agd5f: kdekorte: yeah
kdekorte: just changed the SQ_SEL_ values
kdekorte: I think that fixes texenv too
nanonyme: Like, yeah.
nanonyme: The bigger job is checking all the rest of the orders though. :p
kdekorte: yup...
nanonyme: Since if one was wrong, more can be too.
kdekorte: I think MESA_FORMAT_ARGB8888_REV is wrong too
kdekorte: but don't know how to test it
kdekorte: think the order should be W,X, Y, Z, instead of X,Y,Z,W
kdekorte: that is if, MESA_FORMAT_ARGB8888 is right
airlied: might check against r300
nanonyme: _ASSIGN(RGBA8888_REV, R300_EASY_TX_FORMAT(Z, Y, X, W, W8Z8Y8X8)) # hints to that the problem might be somewhere else
nanonyme: That's iirc exactly the original order.
nanonyme: Oh, or not?
nanonyme: Original in r600_state.c is W,Z,Y,X. (if these orders even have the slightest significance)
kdekorte: is the mesa ordering of colors the opposite of the radeon hardware?
agd5f: kdekorte: you can siwzzle it anyway you want
kdekorte: this stuff makes my head hurt
nanonyme: t->pp_txformat = R300_EASY_TX_FORMAT(X, Y, Z, W, W8Z8Y8X8);
kdekorte: but it is fun when it works
nanonyme: Ahh.
agd5f: when sampling the raw pixel looks like WZYX. what those channels map to depends on the format of the texture. it might be ARGB or BGRA or RGBA
nanonyme: And appears R300_EASY_TX_FORMAT is defined in r300_reg.h and is pretty neat.
nanonyme: I was kinda hoping for a thinko here but can't see one http://cgit.freedesktop.org/mesa/mesa/commit/?id=2c5e55d91992c5954e1d220a7ae497c7138595f5
nanonyme: That is, while moving to the SETfield macros.
agd5f: kdekorte, nanonyme: fixed. it was just the _REV formats
nanonyme: Neat.
kdekorte: great!
kdekorte: agd5f, so any word on the status of the replacement of memcpy?
agd5f: kdekorte: hopefully soon
kdekorte: my clutterdesk application almost works icons are triangles rather than boxes
kdekorte: This is clutterdesk... http://kdekorte.blogspot.com/search/label/ClutterDesk
nanonyme: Strange. I noticed I'm getting a full screen black screen on glsync. o.O
kdekorte: same here....
nanonyme: fire, on the other paw, locked up.
nanonyme: Appears demos are starting to divide to those that work perfectly and those that break horribly. ;)
nanonyme: What the heck is happening with geartrain though...
nanonyme: The gear in the backright has had rendering issues for a while but now it's actually turning round. :p
suokko: nanonyme: glsync is causing blackscreen with r200 too
suokko: So maybe it is realted to that gears blackscreen
suokko: I remember someone saying that single buffered visual had same black screen problem after double buffered version was fixed
nanonyme: suokko: It was glxgears that blackscreened iirc and it's afaik fixed.
suokko: nanonyme: I know
suokko: But my guess is that glsync is using single buffered visual that is not fixed
nanonyme: Hmm, yeah.
nanonyme: Appears they've found a better fix to it anyway than the one I saw.
nanonyme: Since 32bpp GLX VIsual is Ncon still.
suokko: nanonyme: ./glsync -s b
suokko: That works
nanonyme: That's an evil demo, makes my eyes hurt. :(
nanonyme: But yeah, you're right.
suokko: glxinfo -i crashed my server :(
nanonyme: Whoa.
nanonyme: Hey, I didn't know it could do that. :)
nanonyme: (as in, force indirect context)
suokko: How can I know which visual is selected by glsync?
suokko: Because it looks like single buffered 32 bit visual is the broken
nanonyme: Iirc someone said it shouldn't be used except for composited context.
nanonyme: feels like a parrot
otaylor: nanonyme: single-buffered+dri2 is probably a bad idea in general, whether composited or not
adamk_: osiris_, after symlinking those two files that suokko mentioned above, I tried compiling your mesa-vbo branch, but it dies with: 'r300_draw.c:248:9: error macro "radeon_bo_open" requires 7 arguments, but only 6 given"
agd5f: adamk_: disable RADEON_DEBUG
suokko: nanonyme: Only difference between single and double buffered visuals seems to be direct color and true color
nanonyme: otaylor: *shrug* I have DRI1 anyway.
otaylor: nanonyme: for now...
nanonyme: For now, yes.
airlied: otaylor: blender ;-)
otaylor: nanonyme: singled-buffered + dri1 is going to look pretty bad of course, unless the app is highly specialized, and say, doing buffering itself
otaylor: nanonyme: I think the main original use case for single-buffered was apps that redraw on the scale of seconds-per-frame rather than frames-per-second
otaylor: nanonyme: which may be what airlied means by "blender", not sure :-)
nanonyme: otaylor: Mmh, I'm not sure if I'm following quite what you're trying to get through atm. I was mostly getting a full screen black screen with glsync with DRI1 with no params but disappeared with -s b.
otaylor: nanonyme: don't know what glsync is, don't know what glsync -s b gives you. I just was commenting on the general issues with single buffered visuals leaving aside bugs
nanonyme: otaylor: glsync is a demo in xdemos, -s b sets sync method to buffer swap
suokko: nanonyme: read commit message from 5ed440400573631f540701f3efd479d8c1592007
otaylor: nanonyme: that presumably has nothign to do with single-buffered vs. not
otaylor: well, except yuo ucan't buffer swap if you are single-buffered
suokko: So bug still is present in direct color visuals but glxgears selects double buffered visual that works
suokko: So bug is that direct color visual has broken color map which cause black screen
adamk: agd5f: I'm guessing that's not an environmental variable?
agd5f: adamk: no, in the code. you can also patch it up as per the other uses of that macro in r200, etc.
soreau: adamk: Did you get the bsd prob worked out?
adamk: soreau: On OpenBSD? No, I had to put that aside for a bit.
soreau: just curious :)
adamk: agd5f: In r300/radeon_common_context.h I'm seeing a define of RADEON_DEBUG to 0.
adamk: OK, so I edited radeon_common_context.h and specifically defined RADEON_DEBUG as 0.
adamk: Still no go.
soreau: adamk: What are you trying to concoct this time?
adamk: Just trying to compile osiris_' vbo mesa branch on FreeBSD.
adamk: Well now I can't get it to compile on Fedora either :-)
adamk: Oh, I forgot the symlinks on Fedora.
adamk: Hmmm... If I don't pass --disable-glut --disable-glu --disable-egl --disable-gallium on FreeBSD, it now stops with: 'radeon_common_context.h:2:1: error: unterminated #ifndef'
adamk: Guess I'll see if osiris_ is around tomorrow.
adamk: Hmmm... I'm beginning to wonder if that "requires 7 arguments" error is not fatal and think that this is the real problem: "r300_draw.c:243: error: 'radeon_bo_open' undeclared (first use in this function)"'
adamk: I'm too tired to deal with this now :-)
adamk: bbl.
Renacor: Could somebody help me with this please: http://nopaste.info/af9c1fd689.html , I am particularly interested in line 1038-1039 (this is the last line when X initially starts up.) My problem is that I can only get a 800x600 resolution on a VGA monitor, but works fine in 1280x1024 on a DVI monitor.
Renacor: man it's quiet in here
boghog: indeed
hax0r1337: maybe too many people are satisfied with 3d already? :P
Renacor: sucks, i can't figure this problem out
Renacor: and google isn't helping much
boghog: someone should update the topic and change 'no 3D' to 'some 3D' :)
DanaG: Bah, it's not "some 3D" until I can run rss-glx "skyrockets" with at least not hard-lockup. =þ
DanaG: Note that I say nothing about correctness of rendering. =þ
boghog: :p
Renacor: Could somebody help me with this please: http://nopaste.info/af9c1fd689.html , I am particularly interested in line 1038-1039 (this is the last line when X initially starts up.) My problem is that I can only get a 800x600 resolution on a VGA monitor, but works fine in 1280x1024 on a DVI monitor.
boghog: ah, looks like my texturing issue with swapped colors has been fixed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=fcf317ac16e72cff754640cb6c7490531d5de667
boghog: Renacor, I'm afraid I understand nothing of that modesetting stuff :/
Renacor: boghog: me neither, i just tried it out but it doesn't seem to help