ZDoom

I'll try to explain.

This will only speed up things if you can bake all the data for a sector into a single render object that can be dispatched using a single API call.
Vulkan can do that. You can create a single command buffer for the entire sector and when the sector needs to be drawn, just queue the command buffer for rendering and you are done. Lots and lots of time saved if done right.

On OpenGL you still need to set up the textures, the uniforms and a lot of other related data on the CPU for every draw call separately, i.e. you only save the time needed to collect the data. You cannot save much time with this (i.e. less than 10% is the best case scenario. That's simply not worth doing because of the needed checks elsewhere to invalidate the data if it changes.

You right, I still dont understand...

You don't understand. OpenGL has no means to store this stuff efficiently. You still have to do the really time consuming stuff, i.e. passing the data to the GPU, manually.
Vulkan, yes, but not OpenGL. This was one of the main reasons why these modern render APIs were invented in the first place. And unless you missed it, a Vulkan based renderer is already being worked on, so this suggestion has little reason to stay.

Graf Zahl wrote:What should that accomplish?

Decrease load on processor. I mean, processor spend time to check what segs videocard must draw, so that map took less space in memory and save some times for other stuff. But on overly large maps, like some blade of agony maps as most popular, it take too much time to check waht segs it, processor, must send to videocard for drawing.

And "nowadays", and "yesterdays", computers have enough memory to store "garbage" graphich data, like drawed texture, most part of which invisible to player. So if processor, insted of computing what segs player see and what not, send entire subsector to videocard, I think, this this will reduce the load on the processor.

What should that accomplish? With OpenGL it is not possible to pregenerate the render data so you end up doing more work. With Vulkan it will be doable to pregenerate an entire sector's non-translucent geometry as a single command buffer and handle it in one go - but that's a long term goal - first Vulkan needs to work.

Just an options which say to gzdoom "draw entire subsector with all segs".
With this option highly detailed maps can be played without significant lags.

I mean, gzdoom iterate through whole bsp tree to check what exactly it must draw.
After this gzdoom check how much segs have walls and which are it must draw.
And if there are too much walls tree become overly branched, because of implementation of bsp tree in doom.
Or I misunderstood logic of bsp tree in doom?