airlied: scsiraider: pong.
ssieb: airlied: is it a known issue that a gl window will always be on top?
ssieb: needs to check if xv does the same thing
ssieb: never mind, it's not doing it anymore
ssieb: although I do need to use vblank_mode=0
ossman: airlied, in fragment programs, are some of the register initialised to something useful when execution starts?
ossman: I see references to register 1 before it has been assigned a value
airlied: ossman: the shader doesn't execute until vertices are put into the pipeline
airlied: so the setup ordering isn't usually that important.
airlied: spots big AGP bug in kerne.
airlied: spstarr_work: when you read this please try -131 kernel on AGP kms
airlied: and anyone else...
airlied: spstarr_work: back out to the shipping -ati insetad of the hacked up one
MostAwesomeDude: Uf, Thanksgiving was good times.
MostAwesomeDude: ossman: My bicubic tree should have working r5xx filtering. The r3xx code didn't work right, although osiris, onestone, and I all looked at it and thought it looked right.
MostAwesomeDude: It's probably some kind of fragprog bug.
scsiraider: MostAwesomeDude, so its your bicubic code going into any driver yet?
scsiraider: MostAwesomeDude, you have figure out your fog issues
scsiraider: MostAwesomeDude <=== rmh3093
scsiraider: = rmh3093
scsiraider: MostAwesomeDude, fyi
loswillios: I'm using F10 with a XPRESS 200M 5955 (rs480) and my system freezes after a short while
loswillios: it's still responsive over ssh
loswillios: unfortunately Xorg.0.log doesn't say anything
ossman: MostAwesomeDude, ping
ossman: MostAwesomeDude, is the R300 program supposed to be more or less identical to the R500 one?
ossman: 'cause the annotations don't make it apparent that it is :)
glisse: ossman: which program ?
ossman: glisse, the bicubic texture video fragment shader
loswillios: it seems I resolved it by compiling git master
loswillios: although now I don't have the shiny fade effect from boot->gdm anymore
carldani: is there any interface in the radeon driver which would allow me to use the graphics card for copying RAM contents from one place to another?
carldani: by using DMA
carldani: (not video RAM, but the RAM attached to the CPU)
glisse: carldani: we don't want to expose such capabilities
carldani: I can understand that.
hifi: can someone enlighten me what would be the purpose of this?
carldani: if I understood the various web sites about the radeon architecture correctly, there are ops supported by the chip which should allow me to do it with amodified driver
carldani: hifi: sure.
glisse: carldani: you can do it with a modified driver but i suspect things will be slower than using memcpy
hifi: don't get me wrong, I'm not a dev, just a curious bystander :)
ossman: glisse, but you could do it whilst the cpu is doing something else
carldani: the goal is not speed, but rather the ability to perform transfers the host CPU won't do due to being in another mode or having artificial restrictions
glisse: ossman: well you have to take into consideration that you need to map this RAM uncached
glisse: so if you have to switch from cached->uncached you will likely hit horrible path which tear down TLB, page table ....
carldani: glisse: in case I want cache consistency?
glisse: not wanting cache consistency is asking for big trouble ...
carldani: the place where I'd use this is horrible anyway because it has to run wbinvd (writeback and invalidate caches) anyway
carldani: and after that, (if you can guarantee no writes to the affected memory region happen in between) cache consistency for the affected area is always a given
glisse: carldani: depend on your cpu
glisse: on amd for instance cpu can write back to cached memory no matter what the cpu is doing
glisse: so cpu can overwritte what you just copy
carldani: the destination will never be written by the cpu, only read
ossman: glisse, are you familiar with the fragment shader stuff?
glisse: carldani: yup, still some cpu write back what they have in cache
carldani: and the source won't be written between invalidation and the graphics card memory transfer
glisse: ossman: yes
carldani: glisse: and the AMD64 architecture manuals explicitly state that speculative writes are not allowed in any caching mode
ossman: glisse, does register 1 contain something special when a program starts?
glisse: carldani: google for that AMD cpu write back their cache
glisse: don't remember if it was a cpu bug or not
ossman: I'm looking at the bicubic video code, and it references register 1 before any assignment to it
carldani: glisse: thanks
glisse: ossman: reg 1 likely have somethings which is written by the raster pipeline
ossman: and that could be more or less anything depending on the vertex shader?
carldani: ignoring bugs for now. can I just issue two instructions which copy memory from RAM to VRAM and back? Since I don't know what to look for, searching is a bit difficult
glisse: ossman: well could be vertex shader but for bicubic i guess it's somethings which is routed directly
glisse: ie vertex shader are not used at all
ossman: how do I determine what it is? :)
glisse: carldani: x.org/docs/AMD/r5xx*pdf looks for packet3 page 29 somethings like BLIT, HOSTBLIT ...
ossman: I'm a complete noob with the radeon pipeline, but I'm trying to learn
carldani: glisse: Thanks!
glisse: ossman: R300_RS_INST_COUNT* determine where things are routed
ossman: glisse, hmm... do you mean the following R300_RS_IP_*?
glisse: ossman: yup but reg haven't the same name in the radeon_reg.h file
glisse: which suxxx
ossman: just one more question before I go neck deep again
ossman: when it references a texture using 1D mode, what result does that have?
glisse: ossman: see GL specification, i don't remember what means 1d texture anymore
ossman: ok. the hardware strictly follows GL behaviour?
ossman: for this at least :)
glisse: well more DirectX than GL but directx use same meaning as gl
ossman: glisse, I'll do some googling and see if I can make sense of things
ossman: thanks for the pointers :)
glisse: ossman: opengl.org have the documentation
glisse: and they explain things clearly
MostAwesomeDude: ossman: Pong.
MostAwesomeDude: The shader is what we got when we used the Mesa compiler. I'm told that it's the same shader that the AMD compiler produced, too.
ossman: oh? that was actually an idea I had. how do you get it to compile stuff for you?
ossman: and what's the original source you put in there? :)
MostAwesomeDude: Well, it's based off the bilinear-assisted bicubic filter in compiz.
MostAwesomeDude: So we did a dump of the shaders from in compiz.
MostAwesomeDude: You could also modify one of the progs/fp/tri-*.
ossman: is that in mesa?
MostAwesomeDude: Also, the AMD compiler produced the same program.
ossman: and the R500 and R300 code was both made the that way?
MostAwesomeDude: The R500 code was written out by hand by me, and then onestone tweaked it. I think the R300 code is actually a bit faster, probably.
ossman: hmmm... okay... so comparing the two isn't necessarily helpful I guess
ossman: can you talk me through what the algorithm is supposed to do though? :)
MostAwesomeDude: Well, it uses a helper texture to turn a bilinear-filtered texture into a bicubic-filtered image.
MostAwesomeDude: The bilinear filter is done by the GPU in the texture unit.
ossman: tex1 is the lookup table and tex0 is the real texture?
ossman: MostAwesomeDude, and it's supposed to implement a convolution?
airlied: loswillios: grab latest -ati from updatset-testing
loswillios: hm ok. I searched koji but didn't find anything. where is updateset-testing?
airlied: updates-testing even
airlied: koji has a -60 release
airlied: that'll also work
loswillios: ah, I have to use the whole package name. thanks airlied
ossman: MostAwesomeDude, I think I'm beginning to have some idea of this works... temp0 contains the computed texture coords for tex0 and temp1 the ones for tex1, right?
airlied: carldani: with a PCIE GPU you can in theory to snooped read/writes which are cache coherent
scsiraider: what repos do need to be pulling from to get kms and 3d accell
airlied: scsiraider: the same ones as always, except for libdrm which needs to be a few weeks old
airlied: for mesa you need my r300-bufmgr-fedora branch
scsiraider: airlied, can you give me a commitsh for the libdrm
scsiraider: or tag it or something
scsiraider: airlied, that commit is not building for me
scsiraider: radeon_cs_gem.c: In function ‘cs_emit’:
scsiraider: radeon_cs_gem.c:252: error: ‘i’ undeclared (first use in this function)
airlied: scsiraider: you jsut build libdrm
airlied: not the kerneol module
airlied: you get that from the kernel
scsiraider: so i need to use an older drm-rawhide too?
airlied: no the latest drm-rawhide should be fine
scsiraider: thats what I have
scsiraider: i just pulled
scsiraider: and rebuild that
glisse: airlied: familiar with dispatch code ?
airlied: glisse: glapi.runaway.
airlied: glisse: btw any ideas, I'm getting reports of an X300SE hang introduced in 2.6.27
airlied: the patches that went in are your and nha hang fixs
glisse: nha where userspace ?
airlied: glisse: the two emit INDX_BUFFER ones
airlied: glisse: nha was the emit INDX_BUFFER
airlied: yours was fix some hard lockups on r3/4/5
airlied: glisse: I'm blaming yours :)
glisse: airlied: try with a patch which change all my FLUSH cmd in my pathc with :
glisse: RB3D_DC_FLUSH only
glisse: is remove all DC_FREE
glisse: which my patch introduced
glisse: in fact we should never set DC_FREE
glisse: not without stalling the whole fifo and filling it with empty ness
glisse: or with NQ_WAIT
airlied: I've sent him a revert to test, if it is that aptch I'll send him some fix attempts.
airlied: glisse: we used to use DC_FLUSH_ALL which was the same as FEE
airlied: FREE even
glisse: airlied: what i meant is that we should not set the FREE bits
glisse: and FLUSH_ALL iirc set all bits
glisse: we should only set the flush bit so the reg is pipelined and go through the fifo
airlied: yeah so the old code used to do it, at some placse we need to use FREE.
glisse: ie stall the fifo until the flush happen
glisse: then wait should succeed
airlied: I thought FREE + WAIT_UNTIL would work fine.
glisse: we should use free very carefully as it's not pipelined then
loswillios: airlied: nice, it works now (even google-earth, which didn't run with git-master) - thanks!
airlied: glisse: yeah I tried removing it from EXA, things dont work very well :)
glisse: no because for instance the free might happen after the wait and let the cache in bad state for the wait to never see it
glisse: but we need free
airlied: ah if we don't free then wait straight away.
airlied: random freeing is bad.
glisse: just that we need to fill the fifo after the free and stall the fifo with somethings :)
glisse: then wait should be safe
glisse: well it's my understanding of a race i saw with free/waitidleclean
glisse: for instance doing flush, waitidle, free|flush should be ok
airlied: glisse: I wonder is that whatr messes up EXA on the rs690
carldani: airlied: that's really good news to me, thanks!
airlied: glisse: I worked around the issue by flushing the indiret after every rendering
airlied: but I suspect the EXADoneComposite might need some work
glisse: airlied: well there are things we do badly, but for instance in my dri2 branch i was unable to trigger lockup on my touchy rv350 with same test case which used to lockup with normal cs
glisse: ie old cs
glisse: i have a rs690 which i need to use too, so can test lockup prone case
glisse: anyway will be busy a bit with others things first
airlied: gtkperf -c 100000 -a
glisse: i wish i know how to fix this dispatch stuff so i can test gallium
ossman: MostAwesomeDude, I'm trying to understand the math here, so if you have a few minutes, that would be helpful
glisse: ossman: http://en.wikipedia.org/wiki/Bicubic
ossman: glisse, it doesn't go into the aspects of implementing this through a fragment shader through some clever use of another texture as a lookup table though :)
ossman: primarily I'm confused by the fact that it does a texture lookup based on a pixel calculation. which seems odd since I assume everything should be in [0,1] texture coords
glisse: ossman: a better link http://http.developer.nvidia.com/GPUGems/gpugems_ch24.html
glisse: which describe all math behind
glisse: in a pretty straighforward way
glisse: got to go
onestone: ossman: http://medvis.vrvis.at/fileadmin/publications/TR-VRVis-2004-053.pdf
ossman: onestone, thanks. it hade perty pictures and all :)
onestone: ossman: this is the shader we used. I've converted it to ARB_fragment_programm for the compiz bicubic plugin and then we used it for the radeon video filter
ossman: onestone, are we talking about the R500 or R300 version now?
ossman: I figured I'd start by understanding the R500 one as that one is actually working :)
onestone: ossman: both. we used the ATI GPU shader optimizer to get the basic code. On r500 is worked so I could optimize it more. The r300 code should be the pure GPU shader analyzer version
ossman: oh.. hang on... it's 1/width, not width. that would explain things
ossman: goes away in shame
ossman: onestone, any special reason for the creative swizzling in places where it has no effect on the result?
RTFM_FTW: mmm what type of filter are you implementing?
RTFM_FTW: just out of curiosity...
ossman: RTFM_FTW, I'm trying to get the bicubic video filter working on r300
onestone: ossman: I've never really looked at the r300 code
ossman: onestone, this is the r500 code
RTFM_FTW: heh bilinear wasn't good enough?
ossman: nope :)
ossman: onestone, e.g.: TEX temp1, temp3.zwxy, tex0, 1D
ossman: since it's a 1D texture, only z will be used anyway
onestone: ossman: there are some r300 swizzling limitations
ossman: onestone, ok. out of curiosity, how would someone writing a generic FP handle that problem? :)
onestone: ossman: there is no generic FP
ossman: oh? I thought this syntax was something generic that you could use safely in OpenGL?
scsiraider: airlied, alright my kms and dri are working again
scsiraider: airlied, when i pinged you last night i had a different question though
m03sizlak: is there a place where i can get svn copy of xorg-x11-drv-ati for fc10 ?
onestone: ossman: ARB_fragment_program is generic it then has to be converted into hardware specific. The GPU shader optimizer will then convert the swizzling into something the hardware can understand so that temp3.zwxy or temp3.zzzz will be optimized out
ossman: onestone, ah. so the same language is used to describe what's going on on several levels of the system?
ossman: or do you mean it just ignores irrelevant stuff when it compiles it to something hardware specific?
onestone: ossman: ???
RTFM_FTW: heh ARB_fragment_program for the most part is *not* a good indicator of what the underlying shader ALUs are capable of
ossman: onestone, last time I got myself involved into 3d, it was strictly fixed pipelines, so it is taking some time for all of this stuff to sink in :)
RTFM_FTW: specifically on newer (i.e. R6xx+) ASICs
RTFM_FTW: its really quite unfortunate that so many developers latched on to this form of "shader" development :(
airlied: scsiraider: ?
scsiraider: i have access to 2 hdtvs
scsiraider: both are 1080p
scsiraider: when i connect to one of them i get a 720 mode
scsiraider: and no 1080 mode
scsiraider: on the other tv i get 1080 but no 720
scsiraider: this is using an hdmi to dvi cable
scsiraider: if that matters
scsiraider: if i add a modeline for 1080p@60 it works
scsiraider: on the tv where no 1080 mode shows up
scsiraider: i cant believe the tv puts out only 2 modes from EDID
airlied: scsiraider: it might use EEDID.
airlied: which needs a newer server.
airlied: I think the 1.5 servers can parse it, but maybe it'll be in 1.6
scsiraider: is that a massive change or is it a patch that I can pull out from git and apply to 1.5.2
airlied: scsiraider: http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/F-10/xserver-1.5.0-edid-backport.patch?view=log
airlied: that might be it
scsiraider: nice, the patch applied cleanly, gonna have to post than on b.g.o if it works
airlied: let me know if it works, I'm just guessing it might be an EDID issue.
airlied: we might still not parse all the bits, you might need to rebuild the driver against the server also.
scsiraider: airlied, i sorta remember more modes showing up in radeonhd way back
scsiraider: but lately radeonhd shows no modes
scsiraider: so 2 is better than none
scsiraider: brb, testing the patch
scsiraider: airlied, didnt seem to help
scsiraider: i get the same modes as i did before
airlied: scsiraider: did you rebuild the driver against the server?
airlied: try option "modedebug" "true" and see if the log reports anything.
scsiraider: xorg option?
scsiraider: ok it running with modedebug on
MostAwesomeDude: ossman: Most GPU pipelines don't exactly correspond to arb_f_p or arb_f_s, instead we have to convert the instructions in a way that correctly exposes the hardware.
MostAwesomeDude: Shader assemblers are really like compilers nowadays.
airlied: glisse: you might be right I think changing the EXADoneComposite from FREE|FLUSH + WAIT UNTIL to FLUSH + WAIT_UNTIL + FREE
airlied: seems to maek the rs690 a lot happier
scsiraider: airlied, anything you want me to get regarding my lack of modes issue
airlied: scsiraider: can you pastebin the modedebug log
airlied: I'm not sure we can fix it in the driver, so it might need to be the server that needs changes.
airlied: ah we don't seem to parse all the extensions yet.
scsiraider: we as in radeon driver or we as in xorg
airlied: I think some patches from Intel are floating about on the mailing list
airlied: for doing some more of EEDID stuff
scsiraider: airlied, when i check the xorg logs it says eedid support was added to the ddc module in aug
airlied: scsiraider: yes it just doesn't parse all the HDMI additions.
scsiraider: so the commit message " Actually fetch all blocks of EEDID if asked to." is wrong ;)
airlied: nope it fetches the blocks
airlied: it just doesn't parse them
airlied: they added vendor extension blocks.
scsiraider: so they did the CES blocks
scsiraider: or what ever they are called
airlied: CEA blocks I think
scsiraider: i was just looking at the hdmi 1.3 spec
airlied: the patches on xorg list might be worth looking at
airlied: from Ma Ling
scsiraider: found them
scsiraider: i will see how they work
ganymede: hello, i have this card: ATI Technologies Inc RS482 [Radeon Xpress 200M] and was wondering if 3D on this card is up to speed. it believe it is an R300 card but when i checked earlier, there were problems with memory on these Xpress 200M cards so 3D was not available. i was wondering if this is still the case
ganymede: and maybe it is worth mentioning that when i ran lspci about a year ago, it showed up as an RS485 although i don't remember if the string inside the brackets was the same
ganymede: on the laptop sticker, it said something like Radeon Xpress 1050, but i don't remember the exact number since i have torn it off a long time ago
ganymede: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP] may have been it
airlied: ganymede: it should work for most things fine
ganymede: airlied, has this been recently fixed? and do you know about why lspci has given me different results over the years?
airlied: lspci isn't a problem.
ganymede: (i've used different distros on this laptop, not sure when it started giving me a new chipset)
airlied: the AMD naming is a bit messy.
ganymede: guess i'll just grab the git sources for mesa and drm module? (or all of Xorg?)
airlied: it should have upstream support in the kernel for quite a while
airlied: F10 or Ubuntu 8.10 should be fine on it
airlied: (F10 with an updated driver, the GA driver had some issues)
airlied: the 3D support is the best in the world, those chips don't have vertex shaders
ganymede: thanks for the advice
ganymede: yeah, i'm not expecting anything amazing from this card. a desktop geforce 3 outperforms it easily (when compared with binary drivers)
ganymede: on tom's hardware's benchmarks, it's off the charts...
ganymede: ...in the negative direction
scsiraider: airlied, those eedid patches use some reduced blanking patches too
airlied: ah they are against master so might need other bits.
airlied: glisse: actually I lied didn't help my rs690 issue here :(
ganymede: airlied, you said "the 3D support is the best in the world, those chips don't have vertex shaders" did you mean to say that the 3d ISN'T the best in the world since the card supports vertex shaders but not the mesa driver?
airlied: oops 3D isn't the best
airlied: the card doesn't have vertex shaders
airlied: mesa sw vertex shaders suck quite a lot
ganymede: in ##hardware, they say, "i hesitate to call the 200M a 3D chipset" since apparently, they have seen it outperformed by a 7200
airlied: agd5f: ping
airlied: agd5f: when posting pre-ATOM cards with the tables, I'm not seeing the MEMSIZE get set, so I end up with 8MB :(
scsiraider: airlied, so if I get xorg-server from master with the eedid patches applied... i should magically have more modes? or does something in the ati driver still need to happen?
airlied: scsiraider: I think magic happens but I could be wrong, I've never tested it, ajax looked at it more.
scsiraider: well it compiled :D
scsiraider: lets see if the magic happens
scsiraider: airlied, the patches work 1920x1080 60.0*
scsiraider: but now i cant build mesa
airlied: scsiraider: nice.
scsiraider: cause i had to update dri2proto
scsiraider: dri2.c:117: error: ‘xDRI2ConnectReq’ has no member named ‘screen’
scsiraider: dri2.c:124: error: ‘xDRI2ConnectReply’ has no member named ‘busIdLength’
airlied: you need a newer dri2proto
airlied: or --disable-dri2 might work
airlied: or a newer mesa
scsiraider: airlied, i though i needed your mesa branch
airlied: ah then --disable-dri2 to mesa might help
airlied: forgets when I branched off
tlp: airlied: are your r500 AGP changes only useful for kms?
airlied: tlp: yes
scsiraider: airlied, --disable-dri2 is not a option for your mesa
scsiraider: it requires 1.99.1
scsiraider: airlied, i think you need to cherry pick this http://cgit.freedesktop.org/mesa/mesa/commit/?id=4830809524b20e517e949151957512b14d7e679a
scsiraider: seems to be doing the trick
scsiraider: it applied cleanly
scsiraider: ahh spoke toosoon
scsiraider: but its a new error
airlied: scsiraider: that branch will be a dead end soon, have to try and get proper 3D driver support using glisse work now
scsiraider: is that close?
airlied: it works for him.
airlied: but the API isn't lined up properly with kernel bits.
scsiraider: well the error im getting now is this
scsiraider: radeon_screen.c:363: error: storage size of ‘pin_args’ isn’t known
scsiraider: radeon_screen.c:388: error: ‘DRM_RADEON_GEM_MMAP’ undeclared (first use in this
airlied: radeon_drm.h is wrong somewhere I would suspect
scsiraider: yeah my libdrm is wrong somehow
mattst88: airlied, what are the implications of not having a working AGP GART driver? is this going to kill performance of AGP cards?
airlied: mattst88: you get PCI speeds, and you have to use PCI GART instead of the AGP one.
scsiraider: airlied, well not that i fixed my libdrm issue mesa builds so that patch saved the day... may as well pull it in
mattst88: airlied, so significantly slower?
airlied: mattst88: well 1x AGP == PCI, so depending on how much data you transfer to the card
mattst88: airlied, I'm filing a kernel bug report about missing AGP GART support on an Alpha motherboard, feel free to reassign to Ivan Kokshaysky if you want
airlied: mattst88: does the Alpha have AGP?
mattst88: yes, a few high end systems, and then 3 AMD chipset powered boards from Samsung
airlied: the alpha-agp.c driver doesn't cover it?
airlied: or maybe some of the other agp drivres for AMD chipset ones
mattst88: yeah, I wonder if the code has been written but isn't in the right place
airlied: mattst88: what chipsets are they?
mattst88: see line 251 of arch/alpha/kernel/core_irongate.c
mattst88: Irongate (AMD-751 and AMD-761)
airlied: ah... then its an alpha bug not an AGP issue really.
airlied: sounds more like a CPU coherency.
mattst88: ahh, how should I categorize the bug then? Platform-specific?
airlied: yup.. alpha platform at least.
mattst88: OK, thanks for your time
scsiraider: airlied, the ati driver fail horribly with xorg from git and/or latest dri2proto
scsiraider: compiling that is
airlied: scsiraider: wierd, well not so much wierd, as not a major surprise
scsiraider: so u are done working on those branches? let me know when there is a kms/dri2 branch to start playing with
airlied: no I'm not finished, but they are now firmly based on what F10 ships
airlied: so they won't build against brand new pieces of upstream
scsiraider: should i post a bug on xorg or the mailing list about those eedid patchings working perfectly
airlied: if they work no need to post a bug.
airlied: they will be merged when ajax thinks they are ready (they have API breaking possibilites)
scsiraider: airlied, i managed to overwrite my ati driver ebuild with some garbage
scsiraider: which repo/branch should i be pulling from for that
agd5f: airlied: ok. I'll talk to the bios guys tomorrow
airlied: scsiraider: radeon-gem-cs from my tree
scsiraider: airlied, i've got it all working now!!!
scsiraider: the patch for the ati driver was a 1 liner
airlied: scsiraider: woot
scsiraider: yup, thanks for your help
scsiraider: airlied, i lied
scsiraider: now that im using your ati driver
scsiraider: i dont get all the modes
airlied: yeah kms doesn't dod EEDDI yet.
scsiraider: even though im using xorg 1.6.99 with the eedid patches
scsiraider: can i steal that patch from the master repo?
airlied: KMS isn't anything to do with X
airlied: kms is *kernel* modesetting
scsiraider: right... i just though u were talking about the x driver i didnt think eedid was in the kernel
scsiraider: cause i didnt change anything on the kenel side
scsiraider: since the modes were working
airlied: kernel modesetting moves modesetting into the kernel
airlied: you aren't using kms when using the other ati driver
scsiraider: oh i see what u are saying
airlied: I need to provide a way to give X the extended blocks from the driver so it can find the bits.
scsiraider: well if u figure out a solution send me a patch to try ;)
m03sizlak: My question is the following statement: Operating System 4.2 has sloppier architecture than a Tijuana anthill.