Jump to content

  • Log In with Google      Sign In   
  • Create Account

Matias Goldberg

Member Since 02 Jul 2006
Offline Last Active Yesterday, 11:21 PM

Topics I've Started

[D3D11-OGL4] Access to all 3 vertices in the vertex shader

14 July 2015 - 03:45 PM

So... I'm working on an algorithm that requires access to all 3 vertices either in the vertex or pixel shader. Preferably on the VS.

I'm undecided on which one is the best approach (best as in = highest performance). I'm targetting DX11 hardware.

So far I've got the following alternatives:

1. Geometry Shaders. Make a pass-through geometry shader to access all three vertices information and send it to the Pixel Shader. Fortunately I only need to pass 4 float4s to the pixel shader which fits in the GCN cache according to the documentation. But even then, Geometry Shaders are slow. A GS also eliminates the chance to use the pos-vertex cache. I'm worried it won't scale well with high vertex count geometry.
2. Bake the information in the vertex buffer. Create a vertex buffer specifically for this pass, where the vertex position is stored in the POSITION semantic, and the other two positions in two TEXCOORD semantics.
With this method I can get rid of the index buffer and draw using triangle lists. However I'm worried some meshes would sky rocket in memory consumption (and thus bandwidth), since I need 3 vertices for every triangle, no chance to reuse. I can reduce the vertex size by storing the positions as 16-bit floating point. But the hit comes really from the vertex count.
At least GPUs have been traditionally optimized for this kind of throughput.
3. Use two structured buffers and fetch the vertex data manually. One structured buffer would contain the index buffer, the other the vertex buffer.
Use SV_VertexID in this way:
struct Vertex
   float4 vertexPos;

StructuredBuffer<uint> indexBuffer;
StructuredBuffer<Vertex> vertexBuffer;

Vertex currentVertex = vertexBuffer[indexBuffer[vertexID]];
Vertex prevVertex = vertexBuffer[indexBuffer[vertexID - 1]]; //Also deal with out of bounds
Vertex nextVertex = vertexBuffer[indexBuffer[vertexID + 2]]; //Also deal with out of bounds
This method looks the most promising to me: it has a small memory size and BW footprint by allowing the reuse of vertex data. The pos-vertex cache won't work though, because for the HW, no vertex data is actually being reused.
But this code relies in the GPU's ability to hide the latency of the dependant fetches, otherwise it won't perform well. Also GPUs that have a hardware vertex data prefetcher (e.g. non-GCN architectures) won't get the chance to use it.
Another disadvantage is that I have to refactor my engine to consider the case where the vertex & index data comes as structured buffers instead of regular vertex and index buffers.

Does anyone have any better guess than mine on which approach should I devote most of my time? Anyone with some experience in one of these routes?


SDL2 and Linux [RANT]

31 January 2015 - 11:56 PM

Hi everyone!


I chose SDL2 after hearing wonders about it: multiplatform, handles windowing, multiple monitors (specially on Linux!), input, releasing of input grabbing when debugging, it's backed by Valve, etc, etc.

I'm an Ogre developer and we have our own windowing management code for all platforms; however it's not perfect and it doesn't handle input. From what I've heard SDL2 would be a great replacement in all aspects.


So I believed what I've been told and went ahead. Now I'm quite pissed. This piece of software is buggy as hell on Linux. This is what I've found:


1. Creating a GL context that is not supported (i.e. trying a 4.6 or a 5.0 context) will result in a deadlock when calling SDL_GL_CreateContext (or when making the next X11 function if I create the context myself). The callstack is (sorry for no symbols):

0 __lll_lock_wait 135 0x7ffff5316f2c 
1 _L_lock_909 /lib/x86_64-linux-gnu/libpthread.so.0 0x7ffff5312657 
2 __GI___pthread_mutex_lock 79 0x7ffff5312480 
3 ?? /usr/lib/x86_64-linux-gnu/libX11.so.6 0x7ffff5a27973 
4 ?? /usr/lib/libGL.so.1 0x7fffec262406 
5 ?? /usr/lib/x86_64-linux-gnu/dri/fglrx_dri.so 0x7fffe706b844 
6 ?? /usr/lib/libGL.so.1 0x7fffec236022 
7 glXDestroyContext /usr/lib/libGL.so.1 0x7fffec23622c 
8 ?? /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 0x7ffff6e1e931 
9 ?? /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 0x7ffff6e13710 
10 Demo::GraphicsSystem::initialize GraphicsSystem.cpp 140 0x42906e
It may look like it could be AMD's GL driver fault, or the dri driver, or X11. But this doesn't happen when the GL context attempt is used on a non-SDL window.
Either SDL2 is at fault, or it is setting some obscure property on the X11's window that triggers this 100% repeatable deadlock.
2. Unless the window starts maximized (the bug can still be triggered by restoring the maximized window and then maximizing it again), maximizing the window will leave a small portion of the screen to the left not being rendered.
This could get fixed by making the window borderless when going fullscreen... except that all the ways to query if the window is maximized are broken!!!
Similar bugs have already been noticed, and turns out the cause of all these issues have been reported over and over and over again. The bug reports even contain patches to fix the problem! And it's an easy one! But it appears they never made into the repo, despite some of the bug reports being 2 years old.
3. There's like a chance of 1 in 5 that if I set a breakpoint in QtCreator while my application is rendering, to lock the entire system. I can only move the mouse, music still plays (until the end of the track is reached) and that's it. Clicking doesn't do anything, the keyboard is completely locked up. I must do a hard reset.
4. Going fullscreen that involves changing the display resolution will report the wrong screen size (i.e. if I demand 1280x720 but I was at 1920x1080 when launching; SDL2 wrongly reports the resolution is now 1920x1080; leading to incorrect rendering)
So simply... WHAT THE F**K!?
I thought this was a solid stable piece of software recommended by Valve for Linux gaming. I know for personal experience that window and input management on Linux is a nightmare so I expected things to not go fully smooth, but what I found highly under-delivered and frankly, it is over hyped.
Turns out the windowing code we have in Ogre seems to be working better than SDL's so far. Too bad it doesn't handle input; which is an aspect I do like about SDL and have no complaints.
Am I wrong? Am I the only one with these problems??? Am I overreacting?

TCP's 3-way handshake... why not 2-way?

13 May 2013 - 01:09 PM

Hi everybody.
I'm writting a simple reliability layer on top of UDP. Not that I want to reinvent the wheel, just most of the data I'll be sending can be sent unreliable but there are bits of data every now and then that need to be sent reliably; and mixing tcp & udp gets even more troublesome.
For establishing a connection, I'm well aware of the 3-way handshake that TCP uses "SYN; SYN-ACK; ACK"
However, what I don't get, is why the third ACK is needed. Yes, I know it's the ultimate proof that the connection has been acknoledged by both parties; but I don't believe it's absolutely necessary.
This question has already been raised in StackOverflow, however the answers there don't satisfy me:
Let's see a communication without the 3rd ack:

Case: Client didn't get SYN-ACK
In this case, Server thinks the connection is established, Client think it's not. Just send another SYN from client until the SYN-ACK is received
Server may start sending data to client because it doesn't know the SYN-ACK got through. Client won't ACK that data because his connection isn't yet established, so server will continue to keep sending data over & over again until timeout. When the Client successfully gets the syn-ack; it will ack that data, hopefully before the timeout. If timed out, server-side it will just look like one connection timed out, and another came in. It's important that server doesn't use the SYNs from client as proof of heartbeat.
Typical view on this: The server needs to allocate resources (for tcp). More SYNs received -> more resources. However I send a random ID generated client-side with the SYN. That way the server identifies the SYN & IP with associated resources using that ID (and deals with client reconnecting and starting a new session as they'll change their ID; or with another client getting the same IP)
ACKs from normal messages always send the ID along the sequence number. So that if client reconnects (or new client got the same IP & port old client had) the server won't think an ack received from an old session is acknowledging packets sent from the current session.


A connection could be hijacked only if a machine gets the same IP address (and port), happens to use the same ID the other client has been using, and all happens before timeout (or there is a man in the middle that can see all data, spoof the IP, and still read the answers from server because he can see all data going to that spoofed IP).

But it's not like TCP is foolproof to hijacking either. Granted, this method is a lot easier to hijack because the ID, IP & port is repeated in every ack. Furthermore I'm interested in preventing "accidental" hijacking, not directed attacks.
The only disadvantage I can see: Potentially much higher bandwidth consumption (because the server may start sending data while client won't acknoledge it), while TCP needs to account for congestion control (which I don't care).
In TCP, everything is silent until SYN-SYN-ACK-ACK has been performed.


Bigger ACKs as a disadvantage could also be mentioned, but TCP overhead is already much bigger than UDP, and again, most of the data I'll be sending is unreliable (no need for ack), while every now and then I send some reliable data (needs guaranteed delivery, guaranteed to arrive in order)



Am I missing something? Why is the third ACK needed?


New site to get free (royalty free) music

19 March 2013 - 05:04 PM

Hi everyone! I don't usually advertise my own sites in a full forum posts, but my Dad's a musician and we're setting up a website for him to share his work under licenses similar to CC BY SA, so yes, you can use his music for your own video games (or film, or other projects) as long as you credit him properly (even if it's a commercial project!)


The site already! www.yosoygames.com.ar


We're still slowly setting up the site, he has ~80 tracks and counting (but we've only uploaded 19 so far); so let us know through here if you encounter bugs, broken links, can't access the page, just want to leave music feedback, or just thanks. We still don't know how well the server will cope with real load.

We're planning on adding ads & a donation button to support server costs; as well as keep uploading more of my dad's music.


Best regards to everyone!


DOWNLOAD DEMO Distant Souls + Screenshots!

22 May 2012 - 08:19 AM

Some of you may have heard of it.

It's now time to officially announce the first Demo of Distant Souls!




The game demo went into the Intel Level Up contest, but failed to run **sniff**. So now I need testing & feedback from the community.

I've been around in GD.Net for 6 years and many of you may be familiar with my virtual face as I'm always around the Techie forums.
Specially if you've been around the Ogre forums, you may already know about me, I'm always contribute to the Open Source community, be it Ogre Meshy, Instance Manager, Depth Sharing, or as tech support through forums, without ever asking anything in return.
If you still want to know more about my contributions to OSS, you can google my name and my alias (Dark Sylinc, dark_sylinc).

But this time I have big a favour to ask and get some of that love back. Currently I've been running through some tough financial difficulties, and my bets have been on Distant Souls. Being disqualified from the contest didn't help, while I'm also currently in the process of seeking government funding as well as potential private investors.
WANT TO HELP? SHARE on Facebook, FOLLOW the Twitter account,SUBSCRIBE to the Youtube channel. Every bit helps. The more subscribers/followers, the bigger your support. Spread the word!

Let everyone prove there's big, fun, quality game out there in the Indie scene.

You are not forced to do it, I don't expect you to do it; and it won't reflect my future contributions to Open Source projects, but it will help me. And I will greatly appreciate it Posted Image

Other ways you can help:
  • Does it run in your machine? Post all your 5 Logs, they are in the file %AppData%\Distant Souls. Also post all your *.rpl files there so I can reproduce your bug.
  • What do you think about the game?:
  • Do you like it?
  • Is it fun?
  • Was there something you spent too much time to figure out?
  • were you stuck?
  • Did you enjoy it?

Didn't enjoy it? Then tell me! You won't hurt my feelings! Games are an iterative process. We will work on it as many times as possible until we're all 24hs addicted.
This is valuable feedback and please post your results!

IF YOU OWN AN INTEL HD 3000 PLEASE SHARE YOUR EXPERIENCE WITH US!!! I'm 99% sure the game didn't run in the contest because of that GPU, even though, it's ought to be capable to run it.

System requirements:
  • Windows XP/Vista/7
  • Intel Core 2 Duo 2.2 GHz or better/AMD Athlon 64 X2 5000+
  • 2 GB RAM
  • NVIDIA Geforce 8 series or better / ATI Radeon HD 2000 series or better (Shader Model 3.0 compliant with full VTF support)
Unsupported Hardware:
The following hardware is known not to work. And it's really hard to support them, this list not likely to be reduced:
  • ATI Radeon X1000 series
  • Intel GMA 950 series
  • GeForce 6200 (??? needs confirmation)
If you need to contact me directly, you can do so at: dark_sylinc [at] yahoo [dot] com [dot] ar

Mandatory screenshots:
Posted Image
Posted Image

Posted ImagePosted ImagePosted Image
Posted ImagePosted ImagePosted Image
Posted ImagePosted ImagePosted Image

Plot summary:
Distant Souls takes place in the historical events in Dyrvingahl. Long before the start of the game, a dark being killed Nathan's parents, destroyed his entire village, and started a war between the Three Proud Nations.
15 years later little is known about the dark being and those few who track him down call themselves hunters; each hunting it for it's own personal motive.
Today, the world is in complete turmoil, many factions constantly form alliances to take over cities; lasting their control as short as the alliance was formed; while hunters have to make it's way through to reach their ultimate goal.
Player's hunters will have to face with the decision to involve in local affairs or stay distant as much as they can.

Hope you enjoy it!!