That looks great Nicolai! Are we any step closer to an API with this? I'd really love to work on the OpenGL interface after my exams. Should every OpenGL state change just translate to a bunch of register writes? How will textures and vertex data be managed, in the software model?
Of course we want to keep the software model's interface much like the interface between the real driver and the real hardware, but we desperately need to get some simple OpenGL applications working. We'll bump into hundreds or thousands of 'unexpected' issues and the sooner we can start working on them the less time we waste on a buggy hardware implementation. Writing low-level tests is rather pointless because we'll only start seeing the problems in complex applications. Code a little, test a little... but we got to catch up and TEST A LOT. Kind regards, Nicolas -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolai Haehnle Sent: zondag 30 januari 2005 0:21 To: [email protected] Subject: [Open-graphics] Simulator program Hi everybody, I'm sure you all want to see more live action in this project. I know I do - which is why I decided to take the existing software model for a little ride. There isn't anything new in the actual software model except for a small fix [1] but there is some news in how it's used: The main component is a graphical simulator program that displays both a list of "hardware" registers and an actual view into video memory. It also listens on a Unix domain socket. This allows the other components, simple client programs, to send commands to the simulated "hardware". You will be able to see the result of those commands in the simulating program. See it in action: http://homepages.uni-paderborn.de/prefect/ogsim/ogsim-screen1.png What does this mean for the development? 1. We can get a better idea of the actual register interface. 2. We have a slightly better simulation of what control flow will be like (command streams, uploading textures via DMA, etc.). 3. We can create and test actual animations. So you want to try it yourself? Get it at http://homepages.uni-paderborn.de/prefect/ogsim/ogsim-050129.tar.bz2 Some notes: 1. I abused this project as an excuse to teach myself about KDevelop and KDE development. This means that the sources are a bit heavier than they'd have to be and you need to have KDE development headers etc. installed (including moc and uic). 2. The software model itself is basically unmodified except for integration parts in src/render.inc. 3. When creating the "hardware" registers, I simply went for a 1:1 mapping of variables to registers, so many of the registers are *extremely* inefficient (like all those _ENABLE registers). However, I assume the actual final register layout will depend a lot on the actual hardware, so I leave this to Timothy. 4. Textures should work, but there's no way to upload them and I haven't tried render to texture yet. Shared memory support for the IPC connection has a high priority on my todo list. 5. Some tricks are in the README - there's probably more, but I forgot. My plans are (roughly in that order) - get shared memory and textures to work - write a client that uses a more OpenGL-ish coordinate convention etc. - write more tests cu, Nicolai [1] ComputeColor/AlphaBlendFactors need a bitwise & in the switch() expression. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
