Jump to content

  • Log In with Google      Sign In   
  • Create Account


jeff8j

Member Since 19 Jun 2009
Online Last Active Today, 06:16 AM

Posts I've Made

In Topic: OpenGL ES on desktops

05 August 2014 - 08:18 PM

Thanks looks like a good post ill read up


In Topic: OpenGL ES on desktops

05 August 2014 - 07:58 PM

Is there a way to do it in reverse so something already existing using opengl can run in a browser or mobile with opengles? Is there a higher language that could be used across everything? Do developers usually make multiple shaders for multiple targets?


In Topic: OpenGL ES on desktops

05 August 2014 - 07:45 PM

Thanks ill look into that at first glance i just see that it translates to directx is there something else they use for linux and mac osx?

 

Nevermind I see they use it for mac and linux just portions of it I guess


In Topic: Prevent Paging

21 July 2014 - 11:40 AM


These are two very different questions. Trying to answer the second without concretely answering the first is a complete and utter waste of time.

True but now I have 3 different ways to profile so by asking "Is there a way to prevent paging?" I have a way to truly test the first question of "Does paging the resources"

 

The problems still arnt solved and the paging issue is probably more case specific than anything but I have more knowledge than I did before and a path to determine where to go from here and this isnt the only problem either so theres alot more to improve upon im happy with all the knowledge I have received thank you all!


In Topic: Prevent Paging

21 July 2014 - 10:30 AM


That is what the buffer cache handles in a near-optimal way. Every file that is accessed reasonably often will be served from RAM.

Its the files that arnt ever accessed the all the sudden lots of them do need to be accessed is the concern but thats why in the begining I was thinking I could just keep accessing them and doing something with them to keep everything in ram but im not sure what would be something that wouldnt have much overhead and not be optimized away im sure if I just read them and dont do anything with them it will probably be optimized out not sure havent tried yet

 


If you can predict a few milliseconds ahead of time which file you'll be accessing (e.g. if throughput matters but requests need not be processed in realtime, this can be done by stalling a request for that long) you can fadvise (if you read the files) or madvise (if you map the files), allowing the OS to asynchronously prefetch the data in case it has really been swapped out. Advising has much less of a negative impact compared to locking.

I probably could predict alot of what the client side would require thats a very good idea I didnt think of that but now to keep the processing low for the 8 cores

 


If the dataset (files plus location data) can fit into RAM, this is entirely unnecessary. It will just magically work.

lol I hope so thats what im putting together some profiling stats just taking me a bit to design some realistic player like tests

 


Ugh! Bandwidth! This is unaffordable.

Its over lan and im thinking the lan could be sectioned off if needed to run multiple gigabit connections

The actual packets on the line is less than 5000 because the client will batch requests and the server will batch responses lets say that the request asks for 1000 files which is about whats happening right now if each of those touch the hard drive thats lets say 10ms each thats 10 seconds then say we have lots of clients (10+) thats totaly unacceptable (of course im working on multiple areas of this problem some of which mentioned above)


PARTNERS