gpujob 0.0.1__tar.gz

gpujob-0.0.1/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 TheGeneral01
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

gpujob-0.0.1/PKG-INFO

@@ -0,0 +1,30 @@
+Metadata-Version: 2.4
+Name: gpujob
+Version: 0.0.1
+Summary: A lightweight JIT compiler for executing Python math on the GPU via Vulkan.
+Author: TheGeneral01
+License: MIT
+Classifier: Programming Language :: Python :: 3
+Classifier: License :: OSI Approved :: MIT License
+Requires-Python: >=3.8
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Dynamic: license-file
+
+As a preface, this is loosely based on the Vulkan guide from https://vulkan-tutorial.com/ for the C++ side of things. Massive thanks to all the wonderful people over there so I don't have
+to painfully dig through documentation from (the also wonderful people at) Vulkan's source code.
+
+I apologize to those of you whom think this is refined code from a professional at C++ and/or Python, for you will find it is anything but. I will try to keep this library as
+efficient as possible, but I am merely human just as you are. I wish I could make everyone happy, but I have to also set boundaries as a developer. Unfortunately, if
+you put an API call in a function meant to be processed thousands of times per second on a GPU, I don't think I can help you. (Although, hopefully this will be automatically
+resolved in a later update, but only time shall tell. Python is not the magical box of cool hat tricks.)
+
+As you read this right now, this is a very early build, so expect bugs, wrongful errors, and if at the worst, data corruption. Until I remove this message, this will
+be using copy to copy both your function and arguments for both me, and your safety/sanity to avoid a tragic end.
+
+Please contact me with logs over on Github issues if you have any problems. Thanks.
+
+-TheGeneral01
+
+Last Updated:
+08/29/26

gpujob-0.0.1/README.md

@@ -0,0 +1,17 @@
+As a preface, this is loosely based on the Vulkan guide from https://vulkan-tutorial.com/ for the C++ side of things. Massive thanks to all the wonderful people over there so I don't have
+to painfully dig through documentation from (the also wonderful people at) Vulkan's source code.
+
+I apologize to those of you whom think this is refined code from a professional at C++ and/or Python, for you will find it is anything but. I will try to keep this library as
+efficient as possible, but I am merely human just as you are. I wish I could make everyone happy, but I have to also set boundaries as a developer. Unfortunately, if
+you put an API call in a function meant to be processed thousands of times per second on a GPU, I don't think I can help you. (Although, hopefully this will be automatically
+resolved in a later update, but only time shall tell. Python is not the magical box of cool hat tricks.)
+
+As you read this right now, this is a very early build, so expect bugs, wrongful errors, and if at the worst, data corruption. Until I remove this message, this will
+be using copy to copy both your function and arguments for both me, and your safety/sanity to avoid a tragic end.
+
+Please contact me with logs over on Github issues if you have any problems. Thanks.
+
+-TheGeneral01
+
+Last Updated:
+08/29/26

gpujob-0.0.1/pyproject.toml

@@ -0,0 +1,16 @@
+[build-system]
+requires = ["setuptools>=61.0.0"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "gpujob"
+version = "0.0.1"
+description = "A lightweight JIT compiler for executing Python math on the GPU via Vulkan."
+readme = "README.md"
+authors = [{ name = "TheGeneral01" }]
+license = { text = "MIT" }
+classifiers = [
+    "Programming Language :: Python :: 3",
+    "License :: OSI Approved :: MIT License",
+]
+requires-python = ">=3.8"

gpujob-0.0.1/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+

gpujob-0.0.1/src/gpujob/gpujob.py

@@ -0,0 +1,37 @@
+def __init__(self):
+    ...
+    """
+    Let's go ahead and define a few of the parameters we're going to need.
+    
+    1. function_input: This is similar to a lambda in C++, I don't exactly know how that carries over in Python (and this is a reminder to update this documentation later). This is the function that will be executed on the GPU.
+    2. arguments: This is a list of arguments that will be passed to the function_input when it is executed on the GPU.
+    3. maximum_memory: This is the maximum amount of GPU memory that can be used for this job. It is important to
+        distinguish this between total memory. This is designed to prevent crashes. In the event the arguments are larger than the maximum allotted and/or physical memory, the arguments will be 
+        parsed into smaller chunks and executed in a loop. This is important to prevent crashes when the arguments are too large to fit into memory.
+    4. gpu_id: This is the ID of the GPU that will be used for this job. This is important to distinguish between multiple GPUs on a single machine. If this is not specified, the default GPU (most VRAM) will be used.
+    5. ignore_errors: This is a boolean that will ignore all errors that occur during the execution of the function_input. This is only relevant to errors that occur during GPU execution, parsing will always return errors.
+    6. progress: This is a boolean that will display a progress bar during the execution of the function_input. # Might remove? I don't know how Python devs like higher-level functions in performance libraries.
+    7. unsafe: This is a boolean that will allow for unsafe operations to be performed on the GPU, such as using a theoretical 100% capacity of the GPU.
+    8. parallel: This is a boolean that will allow for multiple GPUs to be used for this job. This is important to distinguish between single and multi-GPU jobs. If this is not specified, the default is False.
+    9. core_sync: This is a boolean that will allow for batched execution of the function_input. This is important to distinguish between single and batched execution. If this is not specified, the default is False. This ties multiple
+        GPU cores together, allowing for (in some instances) more efficient execution of the current job. This is only relevant to jobs that are not parallelized, as parallelization will automatically batch the execution of the function_input.
+        Rather, this is the act of dividing function_input itself.
+    10. batching: This is a boolean that will allow for the JIT to batch certain instances of the data together. For example, suppose you have a function that takes in a list of 1000 items, however the GPU can only process 100 items at a time,
+        yet the function wants to process 150 items at a time. This is where batching comes in, as it will allow the JIT to predict deterministic batching processes, that splits the data into smaller subsets, yet still returns the same result.
+    11. experimental: This allows for features like core_sync, batching, and parallel to be used.
+
+    Other things to consider:
+    1. Pickle support - How should pickling work during execution?
+    2. Pandas support - Should dataframes be supported? If so, how should they be handled? and, should an output be able to have a .df attribute that is a dataframe? This would be useful for dataframes that are too large to fit into memory, but can be processed in chunks.
+    3. General large data support - In the event an argument (such as a df > 8GB) is too large for available GPU, how should it be split? What if it relies on a moving window larger than the available GPU memory?
+    4. API support - Should we allow the user to designate if they desire to use Vulkan in comparison to CUDA, OpenGL, OpenCL, etc? Likely solution is to split into modules such as gpulib-vk, gpulib-cuda, etc...
+    5. Should we allow for a different type of processing to be used, such that small functions are optimized? Consider rendering, small functions, but incredibly repetitive.
+    6. Numpy support - How should advanced math, such as linear algebra or linear regression be handled? Should the JIT implement functions in place of the traditional numpy logic?
+    7. Floating-point precision - Should this have a use for finance, how would that be handled? In the likely event that function_input is a financial function, how does the logic for those floating-point operations transfer to
+        a GPU? Consider a library like mpmath, how would implementation of that logic be handled in the AST -> GPU translation?
+    8. Dedicated GPU console - Should the GPU be assigned a dedicated console for debugging?
+    9. Syncronizing function values - Suppose the user made an API request (why would you ever do this??? whatever, I have to plan for it anyway), the C++ embedded code would have to interface BACK to Python and external libraries
+        to handle the request. How would this be handled, and should it be cached if it *is* a reocurring operation?
+    10. I'll come up with some more.
+    """
+

gpujob-0.0.1/src/gpujob.egg-info/PKG-INFO

@@ -0,0 +1,30 @@
+Metadata-Version: 2.4
+Name: gpujob
+Version: 0.0.1
+Summary: A lightweight JIT compiler for executing Python math on the GPU via Vulkan.
+Author: TheGeneral01
+License: MIT
+Classifier: Programming Language :: Python :: 3
+Classifier: License :: OSI Approved :: MIT License
+Requires-Python: >=3.8
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Dynamic: license-file
+
+As a preface, this is loosely based on the Vulkan guide from https://vulkan-tutorial.com/ for the C++ side of things. Massive thanks to all the wonderful people over there so I don't have
+to painfully dig through documentation from (the also wonderful people at) Vulkan's source code.
+
+I apologize to those of you whom think this is refined code from a professional at C++ and/or Python, for you will find it is anything but. I will try to keep this library as
+efficient as possible, but I am merely human just as you are. I wish I could make everyone happy, but I have to also set boundaries as a developer. Unfortunately, if
+you put an API call in a function meant to be processed thousands of times per second on a GPU, I don't think I can help you. (Although, hopefully this will be automatically
+resolved in a later update, but only time shall tell. Python is not the magical box of cool hat tricks.)
+
+As you read this right now, this is a very early build, so expect bugs, wrongful errors, and if at the worst, data corruption. Until I remove this message, this will
+be using copy to copy both your function and arguments for both me, and your safety/sanity to avoid a tragic end.
+
+Please contact me with logs over on Github issues if you have any problems. Thanks.
+
+-TheGeneral01
+
+Last Updated:
+08/29/26

gpujob-0.0.1/src/gpujob.egg-info/SOURCES.txt

@@ -0,0 +1,8 @@
+LICENSE
+README.md
+pyproject.toml
+src/gpujob/gpujob.py
+src/gpujob.egg-info/PKG-INFO
+src/gpujob.egg-info/SOURCES.txt
+src/gpujob.egg-info/dependency_links.txt
+src/gpujob.egg-info/top_level.txt

gpujob-0.0.1/src/gpujob.egg-info/dependency_links.txt

@@ -0,0 +1 @@
+

gpujob-0.0.1/src/gpujob.egg-info/top_level.txt

@@ -0,0 +1 @@
+gpujob