I have googled for linux io monitoring, but most of the search results are about disk I/O monitoring, while i need to monitor I/O in general, e.g. bus master I/O, etc. and in particular, data transfers to/from video card, i.e. how much data is being transferred, when, etc.. Is there a tool for this?

Don't think so, because what you are talking about would use I/O and cpu and affect the measurements :-/. The other factor here is that you are really into low level hardware stuff. Hence benchmarking tests like phoronix test suite which allow comparisons to be made.

It gets very complicated; let me illustrate. Ram timings are something like 6-1-1-1, meaning it takes 6 wait states to find an address, but the immediately following stuff comes/goes with only one wait state. But the relevant stage holds it's breadth (electronically speaking) until the ram can be written to. Now how quick your access is can be determined by how sequential your addresses are. Intel and AMD also have different ways of saying how fast the cpu is going. Stepping considerations exist also - too fast throws in extra wait states. Memtest86 has a speed indication that's about the most reliable ram seed I know of. For video, glxgears running with top is interesting. I have an old box with good video, glxgears gets 99% cpu. New laptop with poor video, and glxgears gets less cpu because the i/o isn't up to speed.

Well, i'll explain my problem in more details. I have a benchmark (Unigine) which has OpenGL and Direct3D modes (under WINE). Direct3D mode is about 2 times slower than OpenGL one. But they both are implemented via single API, OpenGL. My aim is to find, why wined3d is so slower than wineogl, i.e. what operations take that much time. I have tried using CPU profilers, such as sysprof, but i didn't succeed because not only CPU is used here. I guess this may be unoptimised data transfers to video card, because the more polygons in the scene, the greater the lag is. So, i want to compare amounts of data transfers to video card in pure OpenGL mode vs. wined3d mode. Maybe there's another way to find bottlenecks in this situation?

This is Open Source. I would email the author with your specific concerns.
I gather from my attacks on ATI/AMD linux developers that there's a huge difference in the speed of different opengl calls, and You're comparing that with an emulated direct access, which could be anything, in the real world. OpenGL has a windows equivalent, whereas DRI doesn't really, afaik. Open winecfg and check the graphics tab. Wine forums will tell you how access is delivered, but as it's designed to run on just about any video card, some supercompatible format will be used which eliminates all clever tricks pulled by individual manufacturers.

In short, the last thing direct3d is likely to be doing is direct3d :-/.