We need to work on what the REAL API is going to be. As mentioned, some things, like enables, are really inefficient. What I can do on Monday is make up a preliminary register set, and we can tweak the model to that that.
Thank you for helping us on this! On Sun, 30 Jan 2005 10:01:48 +0100, Nicolas Capens <[EMAIL PROTECTED]> wrote: > 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) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
