OSDev.org

Hi,

I will quote a very interesting input from Brendan, while we were discussing the philisophical need for a new Os

If you're attempting to attract market share eventually (even if it's only a tiny market share in a small niche); then recycling/modifying an existing OS (or even just an existing OS design) mostly prevents you from finding a competitive edge and therefore guarantees failure.

To me, he is right.

But there is one point I cannot go beyond: 3d proprietary drivers.

This only point would imply to:
1) beg nvidia to create a driver that could fit my Os. Who was laughing?
2) copying ideas (DRI) and create a linux compatibility layer ( putting large parts of the linux logic in my kernel and at some point, making the whole project more fragile)
3) your idea

It is okay to define new ideas but what if those cannot be made real because of proprietary drivers? Hence reducing the interest of your OS?

Is the only answer: if you need 3d acceleration, just use linux and never come back on that forum ( )?

Thanks bye

AlexHully wrote:3) your idea

Design and implement an operating system that is interesting enough without the proprietary drivers. After that, I am sure things will work out naturally.

Nothing can beat your answer I fear

AlexHully wrote:Hi,

I will quote a very interesting input from Brendan, while we were discussing the philisophical need for a new Os

If you're attempting to attract market share eventually (even if it's only a tiny market share in a small niche); then recycling/modifying an existing OS (or even just an existing OS design) mostly prevents you from finding a competitive edge and therefore guarantees failure.

To me, he is right.

But there is one point I cannot go beyond: 3d proprietary drivers.

This only point would imply to:
1) beg nvidia to create a driver that could fit my Os. Who was laughing?
2) copying ideas (DRI) and create a linux compatibility layer ( putting large parts of the linux logic in my kernel and at some point, making the whole project more fragile)
3) your idea

It is okay to define new ideas but what if those cannot be made real because of proprietary drivers? Hence reducing the interest of your OS?

Is the only answer: if you need 3d acceleration, just use linux and never come back on that forum ( )?

Thanks bye

1.) A better idea is to support AMD and Intel graphics since they give out their specs... and since intel onboard graphics are more common than any nvidia card ever was, you'll support the majority of the market. If/when your OS is big enough you can either talk to NVidia and possibly get some specs or have them design it, or design some sort of compatibility layer like you said. There is nothing stopping you from implementing graphics drivers (besides time, and possibly skill?).
2.) You can do this, and they will run slower than linux, which already runs slower than windows...

3.) My idea is simple, I plan on implementing Intel HD graphics into my OS and supporting the Vulkan API (whenever they finally release the specs!!), it's the next step past opengl, and much lower level (meaning, less things to support in the driver). I am also writing a software stack with programmable pixels/verts/geometry/gpgpu, that way if I don't support your hardware you can still run (albeit very slowly). And, it will be an interface for others to implement hardware drivers in the future.

* Note, I said the idea was simple, not the implementation. I have about 75% of my SPIR-V decoder done (Vulkan bytecode for shaders), my math library is almost done, I can rotate points and project them on screen using my matrix library. I had the rasterizing engine written, but I think it needs a rewrite as it is reused from very old code. I still need to write a compiler to take the spir-v bytecode and either generate x86 code (or, more likely for now) generate simpler to process bytecode and run it through an emulator/interpreter.

You are right, my chance is to work with Intel first.

I will ditch all the things I don't want (even X) and modulate the code exactly like I want.
I've already read the Intel graphics specs. It is complicated to make a graphic card to work, but I will make it.

That solution suits me as it enables to create a whole new graphic stack.

Thanks Ready4dis

AlexHully wrote:You are right, my chance is to work with Intel first.

I will ditch all the things I don't want (even X) and modulate the code exactly like I want.
I've already read the Intel graphics specs. It is complicated to make a graphic card to work, but I will make it.

That solution suits me as it enables to create a whole new graphic stack.

Thanks Ready4dis

Good luck, I got my programmable vertex shader working today in my software renderer... although, right now you have to write it in c/c++ . But, you can modify the vertices before rendering. I am currently working on the programmable fragment shaders next. Eventually I want to be able to take SPIR-V and generate x86 code (either asm or possibly even just C/C++) and then compile to a library to load in the graphics driver. For now, I'm ok with just writing c++ shaders though until I can make sure everything works properly, then i'll work on dynamically loading shaders from a .dll file (or similar), then i can work on converting spir-v into either asm, c, or possibly LLVM IR for compilation.

@Ready4Dis: wow that is a HUGE bump from you. Lot of work. Is your project open? Lot of dependencies?

As far as I am concerned, I try to just modify the open source intel driver to suit my needs, except proven wrong.
It should require a couple of "caffeinated" days to adapt and ditch the unused parts (yeah, lot of work).

I don't want to rewrite their driver, when they wrote it at first (to many hurdles for a null net result).

Doh, my entire post just got deleted. I clicked submit and it didn't do anything ... well, let me try this again.

@Ready4Dis: wow that is a HUGE bump from you. Lot of work. Is your project open? Lot of dependencies?

Not many right now, but I'm sure as it gets further along it will. Right now all development is in windows using a screen buffer, so the only dependency at the moment is a pointer to a screen buffer along with it's info. It's not exactly open source, but it's not exactly closed source. I just haven't bothered to setup any code sharing or anything (or put a license in any of it). I am writing a mono and micro concurrently, and I plan to keep all my drivers source (and most likely) binary compatible, so the dependencies are in a library to interface the kernel. This keeps the driver more simple and means it can work with different types of kernels.

As far as I am concerned, I try to just modify the open source intel driver to suit my needs, except proven wrong.
It should require a couple of "caffeinated" days to adapt and ditch the unused parts (yeah, lot of work).

I don't want to rewrite their driver, when they wrote it at first (to many hurdles for a null net result).

My intention is to only support the (yet unreleased) Vulkan API. Since it's highly based off of AMD Mantle, I can be pretty safe to assume Intel hasn't made a driver for it yet (unless they got a prerelease spec of the Vulkan API). Either way, I don't want to include their bloat in my driver, and I want to abstract as much as possible out to make other drivers easier. The parts that aren't device specific (GPU memory management, texture loading, state saving, etc) should all use the same stub, then the specific parts should only need to be written per device.

Ok fine!

And what about accelerated 2d rendering in your project?

What will you use? X, direct rendering, everything as 3D, else?

AlexHully wrote:Ok fine!

And what about accelerated 2d rendering in your project?

What will you use? X, direct rendering, everything as 3D, else?

My intentions are everything is handled using 3d primitives. If you want to draw a box, render two triangles. This has the benefit of being able to rotate, scale, etc. I'm still not 100% finalized on design (is anything we do ever really finalized?), but I don't intend on using 2D unless I really find a good reason for it.

Really interesting point.
Isn't there performance loss to expect? (because of 3d complexity and setup to display even simple things).

If not, I will follow the same path as you.

Depends on how you design it and how efficient the graphics card is really... also, there are a lot of things that aren't possible in 2D that are in 3D . To me, the benefits outweigh the costs. To each their own though, everyone has different plans, it's just the way I am doing it, anybody or nobody can feel free to do the same .

If you go the same way, let me know when you get into the driver code/interface, I am interested in what others come up with to see how mine compares or possibly if they are close enough we could both work on drivers at some point to share.

I start designing it today and possibly coding tomorrow.

I keep you in touch

AlexHully wrote:I start designing it today and possibly coding tomorrow.

I keep you in touch

Ok, sounds good! I am *slowly* making progress with my software rendering. I may have to focus on more of my kernel and IPC here shortly though, I wonder if it would be better to work on a hardware driver along side my software rasterizer to help with abstracting parts that can be common and those that are specific. I would like to keep as much code the same driver to driver as possible, and only have to modify the parts that really require it.

Ok, so here is the plan.
Disclaimer: will only work for opensource drivers. Is intended at first to my system.

I have a hacker willing to help me.
Instead of starting from scratch, we start from mesa, libvaa and existing drivers that we adapt to our needs.

As I already started, there is a massive amount of LoC that are gone.

This strategy is faster for us to get working and it will be very lean. No need to change the whole stuff completely.
Drivers won't be touched more than needed.

It is made to replace the existing gui frameworks (qt, gtk), and coordination (X, dri), and it comes with a dedicated lightweight desktop environment.
Don't underestimate that last bold statement: massive code can be thrown away with a new desktop environment. It will be a futuristic (and beautiful ) hybrid-tiling one (no overlap possible, except popups). I am in charge of the design.
The framework is going to be very easy to customize (css like). But will always be a hybrid-tiling one.

You will still have the possibility to display multiple apps at the same time, hide them, etc.. and have overlaying popups. All that with animations.

Multi monitor will be managed with the api. (send_to_manager(char * buffer, struct display_hints * hints) )

So devs will have an easy framework API to deal with graphics. The math algos will be borrowed from open source project with complying licences. If the default math is not satisfying, devs can override the functions with function pointers.

Again, we have one life. This may be tuned by people later.

After all, when people are not satisfied and things are open source, they are legit to test and bring new ideas.

A compatibility layer is possible to converge gtk and qt apps to this framework. But at this point, we will need help from the community.

As part of the plan, there is something you may not like (for reason A,B or C). That thing is that every application submit its buffer to the framework and a very thin manager will update the screen. Hardware acceleration will work as usual.

If the app messes with its buffer, that is a problem which will not spread among other app renderings (different surface, even if the result will not be pretty).

The display manager is dozens of C code lines.

An interrupt manager will select the app to send it (do not try all the apps to see who need that interrupt).

What you may prefer: it will be easy to change that behavior (good separation of logic).
What it buys you, as a custom OS dev: more performance and lower electric consumption.

Once we feel that it is ready to show, I will post the github link.

Well..